Depend on Polygene™

Note

Some of the Libraries and Extensions depend on artifacts that are not deployed in central, you’ll need to +add other repositories to your build scripts accordingly.

Release artifacts, including sources and javadoc, are deployed to Maven Central:

http://repo1.maven.org/maven2/ (US)

http://uk.maven.org/maven2/ (Europe)

Snapshot artifacts, including sources and javadoc, are built against the develop branch and deployed weekly to the Apache SNAPSHOTS repository:

http://repository.apache.org/snapshots/

Manually

If you don’t rely on your build scripts dependency resolution mechanism you should +download the SDK distribution.

Using Maven

You simply declare dependencies on Polygene™ artifacts:

<dependencies>
     <dependency>
         <groupId>org.apache.polygene.core</groupId>
         <artifactId>org.apache.polygene.core.bootstrap</artifactId>
@@ -93,15 +93,15 @@ add other repositories to your build scripts accordingly.

Release ar <releases><enabled>false</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> -</repositories>

dependencies { compile "org.apache.polygene.core:org.apache.polygene.core.bootstrap:POLYGENE_VERSION" runtime "org.apache.polygene.core:org.apache.polygene.core.runtime:POLYGENE_VERSION" testCompile "org.apache.polygene.core:org.apache.polygene.core.testsupport:POLYGENE_VERSION" }

compile.with 'org.apache.polygene.core:org.apache.polygene.core.bootstrap:POLYGENE_VERSION' package(:war).with :libs => 'org.apache.polygene.core:org.apache.polygene.core.runtime:POLYGENE_VERSION' -test.with 'org.apache.polygene.core:org.apache.polygene.core.testsupport:POLYGENE_VERSION'

libraryDependencies += \ "org.apache.polygene.core" % "org.apache.polygene.core.bootstrap" % "POLYGENE_VERSION" \ withSources() withJavadoc() libraryDependencies += \ @@ -109,7 +109,7 @@ libraryDependencies += \ withSources() withJavadoc() libraryDependencies += \ "org.apache.polygene.core" % "org.apache.polygene.core.testsupport" % "POLYGENE_VERSION" % "test" \ - withSources() withJavadoc()

<ivy-module> <dependencies> <dependency org="org.apache.polygene.core" name="org.apache.polygene.core.bootstrap" rev="POLYGENE_VERSION" conf="default" /> http://git-wip-us.apache.org/repos/asf/polygene-website/blob/2d44da7d/content/java/develop/howto-invocation-annotation.html ---------------------------------------------------------------------- diff --git a/content/java/develop/howto-invocation-annotation.html b/content/java/develop/howto-invocation-annotation.html index 1a4d18b..1765b4a 100644 --- a/content/java/develop/howto-invocation-annotation.html +++ b/content/java/develop/howto-invocation-annotation.html @@ -1,5 +1,5 @@ -Use @Invocation +Use @Invocation @@ -66,11 +66,11 @@ })(); -

Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary

Overview
Polygene™ in 2 minutes
Polygene™ in 10 minutes
Polygene™ in 30 minutes
Depend on Polygene™
Assemble an Application
Transient Composites Tutorial
Services Composites Tutorial
< span class="section">Use contextual fragments
Leverage Properties
Create a Constraint
Create a Concern
Create a SideEffect
Create an Entity
Configure a Service
Use @Invocation
Polygene™ Build System
Polygene™ Documentation
Releasing Polygene™

Use @Invocation

The @Invocation annotation is relatively unknown but can be rather powerful to use, especially when creating +

Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary

Overview
Polygene™ in 2 minutes
Polygene™ in 10 minutes
Polygene™ in 30 minutes
Depend on Polygene™
Assemble an Application
Transient Composites Tutorial
Services Composites Tutorial
Use contextual fragments
Leverage Properties
Create a Constraint
Create a Concern
Create a SideEffect
Create an Entity
Configure a Service
Use @Invocation
Polygene™ Build System
Polygene™ Documentation
Releasing Polygene™

Use @Invocation

The @Invocation annotation is relatively unknown but can be rather powerful to use, especially when creating libraries that needs to be flexible of what the user needs to do.

@Invocation is a different InjectionScope, which is a concept to tell Polygene runtime where to look for the instances to be injected. Other, more well-known, InjectionScope annotations are @This, @Structure and @Service.

