AS Components Bound to AS Release Cycle

[alrubinger]

Many AS Components are currently bound to the AS Release Cycle. ie:

<dependency>
 <groupId>org.jboss.jbossas</groupId>
 <artifactId>jboss-as-aspects</artifactId>
 <version>${project.version}</version>
</dependency>

...where ${project.version} is currently 5.0.0-SNAPSHOT.

This introduces the following:

1) Whereas AS Components are bound to AS Release Cycle
2) ...And whereas AS inherits AS Component dependencies from "dependency-matrix"
3) ...And whereas Consumers of AS Components inherit dependencies from "dependency-matrix"
4) Therefore AS Consumers are bound to a valid release of AS

Use Case:

1) We release AS 5.0.0.GA
2) 2 weeks later, AS dependency-matrix is now in 5.0.1-SNAPSHOT
3) We want to release EJB3 RC13, which requires changes introduced to jboss-as-aspects after AS 5.0.0.GA shipped
4) We'd have to release a new version of jboss-as-aspects (5.0.1) and jboss-as-dependency-matrix (5.0.1), but no changes to AS. This would put the current versioning (binding AS Components to SA Version) out of sync.

So we need for all components of AS to have independent release cycles.

Which also begs the question: if that's possible, shoudn't each component also have its own SVN structure (trunk, branches, tags)?

S,
ALR

[adrian.brock]

If you depend upon a jbossas sub-project then you are doing it wrong.
Circular dependency anyone? :-)

Your dependency should be on the integration-spi (which should not change)
not implementation details.

But then again, the aspects project is an abortion anyway
I've been complaining about it for years :-(

The transaction aspect should be in the transaction project,
the security aspect in the security project, etc.....

Classic example of re-inventing the wheel or NIH.

[alrubinger]

If you depend upon a jbossas sub-project then you are doing it wrong. Circular dependency anyone? :-)

This is the pattern we'd laid out. We avoid circular dependency by:

( -> == "Depends on")

* EJB3 -> AS Components
* AS -> AS Components, EJB3

...where AS itself is just an Assembly of modules. No AS Components may depend on any AS Component Consumer (ie. EJB3).

Your dependency should be on the integration-spi (which should not change) not implementation details.

Yes, I'd like to see more use of the integration project for well-defined SPIs between modules/projects, but for now it's one step at a time. Else we'll never release anything.

The goal is to keep untangling interdependent modules; I'd like to see the day when we have enough separation that the monolithic structure of AS can disintegrate.

But then again, the aspects project is an abortion anyway I've been complaining about it for years :-(

Was just an example, but you get the point. :)

S,
ALR

[alrubinger]

"ALRubinger" wrote:
I'd like to see the day when we have enough separation that the monolithic structure of AS can disintegrate.

I'll revise that. Either the monolithic structure can disintegrate, *OR* AS Components all have SPIs upon which consumers can depend, making it OK for AS Components to be tied to AS Release Cycle.

At the moment, we've got a hybrid that isn't going to work. What can be done?

S,
ALR

[starksm64]

There should not be AS projects in the parent pom. Only spis and thirdparty dependencies. If it has to be in jboss-as-dependency-matrix due to ejb3, webservices, or other project integration dependencies, then the project either needs an spi added to integration, or broken out like naming was.

[alrubinger]

Allright.

I'm going to move the AS Components back to jboss-as-parent (out of jboss-as-component-matrix), and that'll have to suffice for now while I switch back to EJB3.

A heads up that proper releases won't be possible until we tackle this.

S,
ALR

[kabirkhan]

I
But then again, the aspects project is an abortion anyway
I've been complaining about it for years :-(

The transaction aspect should be in the transaction project,
the security aspect in the security project, etc.....

+100