[EJBTHREE-1315] EJB3 Client JAR(s)

[alrubinger]

On the table: To make the EJB3 Client JAR one unit as its own assembly project, or have each module responsible for creating a *-client.jar of its own.

Regarding EJBTHREE-1315, Carlo has made the assertion:

"wolfc" wrote:
We should not have a client assembly project. That's just recreating the jbossall-client problem in ejb3.

As I understand the jbossall-client issues:

* Duplicate packaging (bloat) of classes already in $JBOSS_HOME/client
* Possibility that classes in jbossall-client.jar may also exist in other JARs, leading to ClassCastException if the versions are different

I don't see the relevance of those here.

However, the Plugin project must have the client JAR declared as a dependency for it to be included in the assembly. Most of these it gets transitively via EJB3 Core, however the client JAR from EJB3 Core is not there and must be specified separately. Else:

[WARNING] The following patterns were never triggered in this artifact inclusion filter:
o 'org.jboss.ejb3:jboss-ejb3-core:jar:client'

...which leads to http://jira.jboss.com/jira/browse/EJBTHREE-1310.

So, we've gotta explicitly define the client classifier dependencies somewhere. Best option I can see is in one new project, "client". What benefits do we reap by creating single artifacts for security-client, proxy-client, etc when they're just going to be repackaged together with the full lot anyway?

S,
ALR

[wolfc]

The same reason why we don't pack all of ejb3 or all of jboss together: we want to be able to upgrade individual components.

The benefit might currently not be clear because we only have one implementation for each component. But in future I want more caching and pooling implementations.

[alrubinger]

Then "plugin" would depend on core and each of the projects' client classifier versions. Very possible for the client classifier versions to not match the project versions obtained transitively via core.

S,
ALR