The @Invocation injection scope can provide the following types, all related to the on-going method invocation, -which is especially useful in Generic Concerns or Generic Mixins;

+which is especially useful in Generic Concerns or Generic Mixins;
- java.lang.reflect.Method - The current method being invoked.
- java.lang.reflect.AnnotatedElement - An descriptor for all annotations of the Method. @@ -78,11 +78,11 @@ which is especially useful in Generic Concerns or Generic Mixins;
  Custom Annotations - Your own annotation type.
- java.util.Iterable<Method> - An iterable of all declared methods of the composite type. -
java.lang.reflect.Method
This injection will simply provide the java.lang.reflect.Method of the on-going call. For generic fragments that +

java.lang.reflect.Method

This injection will simply provide the java.lang.reflect.Method of the on-going call. For generic fragments that will be the same as the second argument in the java.lang.reflect.InvocationHandler.invoke() method. Sometimes -it is useful to obtain this for typed fragment as well, to reduce names in Strings.

java.lang.reflect.AnnotatedElement

This Reflection API class encapsulates the annotation aspect of any element that can be annotated. Polygene implements +it is useful to obtain this for typed fragment as well, to reduce names in Strings.

java.lang.reflect.AnnotatedElement

This Reflection API class encapsulates the annotation aspect of any element that can be annotated. Polygene implements this interface for the Composite. That means that annotations for both the method as well as the composite is provided -through this injection.

Custom Annotations

It is often useful to introduce one’s own annotations, especially for libraries, and use these annotations to direct +through this injection.

Custom Annotations

It is often useful to introduce one’s own annotations, especially for libraries, and use these annotations to direct the runtime to do different things. Many of the "built-in" features in Polygene is actually done by this mechanism and not directly implemented in the Core Runtime.

First create an annotation of your own liking, it must have java.lang.annotation.Retention set to RUNTIME

@Retention( RUNTIME )
 @interface Foo
