You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2006/10/16 19:08:55 UTC
Distribution Thoughts
Hi all,
I just downloaded our distribution SNAPSHOT [1] and poked around a bit.
First let me say, great work - its looking quite good! However, I think
we need to address a few items before we're ready for a release:
* Why is it a JAR and not a ZIP/Tgz? I personally don't like it and
I doubt the incubator will be very keen on it either. For one it
extracts a META-INF directory which is annoying and for two it
isn't very friendly to users. I would be much more in favor of
both a zip/tgz distribution.
* The archive should expand into the directory
cxf-2.0-incubator-VERSION. Not doing so is highly frowned upon at
Apache. bin, docs, lib, dirs should be include in this directory.
* Whats the cxfinstaller for?
* I'm very wary about not putting a version # on cxf-incubator.jar.
I don't think the incubator will like it and I don't buy the
argument about having build scripts depending on cxf-incubator.jar
and having to change the version # every time. People can always
include cxf-incubator-*.jar from ant to pick up any version or
they can copy cxf-2.0-incubator-M1-SNAPSHOT to cxf.jar
* Instead of having cxf-*.jar in lib, I think they should be in some
other directory like "cxf-individual-modules/" so people don't
include both the bundled jar and the individual modules.
* Do we have to distribute activemq?
* avalon-framework isn't being properly excluded
* XmlSchema needs to be updated to version 1.1
* Why is concurrent included?
* Why are maven-* and wagon included?
* Why is XMLBeans 2.1.0 included?
* Why is Velocity included?
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: Distribution Thoughts
Posted by Bozhong Lin <bl...@iona.com>.
Dan Diephouse wrote:
> Hi all,
>
> I just downloaded our distribution SNAPSHOT [1] and poked around a bit.
> First let me say, great work - its looking quite good! However, I think
> we need to address a few items before we're ready for a release:
>
> * Why is it a JAR and not a ZIP/Tgz? I personally don't like it and
> I doubt the incubator will be very keen on it either. For one it
> extracts a META-INF directory which is annoying and for two it
> isn't very friendly to users. I would be much more in favor of
> both a zip/tgz distribution.
I agree. I looked into other Apache projects and I see that the most
common distribution formats are ZIP/Tgz, and I haven't seen a signle
distribution format as JAR. I will add a todo item for this if there is
no objection around this.
> * The archive should expand into the directory
> cxf-2.0-incubator-VERSION. Not doing so is highly frowned upon at
> Apache. bin, docs, lib, dirs should be include in this directory.
> * Whats the cxfinstaller for?
> * I'm very wary about not putting a version # on cxf-incubator.jar.
> I don't think the incubator will like it and I don't buy the
> argument about having build scripts depending on cxf-incubator.jar
> and having to change the version # every time. People can always
> include cxf-incubator-*.jar from ant to pick up any version or
> they can copy cxf-2.0-incubator-M1-SNAPSHOT to cxf.jar
> * Instead of having cxf-*.jar in lib, I think they should be in some
> other directory like "cxf-individual-modules/" so people don't
> include both the bundled jar and the individual modules.
> * Do we have to distribute activemq?
I am for not including activemq in distribution, and putting a note in
release note or readme file. Any objection for this? If not, I will
include this as an action item also.
> * avalon-framework isn't being properly excluded
> * XmlSchema needs to be updated to version 1.1
> * Why is concurrent included?
> * Why are maven-* and wagon included?
> * Why is XMLBeans 2.1.0 included?
> * Why is Velocity included?
>
> Cheers,
> - Dan
>
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
Jim Jagielski wrote:
>
> On Oct 16, 2006, at 2:05 PM, Dan Diephouse wrote:
>
>> Daniel Kulp wrote:
>>> Dan,
>>>
>>>
>>>> I just downloaded our distribution SNAPSHOT [1] and poked around a
>>>> bit.
>>>> First let me say, great work - its looking quite good! However, I
>>>> think
>>>> we need to address a few items before we're ready for a release:
>>>>
>>>> * Why is it a JAR and not a ZIP/Tgz? I personally don't like it
>>>> and
>>>> I doubt the incubator will be very keen on it either. For one it
>>>> extracts a META-INF directory which is annoying and for two it
>>>> isn't very friendly to users. I would be much more in favor of
>>>> both a zip/tgz distribution.
>>>>
>>>
>>> It's a self running jar. java -jar cxf-.......jar
>>>
>>> The purpose is that it handles the CR/LF things for windows/unix
>>> without worrying about windows kits builtin on Linux and vice
>>> versa. It also checks the JDK version and other verifications.
>>> Long term, we want to update that with simple "options" that the
>>> installer can ask for. (like "Install JCA support? (Y/n)").
>>>
>>>
>> This makes me nervous as no other projects do it and people are more
>> familiar with zip files.
>
> Huh?
>
Well, do you know of one other apache project that distributes a self
extracting jar? People like zips/tgzs IMO, including me. I didn't even
realize the jar was self extracting until someone told me, so I think
there is at least some truth to my statement.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: Distribution Thoughts
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 16, 2006, at 2:05 PM, Dan Diephouse wrote:
> Daniel Kulp wrote:
>> Dan,
>>
>>
>>> I just downloaded our distribution SNAPSHOT [1] and poked around
>>> a bit.
>>> First let me say, great work - its looking quite good! However, I
>>> think
>>> we need to address a few items before we're ready for a release:
>>>
>>> * Why is it a JAR and not a ZIP/Tgz? I personally don't like
>>> it and
>>> I doubt the incubator will be very keen on it either. For
>>> one it
>>> extracts a META-INF directory which is annoying and for two it
>>> isn't very friendly to users. I would be much more in favor of
>>> both a zip/tgz distribution.
>>>
>>
>> It's a self running jar. java -jar cxf-.......jar
>>
>> The purpose is that it handles the CR/LF things for windows/unix
>> without worrying about windows kits builtin on Linux and vice
>> versa. It also checks the JDK version and other verifications.
>> Long term, we want to update that with simple "options" that the
>> installer can ask for. (like "Install JCA support? (Y/n)").
>>
>>
> This makes me nervous as no other projects do it and people are
> more familiar with zip files.
Huh?
Re: Distribution Thoughts
Posted by Guillaume Nodet <gn...@gmail.com>.
On 10/16/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> Daniel Kulp wrote:
> > Dan,
> >
> >
> >> I just downloaded our distribution SNAPSHOT [1] and poked around a bit.
> >> First let me say, great work - its looking quite good! However, I think
> >> we need to address a few items before we're ready for a release:
> >>
> >> * Why is it a JAR and not a ZIP/Tgz? I personally don't like it and
> >> I doubt the incubator will be very keen on it either. For one it
> >> extracts a META-INF directory which is annoying and for two it
> >> isn't very friendly to users. I would be much more in favor of
> >> both a zip/tgz distribution.
> >>
> >
> > It's a self running jar. java -jar cxf-.......jar
> >
> > The purpose is that it handles the CR/LF things for windows/unix without
> > worrying about windows kits builtin on Linux and vice versa. It also
> > checks the JDK version and other verifications. Long term, we want to
> > update that with simple "options" that the installer can ask for.
> > (like "Install JCA support? (Y/n)").
This is usually what's done with zip + tar.gz distribution
> >
> >
> This makes me nervous as no other projects do it and people are more
> familiar with zip files.
Agreed.
> >> * The archive should expand into the directory
> >> cxf-2.0-incubator-VERSION. Not doing so is highly frowned upon at
> >> Apache. bin, docs, lib, dirs should be include in this directory.
> >>
I would say (if you want Robert Burrel Donkin to -1 the release) that it must
extract in a apache-cxf-2.0-incubator directory.
--
Cheers,
Guillaume Nodet
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
Daniel Kulp wrote:
>Oisin,
>
>On Monday October 16 2006 5:02 pm, Oisin Hurley wrote:
>
>
>>Also in general, people
>>who are working for ISVs that are forming infrastructure bundles
>>for their own products fall into the second camp.
>>
>>
>
>However, these are also the same people that dislike a bundle jar as it
>makes it nearly impossible for them to bundle the "subset" of the
>functionality that they really need. Example, if they want to "remove"
>the JMS code. In anycase, they would already need to copy a BUNCH of
>jars (saaj-*.jar, jaxb*.jar, jaxws-api.jar, etc...) in addition to
>cxf-bundle-2.0-incubator-M1.jar. So, it's a difference of 44 jars
>versus 71 jars right now. (for everything)
>
>
First, if people want to do the module approach they still can - they
just need to include the specific modules they want. Second, most people
won't need all the dependencies, so its most likely a difference of 25
jars instead of 10.
>For that type of user, I think it's best to help them use the tools to
>allow them to "select" the functionality that they need. If they use
>Maven 2, it's easy. If they use Ant, we could help with docs explaining
>how to use the maven2 extensions to ant. If they use Maven and not put
>a dependency on the JMS plugin, the 71 reduces itself by a LOT as all the
>JMS/ActiveMQ/derby/etc... stuff doesn't get sucked in.
>
>
>In anycase, I would "ignore" the bundle jar for now. If a specific use
>case/user request comes in, we can evaluate if it's best to try the
>bundle jar or best to work with the person to use the maven/ant stuff or
>similar. If we never get a request, no harm done.
>
>
You are exhibiting a bit of a bias against the status quo. If we had a
bundle jar and no manifest jar would you feel the same way? How about I
switch the build around and then we wait for a user request?
I'm not saying that we should do that, I'm saying that is not good logic
to put an end to the thread.
Cheers,
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
Re: Distribution Thoughts
Posted by Daniel Kulp <da...@iona.com>.
Oisin,
On Monday October 16 2006 5:02 pm, Oisin Hurley wrote:
> Also in general, people
> who are working for ISVs that are forming infrastructure bundles
> for their own products fall into the second camp.
However, these are also the same people that dislike a bundle jar as it
makes it nearly impossible for them to bundle the "subset" of the
functionality that they really need. Example, if they want to "remove"
the JMS code. In anycase, they would already need to copy a BUNCH of
jars (saaj-*.jar, jaxb*.jar, jaxws-api.jar, etc...) in addition to
cxf-bundle-2.0-incubator-M1.jar. So, it's a difference of 44 jars
versus 71 jars right now. (for everything)
For that type of user, I think it's best to help them use the tools to
allow them to "select" the functionality that they need. If they use
Maven 2, it's easy. If they use Ant, we could help with docs explaining
how to use the maven2 extensions to ant. If they use Maven and not put
a dependency on the JMS plugin, the 71 reduces itself by a LOT as all the
JMS/ActiveMQ/derby/etc... stuff doesn't get sucked in.
In anycase, I would "ignore" the bundle jar for now. If a specific use
case/user request comes in, we can evaluate if it's best to try the
bundle jar or best to work with the person to use the maven/ant stuff or
similar. If we never get a request, no harm done.
Enjoy!
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
I'm fine with whatever for M1, but I think we should evaluate the bundle
approach for M2.
- Dan
Bozhong Lin wrote:
> I agree with Oisin that there are both pros and cons for "manifest
> jar" vs "bundled jar", and we should considering both approaches in
> the medium term. For M1, can we just go ahead with manifest jar
> approach, as users are waiting for M1 and there is barely enough time
> for accommodating both approaches?
>
> I have filed a JIRA for this [1] to be resolved in future milestone.
>
> Regards,
> Bo
>
> Oisin Hurley wrote:
>>
>> On 16 Oct 2006, at 21:30, Daniel Kulp wrote:
>>
>>> 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.
>>
>> I wish I had a dollar for ever time I've been through this
>> 'manifest jar rules', 'manifest jar sucks' argument. I would
>> at least have enough for a round of Vente Skinny Decaf half
>> pump Irish Cream Lattes for the PPMC.
>>
>> There's a number of pros and cons on both sides, and only some of
>> these are actually important to the consumer. Here's the bit where
>> I say 'in my experience':
>>
>> In my experience, there is a phalanx of users that are happy to
>> have a manifest jar as their classpath is small, and they can
>> easily internalize the complete product.
>>
>> In my experience, there is another phalanx of users that bitterly
>> hate manifest jars because they can't find out what is going on.
>>
>> In general people just using the specific technology to make an
>> application fall into the first camp. Also in general, people
>> who are working for ISVs that are forming infrastructure bundles
>> for their own products fall into the second camp. Both of these
>> types of people are important to product/project, so it's a
>> Good Thing not to cause either to be excluded.
>>
>> So, IMHNBO, as a non-committer, would be to consider doing both
>> in the medium term, but for M1 decide what will give a release
>> the best chance to get out ASAP.
>>
>> cheers
>> --oh
>>
>> ----
>> Oisín Hurley
>> +353 1 637 2639
>> http://blogs.iona.com/ohurley
>>
>>
>>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: Distribution Thoughts
Posted by Bozhong Lin <bl...@iona.com>.
I agree with Oisin that there are both pros and cons for "manifest jar"
vs "bundled jar", and we should considering both approaches in the
medium term. For M1, can we just go ahead with manifest jar approach, as
users are waiting for M1 and there is barely enough time for
accommodating both approaches?
I have filed a JIRA for this [1] to be resolved in future milestone.
Regards,
Bo
Oisin Hurley wrote:
>
> On 16 Oct 2006, at 21:30, Daniel Kulp wrote:
>
>> 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.
>
> I wish I had a dollar for ever time I've been through this
> 'manifest jar rules', 'manifest jar sucks' argument. I would
> at least have enough for a round of Vente Skinny Decaf half
> pump Irish Cream Lattes for the PPMC.
>
> There's a number of pros and cons on both sides, and only some of
> these are actually important to the consumer. Here's the bit where
> I say 'in my experience':
>
> In my experience, there is a phalanx of users that are happy to
> have a manifest jar as their classpath is small, and they can
> easily internalize the complete product.
>
> In my experience, there is another phalanx of users that bitterly
> hate manifest jars because they can't find out what is going on.
>
> In general people just using the specific technology to make an
> application fall into the first camp. Also in general, people
> who are working for ISVs that are forming infrastructure bundles
> for their own products fall into the second camp. Both of these
> types of people are important to product/project, so it's a
> Good Thing not to cause either to be excluded.
>
> So, IMHNBO, as a non-committer, would be to consider doing both
> in the medium term, but for M1 decide what will give a release
> the best chance to get out ASAP.
>
> cheers
> --oh
>
> ----
> Oisín Hurley
> +353 1 637 2639
> http://blogs.iona.com/ohurley
>
>
>
Re: Distribution Thoughts
Posted by Oisin Hurley <oh...@iona.com>.
On 16 Oct 2006, at 21:30, Daniel Kulp wrote:
> 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.
I wish I had a dollar for ever time I've been through this
'manifest jar rules', 'manifest jar sucks' argument. I would
at least have enough for a round of Vente Skinny Decaf half
pump Irish Cream Lattes for the PPMC.
There's a number of pros and cons on both sides, and only some of
these are actually important to the consumer. Here's the bit where
I say 'in my experience':
In my experience, there is a phalanx of users that are happy to
have a manifest jar as their classpath is small, and they can
easily internalize the complete product.
In my experience, there is another phalanx of users that bitterly
hate manifest jars because they can't find out what is going on.
In general people just using the specific technology to make an
application fall into the first camp. Also in general, people
who are working for ISVs that are forming infrastructure bundles
for their own products fall into the second camp. Both of these
types of people are important to product/project, so it's a
Good Thing not to cause either to be excluded.
So, IMHNBO, as a non-committer, would be to consider doing both
in the medium term, but for M1 decide what will give a release
the best chance to get out ASAP.
cheers
--oh
----
Oisín Hurley
+353 1 637 2639
http://blogs.iona.com/ohurley
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
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
>>>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.
>
>
>
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
http://netzooid.com
Re: Distribution Thoughts
Posted by Daniel Kulp <da...@iona.com>.
> >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
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
Daniel Kulp wrote:
>Dan,
>
>
>
>>>> * Instead of having cxf-*.jar in lib, I think they should be in
>>>>some other directory like "cxf-individual-modules/" so people don't
>>>>include both the bundled jar and the individual modules.
>>>>
>>>>
>>>Can you get maven to generate the cxf-incubator manifest jar that
>>>points to jars in another directory? If so, I'm OK. At the time
>>>we set this up, that was all we could get it to do.
>>>
>>>
>>Maybe there is some confusion here because I just noticed that the
>>cxf-incubator.jar is only 9K. IMO this should be a bundle of ALL the
>>CXF modules so people only have to use one jar if they want. So I don't
>>see what the manifest has to do with it...
>>
>>
>
>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.
>
>
>>>>* Do we have
>>>>to distribute activemq?
>>>>
>>>>
>>>For the JMS examples to work "out of the box", yes. That said, if
>>>the readme had instructions for obtaining ActiveMQ, I'd be OK as
>>>well.
>>>
>>>
>>Shouldn't the examples work with just the jars? I don't see any reason
>>why we need a complete copy of the activemq-3.2. We should just be able
>>to use the in memory broker. It would be nice to have the activemq
>>specific jars in an activemq directory/ as it really clutters our
>>dependency list.
>>
>>
>
>It is just the jars, isn't it? There are a few config files (to
>configure activemq to use the correct broker and queues and such) in
>lib/activemq, but not much else.
>
>
>
I thought I saw start/stop scripts as well...
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
Re: Distribution Thoughts
Posted by Daniel Kulp <da...@iona.com>.
Dan,
> >> * Instead of having cxf-*.jar in lib, I think they should be in
> >> some other directory like "cxf-individual-modules/" so people don't
> >> include both the bundled jar and the individual modules.
> >
> > Can you get maven to generate the cxf-incubator manifest jar that
> > points to jars in another directory? If so, I'm OK. At the time
> > we set this up, that was all we could get it to do.
>
> Maybe there is some confusion here because I just noticed that the
> cxf-incubator.jar is only 9K. IMO this should be a bundle of ALL the
> CXF modules so people only have to use one jar if they want. So I don't
> see what the manifest has to do with it...
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.
> >> * Do we have
> >> to distribute activemq?
> > For the JMS examples to work "out of the box", yes. That said, if
> > the readme had instructions for obtaining ActiveMQ, I'd be OK as
> > well.
>
> Shouldn't the examples work with just the jars? I don't see any reason
> why we need a complete copy of the activemq-3.2. We should just be able
> to use the in memory broker. It would be nice to have the activemq
> specific jars in an activemq directory/ as it really clutters our
> dependency list.
It is just the jars, isn't it? There are a few config files (to
configure activemq to use the correct broker and queues and such) in
lib/activemq, but not much else.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Distribution Thoughts
Posted by Dan Diephouse <da...@envoisolutions.com>.
Daniel Kulp wrote:
> Dan,
>
>
>> I just downloaded our distribution SNAPSHOT [1] and poked around a bit.
>> First let me say, great work - its looking quite good! However, I think
>> we need to address a few items before we're ready for a release:
>>
>> * Why is it a JAR and not a ZIP/Tgz? I personally don't like it and
>> I doubt the incubator will be very keen on it either. For one it
>> extracts a META-INF directory which is annoying and for two it
>> isn't very friendly to users. I would be much more in favor of
>> both a zip/tgz distribution.
>>
>
> It's a self running jar. java -jar cxf-.......jar
>
> The purpose is that it handles the CR/LF things for windows/unix without
> worrying about windows kits builtin on Linux and vice versa. It also
> checks the JDK version and other verifications. Long term, we want to
> update that with simple "options" that the installer can ask for.
> (like "Install JCA support? (Y/n)").
>
>
This makes me nervous as no other projects do it and people are more
familiar with zip files.
>> * The archive should expand into the directory
>> cxf-2.0-incubator-VERSION. Not doing so is highly frowned upon at
>> Apache. bin, docs, lib, dirs should be include in this directory.
>>
>
> I need to check the new versions of the maven assembly plugin. For a
> while, this was NOT easy to do with the assembly plugin. When the
> version number changed, we'd have to edit the assembly as well as the pom
> properties were not available in the assembly. I don't know if that
> has changed yet or not.
>
>
I was able to do it with XFire:
<execution>
<id>bin</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
<configuration>
<descriptor>assembly.xml</descriptor>
<finalName>xfire-${version}</finalName>
<outputDirectory>target/distro</outputDirectory>
<workDirectory>target/work</workDirectory>
</configuration>
</execution>
>
>
>> * I'm very wary about not putting a version # on cxf-incubator.jar.
>> I don't think the incubator will like it and I don't buy the
>> argument about having build scripts depending on
>> cxf-incubator.jar and having to change the version # every time. People
>> can always include cxf-incubator-*.jar from ant to pick up any version
>> or they can copy cxf-2.0-incubator-M1-SNAPSHOT to cxf.jar
>>
>
> It's not ANT/Maven that I worry too much about. It's shell scripts
> and "startup" scripts that are usually the problems. Many of those
> WON'T expand a "*".
>
> It SHOULDN'T be a problem since many of the non-maven incubator projects
> (or apache projects) don't put the version number in. Example: woden
> doesn't, wsdl4j doesn't, xerces doesn't, xalan doesn't, etc...
>
>
>
Yes, and I hate it when they don't include the version #.
>> * Instead of having cxf-*.jar in lib, I think they should be in
>> some other directory like "cxf-individual-modules/" so people don't
>> include both the bundled jar and the individual modules.
>>
>
> Can you get maven to generate the cxf-incubator manifest jar that points
> to jars in another directory? If so, I'm OK. At the time we set this
> up, that was all we could get it to do.
>
>
Maybe there is some confusion here because I just noticed that the
cxf-incubator.jar is only 9K. IMO this should be a bundle of ALL the CXF
modules so people only have to use one jar if they want. So I don't see
what the manifest has to do with it...
I had to manually exclude all the xfire-foo jars and include xfire-all
in one assembly run. Then I had to have another assembly run with only
xfire-* being copied to modules/.
>> * Do we have
>> to distribute activemq?
>>
>
> For the JMS examples to work "out of the box", yes. That said, if the
> readme had instructions for obtaining ActiveMQ, I'd be OK as well.
>
Shouldn't the examples work with just the jars? I don't see any reason
why we need a complete copy of the activemq-3.2. We should just be able
to use the in memory broker. It would be nice to have the activemq
specific jars in an activemq directory/ as it really clutters our
dependency list.
>> * Why is XMLBeans 2.1.0 included?
>>
> * Why are maven-* and wagon included?
>
> These are sucked in from the dependency on the maven plugin. That said,
> the bin distribution doesn't need the maven plugin packaged with it.
>
>
Where is the maven plugin included?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: Distribution Thoughts
Posted by Daniel Kulp <da...@iona.com>.
>
> > * Why are maven-* and wagon included?
> > * Why is XMLBeans 2.1.0 included?
>
> These are sucked in from the dependency on the maven plugin. That
> said, the bin distribution doesn't need the maven plugin packaged with
> it.
Actually, I'm semi-wrong on this. The common/xsd module has a direct
dependency on the maven things. I have a fix for that by marking
them "provided" so they won't be included.
XMLBeans is sucked in for the javascript stuff for some reason. Someone
who knows more about that frontend would need to explain why.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Distribution Thoughts
Posted by Daniel Kulp <da...@iona.com>.
Dan,
> I just downloaded our distribution SNAPSHOT [1] and poked around a bit.
> First let me say, great work - its looking quite good! However, I think
> we need to address a few items before we're ready for a release:
>
> * Why is it a JAR and not a ZIP/Tgz? I personally don't like it and
> I doubt the incubator will be very keen on it either. For one it
> extracts a META-INF directory which is annoying and for two it
> isn't very friendly to users. I would be much more in favor of
> both a zip/tgz distribution.
It's a self running jar. java -jar cxf-.......jar
The purpose is that it handles the CR/LF things for windows/unix without
worrying about windows kits builtin on Linux and vice versa. It also
checks the JDK version and other verifications. Long term, we want to
update that with simple "options" that the installer can ask for.
(like "Install JCA support? (Y/n)").
> * The archive should expand into the directory
> cxf-2.0-incubator-VERSION. Not doing so is highly frowned upon at
> Apache. bin, docs, lib, dirs should be include in this directory.
I need to check the new versions of the maven assembly plugin. For a
while, this was NOT easy to do with the assembly plugin. When the
version number changed, we'd have to edit the assembly as well as the pom
properties were not available in the assembly. I don't know if that
has changed yet or not.
> * Whats the cxfinstaller for?
That's the installer. See point (1).
> * I'm very wary about not putting a version # on cxf-incubator.jar.
> I don't think the incubator will like it and I don't buy the
> argument about having build scripts depending on
> cxf-incubator.jar and having to change the version # every time. People
> can always include cxf-incubator-*.jar from ant to pick up any version
> or they can copy cxf-2.0-incubator-M1-SNAPSHOT to cxf.jar
It's not ANT/Maven that I worry too much about. It's shell scripts
and "startup" scripts that are usually the problems. Many of those
WON'T expand a "*".
It SHOULDN'T be a problem since many of the non-maven incubator projects
(or apache projects) don't put the version number in. Example: woden
doesn't, wsdl4j doesn't, xerces doesn't, xalan doesn't, etc...
> * Instead of having cxf-*.jar in lib, I think they should be in
> some other directory like "cxf-individual-modules/" so people don't
> include both the bundled jar and the individual modules.
Can you get maven to generate the cxf-incubator manifest jar that points
to jars in another directory? If so, I'm OK. At the time we set this
up, that was all we could get it to do.
> * Do we have
> to distribute activemq?
For the JMS examples to work "out of the box", yes. That said, if the
readme had instructions for obtaining ActiveMQ, I'd be OK as well.
> * avalon-framework isn't being properly excluded
> * XmlSchema needs to be updated to version 1.1
Just update the top level pom.xml files for those and retest.
> * Why is concurrent included?
The activemq dependency sucks that in.
> * Why is Velocity included?
Code gens need velocity.
> * Why are maven-* and wagon included?
> * Why is XMLBeans 2.1.0 included?
These are sucked in from the dependency on the maven plugin. That said,
the bin distribution doesn't need the maven plugin packaged with it.
Enjoy!
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com