EJB3 embeddable class folders

[ruel.loehr]

Right now we are unjarring a bunch of stuff into three folders for ejb3 embeddable:

1) thirdparty classes
2) hibernate classes
3) jboss classes

Are these folders used for anything other than jarring up the build artifacts?

[bill.burke]

Yes. They are used for the E-EJB3 distribution. FOr testing, these must be built to test the standalone distribution! Please don't remove. Or, move the creation of these to be a dependency of the 'standalone-tests' target.

Thanks

[wolfc]

Yes. They are used for the E-EJB3 distribution. FOr testing, these must be built to test the standalone distribution! Please don't remove. Or, move the creation of these to be a dependency of the 'standalone-tests' target.

Thanks

What if we jar the jars and create a jar jars class loader?

Then we don't have to unjar any artifacts produced by other projects.

[bill.burke]

THe idea of merging the jars was for E-EJB3 users that run off of the Java classpath. They don't want 50 jars to add to their classpath, neither do they want a special classloader they have to use.

[wolfc]

You are right, they don't want a special class loader (IDE & compiler problems etc...).

But I still think that 'modifying' artifacts is bad practice (it doesn't way up to the above however).
How about an e-ejb3.jar with a Class-Path in the manifest that contains all the artifacts (which should be in the same directory)?
That should satisfy both IDEs and applications.

[bill.burke]

are you sure SE even recognizes Class-Path in the manifest? I thought this was a J2EE construct?

[starksm64]

Its standard JavaSE jar specification stuff:
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html

[wolfc]

We could create the same three jars, but then with Class-Path manifest instead of all the classes.

Shall I give it a shot?

[bill.burke]

Ok, demo it next week. Never used class-path.