@@ -100,7 +100,7 @@ not directly implemented in the Core Runtime.
First create an annotation o
 {
     @Invocation
     Foo foo;
-

java.util.Iterable<Method>

This injection will provide all the declared methods of the current composite. This is particularly useful for mixins +

Group ID	Artifact ID	Version
org.apache.polygene.core	org.apache.polygene.core.api	3.0.0-SNAPSHOT

Group ID

Artifact ID

Version

org.apache.polygene.core

org.apache.polygene.core.api

3.0.0-SNAPSHOT

public interface Book +terms.

If you want to reproduce what’s explained in this tutorial, remember to depend on the Core API artifact:

Table 8. Artifact

Group ID	Artifact ID	Version
org.apache.polygene.core	org.apache.polygene.core.api	3.1.0-SNAPSHOT

At runtime you will need the Core Runtime artifact too. See the Depend on Polygene™ tutorial for details.

So in Polygene, instead of writing;

public interface Book
 {
     String getTitle();
     String getAuthor();
@@ -91,7 +91,7 @@ like this;
public interface Book
     @Immutable
     Property<String> author();
 }
-
There is more to this than meets the eye.

+

There is more to this than meets the eye.

@Immutable annotation signals that this can’t change.
Property still have a set() method, which can be used during the initialization only. @@ -108,10 +108,10 @@ Module module; Book book = builder.newInstance(); String title = book.title().get(); // Retrieves the title. book.title().set( "Long Live POJOs" ); // throws an IllegalStateException -

public interface SwingInfo { http://git-wip-us.apache.org/repos/asf/polygene-website/blob/2d44da7d/content/java/develop/index.html ---------------------------------------------------------------------- diff --git a/content/java/develop/index.html b/content/java/develop/index.html index 206a9b5..faf3c19 100644 --- a/content/java/develop/index.html +++ b/content/java/develop/index.html @@ -1,5 +1,5 @@ - + @@ -66,13 +66,13 @@ })(); -

Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary

Polygene™

3.0.0-SNAPSHOT

This is the documentation for Polygene™ 3.0.0-SNAPSHOT. Use the version switcher on the left to browse other -versions documentation.

What is Apache Polygene™ ?

The short answer is that Apache Polygene™ is a framework for domain centric application development, including evolved +

Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary

Polygene™

3.1.0-SNAPSHOT

This is the documentation for Polygene™ 3.1.0-SNAPSHOT. Use the version switcher on the left to browse other +versions documentation.

What is Apache Polygene™ ?

The short answer is that Apache Polygene™ is a framework for domain centric application development, including evolved concepts from AOP, DI and DDD.

Polygene™ is an implementation of Composite Oriented Programming, using the standard Java platform, without the use of any pre-processors or new language elements. Everything you know from Java still applies and you can leverage both your experience and toolkits to become more productive with Composite Oriented Programming today.

Moreover, Polygene™ enables Composite Oriented Programming on the Java platform, including both Java and Scala as primary -languages as well as many of the plethora of languages running on the JVM as bridged languages.

We strongly recommend the introduction section.

Brief History

Apache Polygene™ started its life in 2007 as Qi4j™, initially at OPS4J’s infrastructure and later on GitHub. +languages as well as many of the plethora of languages running on the JVM as bridged languages.

We strongly recommend the introduction section.

Brief History

Apache Polygene™ started its life in 2007 as Qi4j™, initially at OPS4J’s infrastructure and later on GitHub. In March 2015, Apache Polygene™ was created with the Qi4j™ codebase as the base, existing Apache Members as the bootstrap Project Management Committee (PMC).

Qi4j™ is pronounced "chee for jay". This website is out of scope to explain the many facets and history of Qi, so we refer the interested to read the lengthy article at http://git-wip-us.apache.org/repos/asf/polygene-website/blob/2d44da7d/content/java/develop/intro.html ---------------------------------------------------------------------- diff --git a/content/java/develop/intro.html b/content/java/develop/intro.html index 056518a..ef96ec3 100644 --- a/content/java/develop/intro.html +++ b/content/java/develop/intro.html @@ -1,5 +1,5 @@ -Introduction +Introduction @@ -66,7 +66,7 @@ })(); -

Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary

Highlights
Background
What is COP?
What’s an Object anyway?
Polygene™ and state modeling
Related publications & projects

Introduction

Highlights

Principles

Composite Oriented Programming builds on some principles that are not addressed by Object Oriented Programming at all.

+
Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary
Highlights
Background
What is COP?
What’s an Object anyway?
Polygene™ and state modeling
Related publications & projects
Introduction
Highlights
Principles
Composite Oriented Programming builds on some principles that are not addressed by Object Oriented Programming at all.
Behavior depends on Context
Decoupling is a virtue @@ -74,8 +74,8 @@ Decoupling is a virtue Business Rules matters more.
Classes are dead, long live interfaces. -
Behavior Depends on Context
Many objects has life cycles that are more extensive than the simple model that Object Oriented Programming model wants -us to believe. A few simple examples;
+
Behavior Depends on Context
Many objects has life cycles that are more extensive than the simple model that Object Oriented Programming model wants +us to believe. A few simple examples;
An egg becomes a chicken which in turn becomes food.
I am a programmer at work, a father+husband at home, a victim in a traffic accident and hunter and pray in the jungle. @@ -89,13 +89,13 @@ that Person may live on for a long time. In a OOP system, we would need to trans LivingPerson class to a DeadPerson class. In Composite Oriented Programming, it is the same object with different behavior.
We think that one of the the main flaws in OOP is that it is not object oriented at all, but in fact class oriented. Class is the first class citizen that objects are derived from. Not objects being the first-class citizen to which -one or many classes are assigned.
Decoupling is Virtue
Decoupling is more important than developers in general think. If you could have every OOP class decoupled from all +one or many classes are assigned.
Decoupling is Virtue
Decoupling is more important than developers in general think. If you could have every OOP class decoupled from all other classes, it is easy to re-use that class. But when that class references another class and the chain never ends, your chances of re-use diminishes quickly.
Object Oriented Programming is suffering a lot from this, and many mechanisms have been introduced over time to counter this problem. But in reality, the best we can manage is subsystems of functionality, which client code can re-use. And these subsystems tend to be infrastructure related, since domain models are less prone to be similar enough from one project to the next, and since OOP in reality constrains the the re-use of individual domain classes, we need to re-do -the domain model from scratch ever time.
Business Rules matters more
Smart developers often think that low-level, infrastructure and framework code is more important and more cool to work +the domain model from scratch ever time.
Business Rules matters more
Smart developers often think that low-level, infrastructure and framework code is more important and more cool to work with, than the simple domain model. But in reality, it is the Domain Model that reflects the actual need and pays the bills. Infrastructure is just a necessary evil to get things done.
If most developers could focus on the Business Rules and Domain Model, and not having to worry about any infrastructure issues, such as persistence, transactions, security or the framework housing it all, the productivity would surge. Eric http://git-wip-us.apache.org/repos/asf/polygene-website/blob/2d44da7d/content/java/develop/introduction-background.html ---------------------------------------------------------------------- diff --git a/content/java/develop/introduction-background.html b/content/java/develop/introduction-background.html index 12a8f4e..09ba614 100644 --- a/content/java/develop/introduction-background.html +++ b/content/java/develop/introduction-background.html @@ -1,5 +1,5 @@ -Background +Background @@ -66,33 +66,33 @@ })(); -
Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary
Highlights
Background
What is COP?
What’s an Object anyway?
Polygene™ and state modeling
Related publications & projects
Background
Polygene™ is the first Composite Oriented Programming impl ementation leveraging the Java 5 platform, so that everything you +
Polygene™
Introduction
Tutorials
Javadoc
Samples
Core
Libraries
Extensions
Tools
Glossary
Highlights
Background
What is COP?
What’s an Object anyway?
Polygene™ and state modeling
Related publications & projects
Background
Polygene™ is the first Composite Oriented Programming implement ation leveraging the Java 5 platform, so that everything you know from Java 5 still applies. You can mix Polygene™ with your ordinary Java code as much as you want. All your existing Java tools works just like before, and Polygene™ does not introduce any new programming language, no special development -tools needed and no XML is required.
Purpose
Polygene™ addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs, +tools needed and no XML is required.
Purpose
Polygene™ addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs, and let those requirements flow downwards in the software stack and dictate the requirements for underlying layers such as persistence, messaging, querying and more. This means that the business value developer is left to concentrate on the domain models and the actual application bringing the value, instead of creating massive amounts -of glue code to tie underlying technologies together.
Problem Descriptions
Polygene™ didn’t appear out of the blue, when the founders of the project had nothing better to do. It is the result of +of glue code to tie underlying technologies together.
Problem Descriptions
Polygene™ didn’t appear out of the blue, when the founders of the project had nothing better to do. It is the result of observation of problems in real applications, and the experience from previous attempts to address or correct these -problems, that has led to the Polygene™ vision.
Object Oriented Programming (OOP)
How can OOP be a problem? We and others have observed that there is a fundamental flaw in the OOP model. In fact, we +problems, that has led to the Polygene™ vision.
Object Oriented Programming (OOP)
How can OOP be a problem? We and others have observed that there is a fundamental flaw in the OOP model. In fact, we would like to even state that OOP as it is commonly practiced today is not object oriented at all. The object is not the primary citizen, instead the class is the primary artifact. In most mainstream OOP languages, Objects are derived from classes, not that classes are assigned to created objects. Therefore, we think it should have been called Class Oriented Programming. We can also see this class focus in many of the technologies in Java today: in Spring you declare -class names in application contexts, JSP uses class names to declare beans and so forth.
This in turn leads to that there is no good OOP solution for the problem we describe below.
Behavior depends on Context
Once you start thinking of "Behavior depends on Context", you have a hard time understanding how people for the last 20 -years or so of Object Oriented Programming (OOP) has ignored this fact.
Who am I?
When I sitting in front of the computer, I am a software developer, but if I go out in the jungle, I am suddenly +class names in application contexts, JSP uses class names to declare beans and so forth.
This in turn leads to that there is no good OOP solution for the problem we describe below.
Behavior depends on Context
Once you start thinking of "Behavior depends on Context", you have a hard time understanding how people for the last 20 +years or so of Object Oriented Programming (OOP) has ignored this fact.
Who am I?
When I sitting in front of the computer, I am a software developer, but if I go out in the jungle, I am suddenly hunter-gatherer and prey. A large set of me is the same, but my interaction with the surroundings, i.e. the context, is very different. I need different interfaces, so to speak, in these two different contexts.
Now, the above example is perhaps a bit extreme, but we see it in everyday life of the developer. When an object is stored in the database it is of a different class, than when it is transported to the client and possibly when it is displayed in the GUI. We see the effect of this problem in many of the design patterns and so called "best practices" -in Java EE development. Facades, delegation, data transport objects and many more.
Coupling
The OOP proponents once proclaimed that classes can be re-used, since the code is encapsulated with the class, so the +in Java EE development. Facades, delegation, data transport objects and many more.
Coupling
The OOP proponents once proclaimed that classes can be re-used, since the code is encapsulated with the class, so the class is an independent unit which lends itself well to re-use. In reality, however, we have found that classes becomes tightly coupled with many other classes in their neighborhood, leading to impossibilities of single class re-use. Many tricks are introduced to minimize the "Coupling Hell", such as Inversion of Control and Dependency Injection. Although those tools are good, the underlying problem remains.
Why do we end up with large coupled class network graphs?
Essentially, it boils down to "scope". Classes are too large, their scope is too large, and for each small functional unit within the class, there will be additional coupling to other classes. And this often progresses to the full -boundary of the entire domain the class remains in.
Application layer impedance mismatch
Almost all technologies used in modern software development, starts by looking at an infrastructural problem and try to +boundary of the entire domain the class remains in.
Application layer impedance mismatch
Almost all technologies used in modern software development, starts by looking at an infrastructural problem and try to solve that the best way. This is often done in a vacuum and layers on top will be struggling to map or translate the solution into the higher abstraction, and the higher up we get, the harder it becomes to ignore the assumptions, problems and limitations of the underlying technologies. It is also common that the underlying technologies "bleeds" @@ -102,25 +102,25 @@ often, the most skilled developers end up doing the bottom layers, leaving the h Another interesting consequence is that each layer needs to anticipate every single use-case - real, potential or perceived - and deal with it in a specifiable and useful manner. This leads to overly complex solutions, compared to if the system is built from the top layer down, where each layer beneath knows exactly what is expected from it, and only -needs to handle those use-cases.
Abstracting away meaning.
To paraphrase a famous proverb about a hammer: "If all you have are objects, everything looks like a dependency." +needs to handle those use-cases.
Abstracting away meaning.
To paraphrase a famous proverb about a hammer: "If all you have are objects, everything looks like a dependency." We think that increasing abstraction often also increases complexity, and that the abstraction benefits are somewhat linear whereas the complexity negatives are exponential. So, our conclusion is that by making no distinction between different kinds of objects, many sound technologies run into incredibly difficult problems. The implementation of the programming platform (e.g. Java) is of course easier to implement with a hefty amount of scope reduction into as few as possible abstractions. But that is not the situation for the user. The abstraction is then required to be reversed when the rubber hits the road, e.g. ORM mapping must be declared explicitly by the programmer, often using separate tools -and languages.
Solution
We think the solution was expressed more than 2500 years ago, first by Indian scholars and slightly later by Leucippus +and languages.
Solution
We think the solution was expressed more than 2500 years ago, first by Indian scholars and slightly later by Leucippus and Democritus. We are of course talking about atoms, and by using really small building blocks, we can express arbitrarily complex structures. By reducing the classes into what we in Composite Oriented Programming call Fragments, we limit the coupling network graph substantially. Re-use of Fragments becomes a reality, and by combination of Fragments, we compose larger -structures, the Composites.
Composition
Composite Oriented Programming also view the object, we call it the Composite instance, as the first class citizen. The +structures, the Composites.
Composition
Composite Oriented Programming also view the object, we call it the Composite instance, as the first class citizen. The Composite instance can be cast to any context, meaning a different behavior can be applied to the Composite instance, without affecting its underlying state. And back. This in turn means that we can for instance create a ServerContextualInvoiceEntity, transport that across to a client, cast it to a GuiContextualInvoiceEntity do the modifications to the underlying state, possibly using extra interfaces and methods for interacting with the GUI environment, and then transport the modified object back to the server, cast it back to the -ServerContextualInvoiceEntity, and then persist the changes.
Domain Driven Design focus
Composite Oriented Programming is heavily influenced by the book "Domain Driven Design" by Eric Evans. And we are +ServerContextualInvoiceEntity, and then persist the changes.
Domain Driven Design focus
Composite Oriented Programming is heavily influenced by the book "Domain Driven Design" by Eric Evans. And we are trying to use his analysis of the problem to provide the mechanisms needed to get the job done quicker and more reliably. Mr Evans talks about Applications, Layers, Modules, Specifications, SideEffects and so forth, and all of these should be present in a Composite Oriented Programming implementation, and to a large extent it is in Polygene™.