cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: Distribution Thoughts
Date Mon, 16 Oct 2006 22:21:59 GMT
Daniel Kulp wrote:

>>>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
>>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.
That is simply not true. This is a big user experience issue.With the 
manifest jar they have to copy and maintain a bunch of jars. This is an 
turns people off and is a barrier to usage. Its an emotional reaction 
toward software. Users don't like having a gazillion jars around. It 
makes them feel uncomfortable.

>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.
Most people don't care about the modularity. They are happy having all 
the default stuff. If people want to only use certain things then they 
can use the modules.

Additionally, a user should be able to control modularity without 
manipulating their classpath. This should amount to including whichever 
cxf-foo.xml files they want on their claspath. Say cxf-core.xml, 
cxf-soap,.xml and cxf-http.xml

>3) Documentation sucks:  for one way, do this.   Otherwise, do that.
Not a big issue, we haven't really had any issue with XFire.

>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.   
This is a problem anyway - the jar should have a version period. What 
happen if someone uses the module approach, they don't update the 
cxf-incubator.jar and we add a module? Same problem.

Support sucks with the manifest jar because you have users asking - 
"which jars do I need" which inevitably results in confusion and email 
to the list.

>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.
Testing isn't a concern. We've already tested the classes. The only 
thing we need to make sure of is that we don't have the resources with 
the same name. And the only place this happens is with the 
cxf-extension.xml files. These need to change anyway to 
cxf-MODULENAME.xml so we can accomodate people in the scenario I 
mentioned above.

>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
This isn't a technical issue. See #1

>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)
Untrue. Spring, which we have to use anyway, supports the cxf-*.xml 
syntax. Spring handles all the merging and searching of the classpath.

>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)
User requests were the reason we moved to this approach in XFire - and 
while we didn't do a manifest jar because it was 1.4, I still stand by 
my statements in #1 as a valid reasons to do the bundle jar. And no I'm 
not saying we should bundle the dependencies.

>Anyway, I see absolutely no compelling reason to create a bundle jar and 
>LOT's of compelling reasons not to.
To say that there are no good reasons to do a bundle jar is simply not 
true. There are pros/cons for both, but overall I think users are more 
comfortable with the bundle approach.

- Dan

Dan Diephouse
(616) 971-2053
Envoi Solutions LLC

View raw message