jboss-ejb3-project

[alrubinger]

This is to document a new component we'd discussed in IRC.

"project" module is to define the dependency chain, taking this responsibility away from "as-int". "as-int" may then be broken into "as5-int" and "as6-int", both to live outside the EJB3 Project, depending upon "project".

Additionally, jboss-ejb3-project should declare two assemblies, one each for the binaries and source JARs for all components under the EJB3 umbrella. This was recommended by one of our users: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204792

Without arguments I'll start on this in tandem with moving some things out of AS bit by bit.

S,
ALR

[alrubinger]

"project" is also a pretty bad name, I don't have a knack for this. Suggestions for one word that signify that "this module has all transitive dependencies and defines an EJB3 release" are appreciated.

assembly?
composite?
ejb3? (like: org.jboss.ejb3:ejb3)

S,
ALR

[alrubinger]

Some more thoughts:

Naming

I like "org.jboss.ejb3:jboss-ejb3"

Remove the component artifacts from JBossAS

If we provide a unified assembly for all EJB3 projects, then we may provide "jboss-ejb3.jar" as one artifact into AS. This provides the following benefits:

1) No more user confusion as to what version of the EJB3 project is in AS. A check into the manifest will simply say "1.0.0".

2) Removes the half-upgraded problem. Users won't be upgrading ejb3-core while neglecting to update ejb3-proxy or ejb3-common.

3) We can do away with the explicit dependencies upon the client classifier JARs:

<version.org.jboss.ejb3>1.0.0</version.org.jboss.ejb3> < This one stays
 <version.org.jboss.ejb3.common.client>1.0.0</version.org.jboss.ejb3.common.client>
 <version.org.jboss.ejb3.core.client>1.0.0</version.org.jboss.ejb3.core.client>
 <version.org.jboss.ejb3.proxy.client>1.0.0</version.org.jboss.ejb3.proxy.client>
 <version.org.jboss.ejb3.proxy.clustered.client>1.0.0</version.org.jboss.ejb3.proxy.clustered.client>
 <version.org.jboss.ejb3.security.client>1.0.0</version.org.jboss.ejb3.security.client>

Refactoring Required

In order to implement this, each component must have a dedicated namespace, ie. "org.jboss.ejb3.core" that doesn't conflict anywhere else. Otherwise there will be overwrites when we pack everything into one assembly. Take for instance in ejb3-core:

http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/java/org/jboss/ejb3/proxy/

S,
ALR

[wolfc]

org.jboss.ejb3:jboss-ejb3 is good as an overall name.

The aim of the game is not to get an unified assembly, but to get a diverse set of components which can form different assemblies. For example EJB 3 + Remoting 3, EJB 3 + QOS Cache, or just EJB 3 lite. Thus satisfying more use cases with less code bases.

The unique namespace is something we should strive for nevertheless.

[alrubinger]

"wolfc" wrote:
The aim of the game is not to get an unified assembly, but to get a diverse set of components which can form different assemblies. For example EJB 3 + Remoting 3, EJB 3 + QOS Cache, or just EJB 3 lite. Thus satisfying more use cases with less code bases.

I agree.

Then jboss-ejb3 should not declare dependencies, but rather configure the versions to be used for dependencyManagement.

So jboss-ejb3 becomes a POM project decending from jboss-ejb3-build, and as5-int, as6-int, ejb3-embeddable, ejb3-plugin use jboss-ejb3 as a parent. The unified assemblies can come the final projects in the chain.

S,
ALR