cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Distribution Thoughts
Date Mon, 16 Oct 2006 20:30:52 GMT


> >The manifest has a CLASSPATH entry in it that points to all the other
> >files.   That's why it's small.    There is no need to re-package all
> > the jars into one jar.    You use the CLASSPATH in the jar to point
> > to all the other jars.      It acts like "one jar" (just need the one
> > jar on the classpath") but keeps the modules separate.
> >
> >Repackaging will really break things.   A bunch of jars have the
> >META-INF/extensions.xml and META-INF/bus-extensions.xml and other
> > files.
>
> Well this should fixed. I'm -1 on doing a final release (not
> necessariliy M1) which doesn't have a bundled jar. Users go nuts when
> you don't have it and they have to use a gazillion jars.

Well, I'm completely -1 on repackaging into an "uber" jar unless there is 
a VERY VERY compelling reason to do so, and I don't see one here.

1) Just putting cxf-incubator.jar on the classpath accomplishes EVERYTHING 
that having the bundled jar does.   From a users standpoint, there isn't 
any difference from using the modular system.

2) The whole point of a plugable/modular system is that it's "plugable and 
modular."   The bundle jar kills that idea completely.   You would still 
need to include the non-bundles jars for that system to work.

3) Documentation sucks:  for one way, do this.   Otherwise, do that.

4) Support sucks: if a user has a problem, you need to know if they are 
using the bundled version or the non-bundled version.   

5) Testing sucks: all of our current testing infrastructure uses 
the "non-bundled" versions of everything.   I'm not even sure how we'd 
set things up to handle to "modes" from a maven standpoint.

6) The ONLY difference would be if they want to copy the stuff out of the 
lib dir into their own stuff.   In that case:
    a) If they are using Maven, it's automatic anyway.
    b) If they are using Ant, "cxf-*.jar" works fine
    c) I don't think it's a case I'd worry about for M1

7) It complicates the "plugin loading" and dynamic discovery stuff, which 
also then complicates the documentation.   Right now, the files 
a "plugin" (like Yoko) cares about are well defined file names.   
(META-INF/extensions.xml, bus-extensions.xml, etc...)    We need to keep 
that, but you cannot do that if you bundle all the plugins together 
unless you keep a set of "uber" xml files for the "bundle" which I don't 
want to maintain.  (or write a plugin that would "merge" them all)

8) From my experience (IONA's commercial products), I've NEVER had a user 
complain about multiple jars IF there is an acceptable MANIFEST jar that 
works.  (or good shell scripts to setup the environment)    In anycase, 
even with the bundle, they'll have to deal with multiple jars (saaj jars, 
jaxb jars, spring jars, etc...) in addition to cxf-bundle.jar.   Thus, 
it's not a huge deal.   (And I refuse to bundle those things in.   Many 
licenses specifically prohibit that.   With maven doing 
things "automagically", I don't want it bundling things automatically 
that would violate a license)

Anyway, I see absolutely no compelling reason to create a bundle jar and 
LOT's of compelling reasons not to.

Enjoy!
-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Mime
View raw message