Build Contract for jbossall-client.jar

[alrubinger]

I'm currently maintaining a separate assembly for the repackaging of jbossall-client.jar in the EJB3 Installer component, used when the EJB3 Plugin is run.

Much like centralizing the dependencies between AS and AS component consumers, we'll need a similar mechanism defining the makeup of jbossall-client, else consumers fall out of sync.

Two suggestions:

1) We externalize the includes into a separate file

2) We revisit the use of the manifest's Class-Path entry and share a common .mf file

Option 2) is more implementation-independent; Option 1) integrates well with Ant "includesfile".

Defining task is:

http://jira.jboss.com/jira/browse/EJBTHREE-1240

Other ideas?

S,
ALR

[clebert.suconic]

jbossall-client.jar is a big mess...

We have already agreed sometime ago on the forums it should die. It's just a matter of someone taking the courage and removing it from the build :-)

[peterj]

If jbossall-client.jar disappears, what jar file will be required for clients? Listing 20-30 jar files in the classpath for a client seems to me to be asking too much work on the part of your customers. In addition, the forums will be flooded with people saying "I am get a class not found exception, which jar file contains class XXX?"

And I am not convinced that a script like jbossws' runclient is the solution either (especially because if often doesn't include all the necessary jar files).

Having a single jar file that includes everything needed for a typical client seems like a good idea to me.

[clebert.suconic]

The problem is maintaining it and repackaging it.
There are things we can't repackage...


Anyway... I don't take that decision...
I had a similar request for JbossMessaging on jboss-dev-list, and that started a short discussion about jboss-allclient.

I don't know if we should remove it or not.. but it can't be the way it's currently done. For instance, for JbossMessaging jbossall-client is next to useless as it doesn't include trove and some other thirdparty libraries we need.

[clebert.suconic]

We need an input from Scott or Dimitris on this.

(I was going to write this before but I pressed submit by accident)

[starksm64]

The solution we talked about being reasonable was to make the jbossall-client.jar a manifest only jar that references its content via the standard jar Class-Path manifest header. That way the client jars can easily be patched and jbossall-client.jar easily patched by updating the manifest, and there would be no duplicated content.

[alrubinger]

So...option 2 then. :)

"ALRubinger" wrote:
2) We revisit the use of the manifest's Class-Path entry and share a common .mf file

Where could this live? A new AS Component project with its own POM? Then it may be sucked in by the AS Assembly and AS Consumers.

Requirements:

* Needs to be consumable outside of AS
* Must be easily maintained and bound to AS build cycle, so cannot be external project
* Is not locked-down, so cannot be in "integration"

S,
ALR

[clebert.suconic]

Why not just change the build.xml on JBAS5-trunk/build to generate the file using classpath instead of exploding the files?

[alrubinger]

Why not just change the build.xml on JBAS5-trunk/build to generate the file using classpath instead of exploding the files?

For the reasons stated in my requirements.

S,
ALR

[wolfc]

This is about having a hook defined where we can rebuild jbossall-client.jar after release.

For example we could create a directory client/classpath.d which contain all class path entries a project/component wants to be on the client jbossall-client.jar classpath. Then rebuilding it is a matter of:

LANG=C A=`cat client/classpath.d/*`; echo $A >/tmp/newmanifest.mf
jar -cf jbossall-client.jar -m /tmp/newmanifest.mf

or something like that.

Then during distro build everyone copies their config file into client/classpath.d.

[wolfc]

Since we're not allowed to '+1' on the forum.

I say vote for http://jira.jboss.org/jira/browse/JBAS-4355. :-P

[starksm64]

That is already a critical issue, just make the change to a manifest only jar next week.