You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by tog <gu...@gmail.com> on 2007/03/26 21:06:54 UTC
cxf packaging
Hi folks
Thanks a lot for all the work you have done so far. I am enthousiastic user.
My goal is to link cxf with a dynamic languages namely Groovy. Among the
difficulty I currently have is the selection of jar files would it be
possible to have different kind of packaging for example (this is only a
proposal) a full jarfile (including dependencies) cxf-all.jar, a minimum jar
file (not including the dependencies) for example based on aegis. Of course
this does not prevent you to propose the single jars. Such jars will ease
the integration and does not require much additional effort.
Best Regards
Guillaume
--
<a target="_blank"
href="http://www.google.com/calendar/render?cid=guillaume.alleon%40gmail.com
"><img src="http://www.google.com/calendar/images/ext/gc_button1_en.gif"
border=0></a>
Re: cxf packaging
Posted by Bozhong Lin <bl...@iona.com>.
We probably will be able to resolve 1) issue if current
shade-maven-plugin is improved to support resources merge through plugin
configuration, the 2) issue can probably be worked around around also.
However, we do have another issue: how are we going to generate manifest
jar with cxf modules jars and third-party jars located in two different
directories? anyone has any idea on manifest jar creation under this
situation?
Thankss,
Bo
Daniel Kulp wrote:
> Just to bring up a complication that Dan and I kind of thought about
> yesterday:
>
> 1) What will happen with all the files that are in "multiple modules".
> I'm thinking about the files like:
> META-INF/cxf/cxf-property-editors.xml
> META-INF/tools-plugin.xml
> META-INF/spring.handlers
> etc....
>
> Those will all need to be merged together. That's not going to be fun
> and will definitely be a maintenence issue if it's not something that
> can be automated.
>
>
> 2) The NOTICE file for the bundle will also need to be a merge of the
> automated NOTICE as well as all the appended information.
>
>
> Dan
>
>
>
> On Thursday 29 March 2007 06:40, Bozhong Lin wrote:
>
>> I still have fresh memory that we had long discussion about
>> manifest.jar vs bundle.jar right before M1 release. I guess it must be
>> time for another milestone release, thus the discussion of packaging
>> again. :-)
>>
>> By observing all discussions happened on this topic, I would like to
>> propose a packaging solution that satisfies both sides of world
>> (manifest.jar and bundle.jar):
>>
>> -- "lib" directory containing
>> cxf-bundle.jar
>> other-third-party dependency jars, such as saaj.jar
>> a manifest jar
>> -- "modules" directory containing
>> cxf-*.jar
>>
>> Would this work for everyone?
>>
>> Cheers,
>> Bo
>>
>> Dan Diephouse wrote:
>>
>>> On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
>>>
>>>>> Ted, maybe we haven't been clear in what we mean by single jar.
>>>>>
>>>> That's what I get for wandering into the middle of a conversation.
>>>> Thanks
>>>> for not pointing out the obvious stupidity on the part of the guy
>>>> who didn't
>>>> read through the entire thread. ;-)
>>>>
>>>>
>>>>> So given that, what's so bad about one cxf jar file? With regards
>>>>> to update, the same rules apply as with any other project. You
>>>>> check the release notes and decide if you want the new version or
>>>>> not. This has nothing to do with multiple jars, as they don't rev
>>>>> independently of each other (and if they did, then sure, they
>>>>> should be separate jars).
>>>>>
>>>> I guess I have to fall back on the aesthetic principle of
>>>> modularity. I agree with Dan's earlier statement that he's seen
>>>> projects that used a monolithic jar/.exe/artifact approach that
>>>> allowed deep "tangling" to take
>>>> place over time--I've seen the same.
>>>>
>>>> That said, though, how hard would it be to keep them in separate
>>>> jars in the
>>>> development cycle, to help enforce that kind of modularity, and
>>>> just have
>>>> an
>>>> Ant task stitch them together into a single jar as part of the
>>>> release process? This doesn't seem like a major showstopper to me.
>>>>
>>> I believe thats what we're proposing. We'd still want to use Maven
>>> for the
>>> individual modules and to encourage modularity. We'd just package up
>>> most of
>>> the modules into one jar for users to use instead of having to
>>> manage 8 or 9
>>> cxf-*.jars
>>>
>>> - Dan
>>>
>
>
Re: cxf packaging
Posted by Daniel Kulp <dk...@apache.org>.
Just to bring up a complication that Dan and I kind of thought about
yesterday:
1) What will happen with all the files that are in "multiple modules".
I'm thinking about the files like:
META-INF/cxf/cxf-property-editors.xml
META-INF/tools-plugin.xml
META-INF/spring.handlers
etc....
Those will all need to be merged together. That's not going to be fun
and will definitely be a maintenence issue if it's not something that
can be automated.
2) The NOTICE file for the bundle will also need to be a merge of the
automated NOTICE as well as all the appended information.
Dan
On Thursday 29 March 2007 06:40, Bozhong Lin wrote:
> I still have fresh memory that we had long discussion about
> manifest.jar vs bundle.jar right before M1 release. I guess it must be
> time for another milestone release, thus the discussion of packaging
> again. :-)
>
> By observing all discussions happened on this topic, I would like to
> propose a packaging solution that satisfies both sides of world
> (manifest.jar and bundle.jar):
>
> -- "lib" directory containing
> cxf-bundle.jar
> other-third-party dependency jars, such as saaj.jar
> a manifest jar
> -- "modules" directory containing
> cxf-*.jar
>
> Would this work for everyone?
>
> Cheers,
> Bo
>
> Dan Diephouse wrote:
> > On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
> >> > Ted, maybe we haven't been clear in what we mean by single jar.
> >>
> >> That's what I get for wandering into the middle of a conversation.
> >> Thanks
> >> for not pointing out the obvious stupidity on the part of the guy
> >> who didn't
> >> read through the entire thread. ;-)
> >>
> >> > So given that, what's so bad about one cxf jar file? With regards
> >> > to update, the same rules apply as with any other project. You
> >> > check the release notes and decide if you want the new version or
> >> > not. This has nothing to do with multiple jars, as they don't rev
> >> > independently of each other (and if they did, then sure, they
> >> > should be separate jars).
> >>
> >> I guess I have to fall back on the aesthetic principle of
> >> modularity. I agree with Dan's earlier statement that he's seen
> >> projects that used a monolithic jar/.exe/artifact approach that
> >> allowed deep "tangling" to take
> >> place over time--I've seen the same.
> >>
> >> That said, though, how hard would it be to keep them in separate
> >> jars in the
> >> development cycle, to help enforce that kind of modularity, and
> >> just have
> >> an
> >> Ant task stitch them together into a single jar as part of the
> >> release process? This doesn't seem like a major showstopper to me.
> >
> > I believe thats what we're proposing. We'd still want to use Maven
> > for the
> > individual modules and to encourage modularity. We'd just package up
> > most of
> > the modules into one jar for users to use instead of having to
> > manage 8 or 9
> > cxf-*.jars
> >
> > - Dan
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
I think this would be good, but I would request the following modifications
1. Name cxf-bundle.jar cxf-incubator-VERSION.jar
2. Name the manifest jar cxf-incubator-manifest-VERSION.jar and put it in
the modules directory.
3. For the bundle jar, include everything except JCA, JBI, *tests, xjc
plugins, and testutils (hopefully I didn't miss any)
Regards,
- Dan
On 3/29/07, Bozhong Lin <bl...@iona.com> wrote:
>
> I still have fresh memory that we had long discussion about manifest.jar
> vs bundle.jar right before M1 release. I guess it must be time for
> another milestone release, thus the discussion of packaging again. :-)
>
> By observing all discussions happened on this topic, I would like to
> propose a packaging solution that satisfies both sides of world
> (manifest.jar and bundle.jar):
>
> -- "lib" directory containing
> cxf-bundle.jar
> other-third-party dependency jars, such as saaj.jar
> a manifest jar
> -- "modules" directory containing
> cxf-*.jar
>
> Would this work for everyone?
>
> Cheers,
> Bo
>
> Dan Diephouse wrote:
> > On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
> >>
> >> > Ted, maybe we haven't been clear in what we mean by single jar.
> >> >
> >> That's what I get for wandering into the middle of a conversation.
> >> Thanks
> >> for not pointing out the obvious stupidity on the part of the guy who
> >> didn't
> >> read through the entire thread. ;-)
> >>
> >> > So given that, what's so bad about one cxf jar file? With regards to
> >> > update, the same rules apply as with any other project. You check the
> >> > release notes and decide if you want the new version or not. This has
> >> > nothing to do with multiple jars, as they don't rev independently of
> >> > each other (and if they did, then sure, they should be separate
> jars).
> >> >
> >> I guess I have to fall back on the aesthetic principle of modularity. I
> >> agree with Dan's earlier statement that he's seen projects that used a
> >> monolithic jar/.exe/artifact approach that allowed deep "tangling" to
> >> take
> >> place over time--I've seen the same.
> >>
> >> That said, though, how hard would it be to keep them in separate jars
> in
> >> the
> >> development cycle, to help enforce that kind of modularity, and just
> >> have
> >> an
> >> Ant task stitch them together into a single jar as part of the release
> >> process? This doesn't seem like a major showstopper to me.
> >
> >
> > I believe thats what we're proposing. We'd still want to use Maven for
> > the
> > individual modules and to encourage modularity. We'd just package up
> > most of
> > the modules into one jar for users to use instead of having to manage
> > 8 or 9
> > cxf-*.jars
> >
> > - Dan
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: cxf packaging
Posted by Bozhong Lin <bl...@iona.com>.
We are not going to use cxf-bundle.jar name, I was just using that to
illustrate the point.
Thanks,
Bo
Hani Suleiman wrote:
> Yes this would be good, though I have two minor comments:
>
> - Why -bundle extension? No other project uses this naming format.
> What's so bad about just cxf.jar?
> - It's worth distinguishing this as a top level artifact rather than
> another dependency, so it'd be better if it lived in the top level
> directory rather than the lib dir.
>
> Either way, both very minor points, but since we're this close to
> reaching agreement, figured it's worth suggesting!
>
> On Mar 30, 2007, at 12:33 AM, Bharath Ganesh wrote:
>
>> Yes that looks fine.
>>
>> On 3/29/07, Bozhong Lin <bl...@iona.com> wrote:
>>>
>>> I still have fresh memory that we had long discussion about
>>> manifest.jar
>>> vs bundle.jar right before M1 release. I guess it must be time for
>>> another milestone release, thus the discussion of packaging again. :-)
>>>
>>> By observing all discussions happened on this topic, I would like to
>>> propose a packaging solution that satisfies both sides of world
>>> (manifest.jar and bundle.jar):
>>>
>>> -- "lib" directory containing
>>> cxf-bundle.jar
>>> other-third-party dependency jars, such as saaj.jar
>>> a manifest jar
>>> -- "modules" directory containing
>>> cxf-*.jar
>>>
>>> Would this work for everyone?
>>>
>>> Cheers,
>>> Bo
>>>
>>> Dan Diephouse wrote:
>>> > On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
>>> >>
>>> >> > Ted, maybe we haven't been clear in what we mean by single jar.
>>> >> >
>>> >> That's what I get for wandering into the middle of a conversation.
>>> >> Thanks
>>> >> for not pointing out the obvious stupidity on the part of the guy
>>> who
>>> >> didn't
>>> >> read through the entire thread. ;-)
>>> >>
>>> >> > So given that, what's so bad about one cxf jar file? With
>>> regards to
>>> >> > update, the same rules apply as with any other project. You
>>> check the
>>> >> > release notes and decide if you want the new version or not.
>>> This has
>>> >> > nothing to do with multiple jars, as they don't rev
>>> independently of
>>> >> > each other (and if they did, then sure, they should be separate
>>> jars).
>>> >> >
>>> >> I guess I have to fall back on the aesthetic principle of
>>> modularity. I
>>> >> agree with Dan's earlier statement that he's seen projects that
>>> used a
>>> >> monolithic jar/.exe/artifact approach that allowed deep
>>> "tangling" to
>>> >> take
>>> >> place over time--I've seen the same.
>>> >>
>>> >> That said, though, how hard would it be to keep them in separate
>>> jars
>>> in
>>> >> the
>>> >> development cycle, to help enforce that kind of modularity, and just
>>> >> have
>>> >> an
>>> >> Ant task stitch them together into a single jar as part of the
>>> release
>>> >> process? This doesn't seem like a major showstopper to me.
>>> >
>>> >
>>> > I believe thats what we're proposing. We'd still want to use Maven
>>> for
>>> > the
>>> > individual modules and to encourage modularity. We'd just package up
>>> > most of
>>> > the modules into one jar for users to use instead of having to manage
>>> > 8 or 9
>>> > cxf-*.jars
>>> >
>>> > - Dan
>>> >
>>>
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
Yes this would be good, though I have two minor comments:
- Why -bundle extension? No other project uses this naming format.
What's so bad about just cxf.jar?
- It's worth distinguishing this as a top level artifact rather than
another dependency, so it'd be better if it lived in the top level
directory rather than the lib dir.
Either way, both very minor points, but since we're this close to
reaching agreement, figured it's worth suggesting!
On Mar 30, 2007, at 12:33 AM, Bharath Ganesh wrote:
> Yes that looks fine.
>
> On 3/29/07, Bozhong Lin <bl...@iona.com> wrote:
>>
>> I still have fresh memory that we had long discussion about
>> manifest.jar
>> vs bundle.jar right before M1 release. I guess it must be time for
>> another milestone release, thus the discussion of packaging
>> again. :-)
>>
>> By observing all discussions happened on this topic, I would like to
>> propose a packaging solution that satisfies both sides of world
>> (manifest.jar and bundle.jar):
>>
>> -- "lib" directory containing
>> cxf-bundle.jar
>> other-third-party dependency jars, such as saaj.jar
>> a manifest jar
>> -- "modules" directory containing
>> cxf-*.jar
>>
>> Would this work for everyone?
>>
>> Cheers,
>> Bo
>>
>> Dan Diephouse wrote:
>> > On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
>> >>
>> >> > Ted, maybe we haven't been clear in what we mean by single jar.
>> >> >
>> >> That's what I get for wandering into the middle of a conversation.
>> >> Thanks
>> >> for not pointing out the obvious stupidity on the part of the
>> guy who
>> >> didn't
>> >> read through the entire thread. ;-)
>> >>
>> >> > So given that, what's so bad about one cxf jar file? With
>> regards to
>> >> > update, the same rules apply as with any other project. You
>> check the
>> >> > release notes and decide if you want the new version or not.
>> This has
>> >> > nothing to do with multiple jars, as they don't rev
>> independently of
>> >> > each other (and if they did, then sure, they should be separate
>> jars).
>> >> >
>> >> I guess I have to fall back on the aesthetic principle of
>> modularity. I
>> >> agree with Dan's earlier statement that he's seen projects that
>> used a
>> >> monolithic jar/.exe/artifact approach that allowed deep
>> "tangling" to
>> >> take
>> >> place over time--I've seen the same.
>> >>
>> >> That said, though, how hard would it be to keep them in
>> separate jars
>> in
>> >> the
>> >> development cycle, to help enforce that kind of modularity, and
>> just
>> >> have
>> >> an
>> >> Ant task stitch them together into a single jar as part of the
>> release
>> >> process? This doesn't seem like a major showstopper to me.
>> >
>> >
>> > I believe thats what we're proposing. We'd still want to use
>> Maven for
>> > the
>> > individual modules and to encourage modularity. We'd just
>> package up
>> > most of
>> > the modules into one jar for users to use instead of having to
>> manage
>> > 8 or 9
>> > cxf-*.jars
>> >
>> > - Dan
>> >
>>
Re: cxf packaging
Posted by Bharath Ganesh <bh...@gmail.com>.
Yes that looks fine.
On 3/29/07, Bozhong Lin <bl...@iona.com> wrote:
>
> I still have fresh memory that we had long discussion about manifest.jar
> vs bundle.jar right before M1 release. I guess it must be time for
> another milestone release, thus the discussion of packaging again. :-)
>
> By observing all discussions happened on this topic, I would like to
> propose a packaging solution that satisfies both sides of world
> (manifest.jar and bundle.jar):
>
> -- "lib" directory containing
> cxf-bundle.jar
> other-third-party dependency jars, such as saaj.jar
> a manifest jar
> -- "modules" directory containing
> cxf-*.jar
>
> Would this work for everyone?
>
> Cheers,
> Bo
>
> Dan Diephouse wrote:
> > On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
> >>
> >> > Ted, maybe we haven't been clear in what we mean by single jar.
> >> >
> >> That's what I get for wandering into the middle of a conversation.
> >> Thanks
> >> for not pointing out the obvious stupidity on the part of the guy who
> >> didn't
> >> read through the entire thread. ;-)
> >>
> >> > So given that, what's so bad about one cxf jar file? With regards to
> >> > update, the same rules apply as with any other project. You check the
> >> > release notes and decide if you want the new version or not. This has
> >> > nothing to do with multiple jars, as they don't rev independently of
> >> > each other (and if they did, then sure, they should be separate
> jars).
> >> >
> >> I guess I have to fall back on the aesthetic principle of modularity. I
> >> agree with Dan's earlier statement that he's seen projects that used a
> >> monolithic jar/.exe/artifact approach that allowed deep "tangling" to
> >> take
> >> place over time--I've seen the same.
> >>
> >> That said, though, how hard would it be to keep them in separate jars
> in
> >> the
> >> development cycle, to help enforce that kind of modularity, and just
> >> have
> >> an
> >> Ant task stitch them together into a single jar as part of the release
> >> process? This doesn't seem like a major showstopper to me.
> >
> >
> > I believe thats what we're proposing. We'd still want to use Maven for
> > the
> > individual modules and to encourage modularity. We'd just package up
> > most of
> > the modules into one jar for users to use instead of having to manage
> > 8 or 9
> > cxf-*.jars
> >
> > - Dan
> >
>
Re: cxf packaging
Posted by Bozhong Lin <bl...@iona.com>.
I still have fresh memory that we had long discussion about manifest.jar
vs bundle.jar right before M1 release. I guess it must be time for
another milestone release, thus the discussion of packaging again. :-)
By observing all discussions happened on this topic, I would like to
propose a packaging solution that satisfies both sides of world
(manifest.jar and bundle.jar):
-- "lib" directory containing
cxf-bundle.jar
other-third-party dependency jars, such as saaj.jar
a manifest jar
-- "modules" directory containing
cxf-*.jar
Would this work for everyone?
Cheers,
Bo
Dan Diephouse wrote:
> On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
>>
>> > Ted, maybe we haven't been clear in what we mean by single jar.
>> >
>> That's what I get for wandering into the middle of a conversation.
>> Thanks
>> for not pointing out the obvious stupidity on the part of the guy who
>> didn't
>> read through the entire thread. ;-)
>>
>> > So given that, what's so bad about one cxf jar file? With regards to
>> > update, the same rules apply as with any other project. You check the
>> > release notes and decide if you want the new version or not. This has
>> > nothing to do with multiple jars, as they don't rev independently of
>> > each other (and if they did, then sure, they should be separate jars).
>> >
>> I guess I have to fall back on the aesthetic principle of modularity. I
>> agree with Dan's earlier statement that he's seen projects that used a
>> monolithic jar/.exe/artifact approach that allowed deep "tangling" to
>> take
>> place over time--I've seen the same.
>>
>> That said, though, how hard would it be to keep them in separate jars in
>> the
>> development cycle, to help enforce that kind of modularity, and just
>> have
>> an
>> Ant task stitch them together into a single jar as part of the release
>> process? This doesn't seem like a major showstopper to me.
>
>
> I believe thats what we're proposing. We'd still want to use Maven for
> the
> individual modules and to encourage modularity. We'd just package up
> most of
> the modules into one jar for users to use instead of having to manage
> 8 or 9
> cxf-*.jars
>
> - Dan
>
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/27/07, Ted Neward <te...@tedneward.com> wrote:
>
> > Ted, maybe we haven't been clear in what we mean by single jar.
> >
> That's what I get for wandering into the middle of a conversation. Thanks
> for not pointing out the obvious stupidity on the part of the guy who
> didn't
> read through the entire thread. ;-)
>
> > So given that, what's so bad about one cxf jar file? With regards to
> > update, the same rules apply as with any other project. You check the
> > release notes and decide if you want the new version or not. This has
> > nothing to do with multiple jars, as they don't rev independently of
> > each other (and if they did, then sure, they should be separate jars).
> >
> I guess I have to fall back on the aesthetic principle of modularity. I
> agree with Dan's earlier statement that he's seen projects that used a
> monolithic jar/.exe/artifact approach that allowed deep "tangling" to take
> place over time--I've seen the same.
>
> That said, though, how hard would it be to keep them in separate jars in
> the
> development cycle, to help enforce that kind of modularity, and just have
> an
> Ant task stitch them together into a single jar as part of the release
> process? This doesn't seem like a major showstopper to me.
I believe thats what we're proposing. We'd still want to use Maven for the
individual modules and to encourage modularity. We'd just package up most of
the modules into one jar for users to use instead of having to manage 8 or 9
cxf-*.jars
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: cxf packaging
Posted by Ted Neward <te...@tedneward.com>.
> Ted, maybe we haven't been clear in what we mean by single jar.
>
That's what I get for wandering into the middle of a conversation. Thanks
for not pointing out the obvious stupidity on the part of the guy who didn't
read through the entire thread. ;-)
> So given that, what's so bad about one cxf jar file? With regards to
> update, the same rules apply as with any other project. You check the
> release notes and decide if you want the new version or not. This has
> nothing to do with multiple jars, as they don't rev independently of
> each other (and if they did, then sure, they should be separate jars).
>
I guess I have to fall back on the aesthetic principle of modularity. I
agree with Dan's earlier statement that he's seen projects that used a
monolithic jar/.exe/artifact approach that allowed deep "tangling" to take
place over time--I've seen the same.
That said, though, how hard would it be to keep them in separate jars in the
development cycle, to help enforce that kind of modularity, and just have an
Ant task stitch them together into a single jar as part of the release
process? This doesn't seem like a major showstopper to me.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> -----Original Message-----
> From: Hani Suleiman [mailto:hani@formicary.net]
> Sent: Tuesday, March 27, 2007 9:35 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: cxf packaging
>
>
> On Mar 27, 2007, at 12:28 PM, Ted Neward wrote:
>
> >>> 1) CXF developers - basically, the folks on cxf-dev that are in the
> >>> core
> >>> writing stuff.
> >>>
> > Who need to keep their heads wrapped around what they're doing.
> >
> >>> 2) Basic "end user" type folks. Most of these are happy with the
> >>> JAX-WS
> >>> specification or the other "basic" info we have up on the Wiki.
> >>> (Well,
> >>> the stuff that Dan is working on getting on the wiki. More work is
> >>> needed on this front.)
> >>>
> >> Yes, and being in that category, I don't want to add 8 cxf jars. It's
> >> an irritating barrier to adoption. Does a single user on this list
> >> think this is a good idea? Please speak up if you *want* dozens of
> >> jars.
> >>
> > Do I want "dozens" of jars? Not really. But let's not over-
> > exaggerate the
> > situation here--how painful is it, really, to add eight entries to
> > an Ant
> > script? You prefer "bloated monolithic" jars to "dozens of jars",
> > Hani?
> > (Note the deliberate use of the perjorative here to try and point
> > out that
> > it's easy to skew a question to generate the answer the questioner
> > wants.)
>
> Ted, maybe we haven't been clear in what we mean by single jar. The
> proposed jar does not contain ANY dependencies, nothing external. You
> still need to have jaxb, stax, and whatever other dependencies cxf
> has. The issue is just that cxf specific artifacts (or a useful
> subset) should go into a single jar. They're all under the same
> license, developed by the same people, in the same source repo, with
> the same release schedule. You'd never mix and match versions or want
> to swap one out for another.
>
> So given that, what's so bad about one cxf jar file? With regards to
> update, the same rules apply as with any other project. You check the
> release notes and decide if you want the new version or not. This has
> nothing to do with multiple jars, as they don't rev independently of
> each other (and if they did, then sure, they should be separate jars).
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007
> 2:31 PM
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007
2:31 PM
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 12:28 PM, Ted Neward wrote:
>>> 1) CXF developers - basically, the folks on cxf-dev that are in the
>>> core
>>> writing stuff.
>>>
> Who need to keep their heads wrapped around what they're doing.
>
>>> 2) Basic "end user" type folks. Most of these are happy with the
>>> JAX-WS
>>> specification or the other "basic" info we have up on the Wiki.
>>> (Well,
>>> the stuff that Dan is working on getting on the wiki. More work is
>>> needed on this front.)
>>>
>> Yes, and being in that category, I don't want to add 8 cxf jars. It's
>> an irritating barrier to adoption. Does a single user on this list
>> think this is a good idea? Please speak up if you *want* dozens of
>> jars.
>>
> Do I want "dozens" of jars? Not really. But let's not over-
> exaggerate the
> situation here--how painful is it, really, to add eight entries to
> an Ant
> script? You prefer "bloated monolithic" jars to "dozens of jars",
> Hani?
> (Note the deliberate use of the perjorative here to try and point
> out that
> it's easy to skew a question to generate the answer the questioner
> wants.)
Ted, maybe we haven't been clear in what we mean by single jar. The
proposed jar does not contain ANY dependencies, nothing external. You
still need to have jaxb, stax, and whatever other dependencies cxf
has. The issue is just that cxf specific artifacts (or a useful
subset) should go into a single jar. They're all under the same
license, developed by the same people, in the same source repo, with
the same release schedule. You'd never mix and match versions or want
to swap one out for another.
So given that, what's so bad about one cxf jar file? With regards to
update, the same rules apply as with any other project. You check the
release notes and decide if you want the new version or not. This has
nothing to do with multiple jars, as they don't rev independently of
each other (and if they did, then sure, they should be separate jars).
RE: cxf packaging
Posted by Ted Neward <te...@tedneward.com>.
> > 1) CXF developers - basically, the folks on cxf-dev that are in the
> > core
> > writing stuff.
> >
Who need to keep their heads wrapped around what they're doing.
> > 2) Basic "end user" type folks. Most of these are happy with the
> > JAX-WS
> > specification or the other "basic" info we have up on the Wiki.
> > (Well,
> > the stuff that Dan is working on getting on the wiki. More work is
> > needed on this front.)
> >
> Yes, and being in that category, I don't want to add 8 cxf jars. It's
> an irritating barrier to adoption. Does a single user on this list
> think this is a good idea? Please speak up if you *want* dozens of jars.
>
Do I want "dozens" of jars? Not really. But let's not over-exaggerate the
situation here--how painful is it, really, to add eight entries to an Ant
script? You prefer "bloated monolithic" jars to "dozens of jars", Hani?
(Note the deliberate use of the perjorative here to try and point out that
it's easy to skew a question to generate the answer the questioner wants.)
Besides which, there's the larger problem of:
(*) licensing (do you have permission to redistribute any dependencies in
your single monolithic jar?)
(*) compartmentalization (do I really want to replace the monolithic jar
every time you make a change to something I don't use in Celtix?)
(*) componentization (do I really want to have to choose between
combinatorial monolithic jars containing the various options? JAXB/Jetty vs.
JAXB/Tomcat vs. ...)
(*) versioning (what if the monolithic jar is using a different version of
JAXB than I am elsewhere in my code?)
Breaking things up offers potential solutions to all of these problems, at
the cost of having to add eight entries to the <classpath> node in your
build.xml.
> > 3) Advanced developers - these are the folks that are writing
> > interceptors, writing new bindings/transports, etc.... For these
> > folks, the javadocs in "api" are the important things.
> >
> You honestly think that these developers won't know that a package
> called 'internal' or 'impl' is not public, even if that's documented?
>
This to me is a red herring issue. Advanced developers will tune the
environment to suit their needs/build process, regadless of what's done by
the CXF team.
> In the 3 groups above, there are sometimes conflicting needs. Right
> now it looks like the people most catered to in terms of packaging
> are the first group, which seems a bit...odd.
>
If that were the only reason, I'd agree with you. But I happen to think that
monolithic jars are a bad idea, so I'll disagree with the idea that CXF
should use a monolithic jar.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> -----Original Message-----
> From: Hani Suleiman [mailto:hani@formicary.net]
> Sent: Tuesday, March 27, 2007 6:55 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: cxf packaging
>
> On Mar 27, 2007, at 9:47 AM, Daniel Kulp wrote:
>
> > It makes dependency management MUCH easier. It also specifically
> > prevents a lot of "bad practices". By having each in a separate
> > module, it's completley impossible to produce a bunch of spegetti code
> > with circular references and such. Every single time I've looked
> > at a
> > project that tried to build things into one module, the code has
> > been a
> > disaster.
> >
> You're mixing up compile time with build time. By all means, have as
> many source modules as you want to maintain whatever good design
> practice you want to. As a user, this is irrelevant to me. There
> should not be a 1-1 mapping between source modules and jar files. The
> multiple modules is to allow you (the developers) to scale the
> project and grow it in a sensible manner over time, which is great.
> As an end user, all I want is to use cxf.
>
> > There are three categories of folks I need to keep in mind:
> >
> > 1) CXF developers - basically, the folks on cxf-dev that are in the
> > core
> > writing stuff.
> >
> > 2) Basic "end user" type folks. Most of these are happy with the
> > JAX-WS
> > specification or the other "basic" info we have up on the Wiki.
> > (Well,
> > the stuff that Dan is working on getting on the wiki. More work is
> > needed on this front.)
> >
> Yes, and being in that category, I don't want to add 8 cxf jars. It's
> an irritating barrier to adoption. Does a single user on this list
> think this is a good idea? Please speak up if you *want* dozens of jars.
>
> > 3) Advanced developers - these are the folks that are writing
> > interceptors, writing new bindings/transports, etc.... For these
> > folks, the javadocs in "api" are the important things.
> >
> You honestly think that these developers won't know that a package
> called 'internal' or 'impl' is not public, even if that's documented?
>
> In the 3 groups above, there are sometimes conflicting needs. Right
> now it looks like the people most catered to in terms of packaging
> are the first group, which seems a bit...odd.
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007
> 2:31 PM
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007
2:31 PM
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 9:47 AM, Daniel Kulp wrote:
> It makes dependency management MUCH easier. It also specifically
> prevents a lot of "bad practices". By having each in a separate
> module, it's completley impossible to produce a bunch of spegetti code
> with circular references and such. Every single time I've looked
> at a
> project that tried to build things into one module, the code has
> been a
> disaster.
>
You're mixing up compile time with build time. By all means, have as
many source modules as you want to maintain whatever good design
practice you want to. As a user, this is irrelevant to me. There
should not be a 1-1 mapping between source modules and jar files. The
multiple modules is to allow you (the developers) to scale the
project and grow it in a sensible manner over time, which is great.
As an end user, all I want is to use cxf.
> There are three categories of folks I need to keep in mind:
>
> 1) CXF developers - basically, the folks on cxf-dev that are in the
> core
> writing stuff.
>
> 2) Basic "end user" type folks. Most of these are happy with the
> JAX-WS
> specification or the other "basic" info we have up on the Wiki.
> (Well,
> the stuff that Dan is working on getting on the wiki. More work is
> needed on this front.)
>
Yes, and being in that category, I don't want to add 8 cxf jars. It's
an irritating barrier to adoption. Does a single user on this list
think this is a good idea? Please speak up if you *want* dozens of jars.
> 3) Advanced developers - these are the folks that are writing
> interceptors, writing new bindings/transports, etc.... For these
> folks, the javadocs in "api" are the important things.
>
You honestly think that these developers won't know that a package
called 'internal' or 'impl' is not public, even if that's documented?
In the 3 groups above, there are sometimes conflicting needs. Right
now it looks like the people most catered to in terms of packaging
are the first group, which seems a bit...odd.
Re: cxf packaging
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 27 March 2007 08:31, Hani Suleiman wrote:
> On Mar 27, 2007, at 7:27 AM, Daniel Kulp wrote:
> > God no. I can see api and rt-core being combined. However, none
> > of the
> > other rt-* artifacts should be combined into it. All of those are
> > modular for a reason and should stay that way.
>
> Why?
It makes dependency management MUCH easier. It also specifically
prevents a lot of "bad practices". By having each in a separate
module, it's completley impossible to produce a bunch of spegetti code
with circular references and such. Every single time I've looked at a
project that tried to build things into one module, the code has been a
disaster.
> > The separation of API and CORE is mostly to aid in javadoc
> > generation. If someone can find a easy way to generate javadocs for
> > all the stuff in
> > api, but not the stuff in core if they are combined, fine. However,
> > I don't consider a monser list of includes/excludes an "easy" way of
> > doing
> > it.
>
> It's not easy for the developers, but who is the majority in cxf, its
> developers or its users?
There are three categories of folks I need to keep in mind:
1) CXF developers - basically, the folks on cxf-dev that are in the core
writing stuff.
2) Basic "end user" type folks. Most of these are happy with the JAX-WS
specification or the other "basic" info we have up on the Wiki. (Well,
the stuff that Dan is working on getting on the wiki. More work is
needed on this front.)
3) Advanced developers - these are the folks that are writing
interceptors, writing new bindings/transports, etc.... For these
folks, the javadocs in "api" are the important things.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: cxf packaging
Posted by Daniel Kulp <dk...@apache.org>.
I've been looking at the minijar plugin on mojo:
http://mojo.codehaus.org/minijar-maven-plugin/
It has an "ueberjar" goal that can be used to combine jars and such.
I'm not completely sure on the status of it right now though.
Dan
On Tuesday 27 March 2007 09:31, James Strachan wrote:
> On 3/27/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > On 3/27/07, Hani Suleiman <ha...@formicary.net> wrote:
> > > On Mar 27, 2007, at 7:27 AM, Daniel Kulp wrote:
> > > > God no. I can see api and rt-core being combined. However,
> > > > none of the
> > > > other rt-* artifacts should be combined into it. All of those
> > > > are modular for a reason and should stay that way.
> > >
> > > Why?
> >
> > From a maven point of view it makes dependency management much
> > easier.
> >
> > What I would like to see is this (and I think this satisfies your
> > concerns Hani)
> > 1. API & Core combined
> > 2. A cxf-core-bundle.jar produced which contains the frequently used
> > modules (core, jax-ws, etc)
> > 3. In the distribution include the cxf-bundle.jar and any other
> > individual modules we don't want included by default (like jbi or
> > jca).
>
> +1
>
> I'm a big fan of the 'one jar to use a library/framework' approach; we
> do it in ActiveMQ and Camel too (as do Spring as well). Note though
> that this is not an exclusive decision. Developers can choose to use
> the individual jars if they wish, or the big-ass-bundle jar if they
> prefer. When I'm a user of CXF I know I'd prefer just one big jar with
> the common stuff in it.
>
> BTW here's pom.xml from Camel which makes the single jar containing
> all the little jars if anyone wants to reuse it...
>
> https://svn.apache.org/repos/asf/activemq/camel/trunk/apache-camel/pom
>.xml
>
> (search for maven-bundle-plugin). The only trick is that the jars
> being put into the assembly jars must be dependencies of the pom.xml
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 8:48 AM, Dan Diephouse wrote:
> By splitting up the different modules in Maven we're ensuring that
> we don't
> inadvertently depend on things which we shouldn't, which helps you
> the end
> user by reducing the number of dependencies. For instance, by
> separating out
> the JAX-WS module, we're able to ensure that we don't force a user
> to have a
> dependency on the JAX-WS jars. If you're just using the simple pojo
> frontend, this significantly reduces your dependency list.
>
Sure, I understand this (and it's a good thing), my point is that
this is completely orthogonal to artifacts produced. Build layout
does not dictate end jars!
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/27/07, Hani Suleiman <ha...@formicary.net> wrote:
>
> On Mar 27, 2007, at 8:36 AM, Dan Diephouse wrote:
>
> > What I would like to see is this (and I think this satisfies your
> > concerns
> > Hani)
> > 1. API & Core combined
> > 2. A cxf-core-bundle.jar produced which contains the frequently
> > used modules
> > (core, jax-ws, etc)
> > 3. In the distribution include the cxf-bundle.jar and any other
> > individual
> > modules we don't want included by default (like jbi or jca).
> >
>
> Yeah this would help, though I'd still go for 1 and 2 combined, in a
> cxf.jar (and 3 is cxf-extras.jar).
>
Wouldn't a cxf-bundle.jar be the same thing in effect? All you see at the
end of it is a cxf-bundle.jar. (It should probably just be named cxf.jar, I
am using -bundle for clarity).
By splitting up the different modules in Maven we're ensuring that we don't
inadvertently depend on things which we shouldn't, which helps you the end
user by reducing the number of dependencies. For instance, by separating out
the JAX-WS module, we're able to ensure that we don't force a user to have a
dependency on the JAX-WS jars. If you're just using the simple pojo
frontend, this significantly reduces your dependency list.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 8:36 AM, Dan Diephouse wrote:
> What I would like to see is this (and I think this satisfies your
> concerns
> Hani)
> 1. API & Core combined
> 2. A cxf-core-bundle.jar produced which contains the frequently
> used modules
> (core, jax-ws, etc)
> 3. In the distribution include the cxf-bundle.jar and any other
> individual
> modules we don't want included by default (like jbi or jca).
>
Yeah this would help, though I'd still go for 1 and 2 combined, in a
cxf.jar (and 3 is cxf-extras.jar).
Re: cxf packaging
Posted by James Strachan <ja...@gmail.com>.
On 3/27/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> On 3/27/07, Hani Suleiman <ha...@formicary.net> wrote:
> >
> > On Mar 27, 2007, at 7:27 AM, Daniel Kulp wrote:
> >
> > >
> > > God no. I can see api and rt-core being combined. However, none
> > > of the
> > > other rt-* artifacts should be combined into it. All of those are
> > > modular for a reason and should stay that way.
> > >
> > Why?
>
>
> From a maven point of view it makes dependency management much easier.
>
> What I would like to see is this (and I think this satisfies your concerns
> Hani)
> 1. API & Core combined
> 2. A cxf-core-bundle.jar produced which contains the frequently used modules
> (core, jax-ws, etc)
> 3. In the distribution include the cxf-bundle.jar and any other individual
> modules we don't want included by default (like jbi or jca).
+1
I'm a big fan of the 'one jar to use a library/framework' approach; we
do it in ActiveMQ and Camel too (as do Spring as well). Note though
that this is not an exclusive decision. Developers can choose to use
the individual jars if they wish, or the big-ass-bundle jar if they
prefer. When I'm a user of CXF I know I'd prefer just one big jar with
the common stuff in it.
BTW here's pom.xml from Camel which makes the single jar containing
all the little jars if anyone wants to reuse it...
https://svn.apache.org/repos/asf/activemq/camel/trunk/apache-camel/pom.xml
(search for maven-bundle-plugin). The only trick is that the jars
being put into the assembly jars must be dependencies of the pom.xml
--
James
-------
http://radio.weblogs.com/0112098/
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/27/07, Hani Suleiman <ha...@formicary.net> wrote:
>
> On Mar 27, 2007, at 7:27 AM, Daniel Kulp wrote:
>
> >
> > God no. I can see api and rt-core being combined. However, none
> > of the
> > other rt-* artifacts should be combined into it. All of those are
> > modular for a reason and should stay that way.
> >
> Why?
>From a maven point of view it makes dependency management much easier.
What I would like to see is this (and I think this satisfies your concerns
Hani)
1. API & Core combined
2. A cxf-core-bundle.jar produced which contains the frequently used modules
(core, jax-ws, etc)
3. In the distribution include the cxf-bundle.jar and any other individual
modules we don't want included by default (like jbi or jca).
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 7:27 AM, Daniel Kulp wrote:
>
> God no. I can see api and rt-core being combined. However, none
> of the
> other rt-* artifacts should be combined into it. All of those are
> modular for a reason and should stay that way.
>
Why?
> The separation of API and CORE is mostly to aid in javadoc generation.
> If someone can find a easy way to generate javadocs for all the
> stuff in
> api, but not the stuff in core if they are combined, fine. However, I
> don't consider a monser list of includes/excludes an "easy" way of
> doing
> it.
>
It's not easy for the developers, but who is the majority in cxf, its
developers or its users?
> Remember, not everyone uses fancy IDE's and stuff. Javadoc of the
> stuff
> users/devs should be aware of is important.
Sure, so have your explicit list of javadoc packages to include/
exclude in your javadoc task.
Even if you DID have it all in one javadoc tree,you could easily just
drop in a package.html file in each 'internal' package with a
disclaimer saying it shouldn't be used. You can only suggest that,
you can't enforce it anyway. Have some faith in users.
Re: cxf packaging
Posted by Daniel Kulp <dk...@apache.org>.
God no. I can see api and rt-core being combined. However, none of the
other rt-* artifacts should be combined into it. All of those are
modular for a reason and should stay that way.
The separation of API and CORE is mostly to aid in javadoc generation.
If someone can find a easy way to generate javadocs for all the stuff in
api, but not the stuff in core if they are combined, fine. However, I
don't consider a monser list of includes/excludes an "easy" way of doing
it.
Remember, not everyone uses fancy IDE's and stuff. Javadoc of the stuff
users/devs should be aware of is important.
Dan
On Tuesday 27 March 2007 03:19, Andrea Smyth wrote:
> The policy APIs in the api module are a good example - the reason they
> are there and not, along with the impl in the cxf-rt-ws-policy module,
> is the modularization of the rt modules in the first place: cxf-api so
> far has been a solution to keeping the numerous cxf-rt-* modules free
> from circular dependencies.
> If we combined cxf-api and cxf-rt-* (with packages in the latter being
> moved into impl or internal packages) that would not be an issue, but
> the jar and its list of dependencies will become quite big.
> Maybe we should define which transports, bindings, and other
> functionality are 'core' (say http, or perhaps only a jetty
> independent http client, and soap) and which ones optional (jms, xml)?
> The compromise may still be too granular for some and have too many
> dependencies for others.
>
> Andrea.
>
>
>
> All of the
>
> Dan Diephouse wrote:
> > Agreed. We have lots of arbitrary distinctions going on right now
> > too. For
> > instance, if you look at the WS-Policy bits you'll see we have half
> > about in
> > the cxf-api module by necessity. If you look at the classes, I don't
> > think
> > thats really ideal as I don't think that under ideal conditions you
> > would want it that way.
> >
> > - Dan
> >
> > On 3/26/07, Hani Suleiman <ha...@formicary.net> wrote:
> >> On Mar 26, 2007, at 4:53 PM, Paul Brown wrote:
> >> > 2) I can't think of a (good) reason that code layout choices
> >> > (separation of interface and implementation codebases) or
> >> > artificial constraints (maven's predilections about directories)
> >> > should influence artifacts. These things are also confusing --
> >> > do I need both the ifact and impl JARs? (Ultimately, if it's not
> >> > for public use, then it should be package private anyway...)
> >>
> >> Yep! It's a pretty awful abuse of jar files. It's not like cxf-api
> >> is a spec or that it'll have more than one impl that could be
> >> dropped in. It's pretty pretentious to split it up that way. If the
> >> intent is to distinguish between public and private APIs, then this
> >> is a very poor way of doing so, for the following reasons:
> >>
> >> - IDEs will have both in the classpath, how often does anyone check
> >> what jar a dependency comes from, if it's been satisfied somehow?
> >> - It ignores the fact that packages exist for exactly this reason.
> >> - Nobody else does it this way
> >> - While the build classpath is sometimes bigger than the runtime
> >> one, this particular split seems to feel that sometimes it's the
> >> opposite (1 jar for build and 2 for deployment), which is fairly
> >> ....uhm (can't think of a polite word)... as no other framework
> >> makes this odd assumption.
> >>
> >> You're far better served by moving the impl into a 'internal' or
> >> 'impl' package. That way a glance at the imports tells you
> >> everything you need to know.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 27, 2007, at 3:19 AM, Andrea Smyth wrote:
> The policy APIs in the api module are a good example - the reason
> they are there and not, along with the impl in the cxf-rt-ws-policy
> module, is the modularization of the rt modules in the first place:
> cxf-api so far has been a solution to keeping the numerous cxf-rt-*
> modules free from circular dependencies.
Again, you're approaching this from the viewpoint of someone who is
developing cxf. The user of the jars isn't cxf developers, it's end
users to whom this is not relevant at all. it's an implementation/
internal design detail that's leaking into userland and making the
library more difficult to use than it should be.
> If we combined cxf-api and cxf-rt-* (with packages in the latter
> being moved into impl or internal packages) that would not be an
> issue, but the jar and its list of dependencies will become quite big.
I'd be happy if there was one jar I could drop in that would run for
basic usage. Basic usage meaning I can programatically create a
service and have it be invoked.
Re: cxf packaging
Posted by Andrea Smyth <an...@iona.com>.
The policy APIs in the api module are a good example - the reason they
are there and not, along with the impl in the cxf-rt-ws-policy module,
is the modularization of the rt modules in the first place: cxf-api so
far has been a solution to keeping the numerous cxf-rt-* modules free
from circular dependencies.
If we combined cxf-api and cxf-rt-* (with packages in the latter being
moved into impl or internal packages) that would not be an issue, but
the jar and its list of dependencies will become quite big.
Maybe we should define which transports, bindings, and other
functionality are 'core' (say http, or perhaps only a jetty independent
http client, and soap) and which ones optional (jms, xml)? The
compromise may still be too granular for some and have too many
dependencies for others.
Andrea.
All of the
Dan Diephouse wrote:
> Agreed. We have lots of arbitrary distinctions going on right now too.
> For
> instance, if you look at the WS-Policy bits you'll see we have half
> about in
> the cxf-api module by necessity. If you look at the classes, I don't
> think
> thats really ideal as I don't think that under ideal conditions you would
> want it that way.
>
> - Dan
>
> On 3/26/07, Hani Suleiman <ha...@formicary.net> wrote:
>
>>
>>
>> On Mar 26, 2007, at 4:53 PM, Paul Brown wrote:
>>
>> > 2) I can't think of a (good) reason that code layout choices
>> > (separation of interface and implementation codebases) or artificial
>> > constraints (maven's predilections about directories) should influence
>> > artifacts. These things are also confusing -- do I need both the
>> > ifact and impl JARs? (Ultimately, if it's not for public use, then it
>> > should be package private anyway...)
>> >
>> Yep! It's a pretty awful abuse of jar files. It's not like cxf-api is
>> a spec or that it'll have more than one impl that could be dropped
>> in. It's pretty pretentious to split it up that way. If the intent is
>> to distinguish between public and private APIs, then this is a very
>> poor way of doing so, for the following reasons:
>>
>> - IDEs will have both in the classpath, how often does anyone check
>> what jar a dependency comes from, if it's been satisfied somehow?
>> - It ignores the fact that packages exist for exactly this reason.
>> - Nobody else does it this way
>> - While the build classpath is sometimes bigger than the runtime one,
>> this particular split seems to feel that sometimes it's the opposite
>> (1 jar for build and 2 for deployment), which is fairly ....uhm
>> (can't think of a polite word)... as no other framework makes this
>> odd assumption.
>>
>> You're far better served by moving the impl into a 'internal' or
>> 'impl' package. That way a glance at the imports tells you everything
>> you need to know.
>>
>
>
>
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
Agreed. We have lots of arbitrary distinctions going on right now too. For
instance, if you look at the WS-Policy bits you'll see we have half about in
the cxf-api module by necessity. If you look at the classes, I don't think
thats really ideal as I don't think that under ideal conditions you would
want it that way.
- Dan
On 3/26/07, Hani Suleiman <ha...@formicary.net> wrote:
>
>
> On Mar 26, 2007, at 4:53 PM, Paul Brown wrote:
>
> > 2) I can't think of a (good) reason that code layout choices
> > (separation of interface and implementation codebases) or artificial
> > constraints (maven's predilections about directories) should influence
> > artifacts. These things are also confusing -- do I need both the
> > ifact and impl JARs? (Ultimately, if it's not for public use, then it
> > should be package private anyway...)
> >
> Yep! It's a pretty awful abuse of jar files. It's not like cxf-api is
> a spec or that it'll have more than one impl that could be dropped
> in. It's pretty pretentious to split it up that way. If the intent is
> to distinguish between public and private APIs, then this is a very
> poor way of doing so, for the following reasons:
>
> - IDEs will have both in the classpath, how often does anyone check
> what jar a dependency comes from, if it's been satisfied somehow?
> - It ignores the fact that packages exist for exactly this reason.
> - Nobody else does it this way
> - While the build classpath is sometimes bigger than the runtime one,
> this particular split seems to feel that sometimes it's the opposite
> (1 jar for build and 2 for deployment), which is fairly ....uhm
> (can't think of a polite word)... as no other framework makes this
> odd assumption.
>
> You're far better served by moving the impl into a 'internal' or
> 'impl' package. That way a glance at the imports tells you everything
> you need to know.
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
On Mar 26, 2007, at 4:53 PM, Paul Brown wrote:
> 2) I can't think of a (good) reason that code layout choices
> (separation of interface and implementation codebases) or artificial
> constraints (maven's predilections about directories) should influence
> artifacts. These things are also confusing -- do I need both the
> ifact and impl JARs? (Ultimately, if it's not for public use, then it
> should be package private anyway...)
>
Yep! It's a pretty awful abuse of jar files. It's not like cxf-api is
a spec or that it'll have more than one impl that could be dropped
in. It's pretty pretentious to split it up that way. If the intent is
to distinguish between public and private APIs, then this is a very
poor way of doing so, for the following reasons:
- IDEs will have both in the classpath, how often does anyone check
what jar a dependency comes from, if it's been satisfied somehow?
- It ignores the fact that packages exist for exactly this reason.
- Nobody else does it this way
- While the build classpath is sometimes bigger than the runtime one,
this particular split seems to feel that sometimes it's the opposite
(1 jar for build and 2 for deployment), which is fairly ....uhm
(can't think of a polite word)... as no other framework makes this
odd assumption.
You're far better served by moving the impl into a 'internal' or
'impl' package. That way a glance at the imports tells you everything
you need to know.
Re: cxf packaging
Posted by Paul Brown <pa...@gmail.com>.
On 3/26/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> I too would like to see a bundle jar so users don't have to manage all the
> cxf-* jars.
> Currently we have a manifest jar which helps in setting up the classpath
> (you only have to reference cxf-incubator.jar), but managing the cxf-* jars
> is unwieldy and a PITA.
> I would like to see us have a bundle jar which includes the most commonly
> used modules. Then people could add the jbi, jca, etc jars if they wanted.
A couple of things that I'll ask in this context:
1) Please make it absolutely clear what it required for/by what. For
example, dealing with Spring via Maven is a confusing PITA because
what lives where isn't clearly specified.
2) I can't think of a (good) reason that code layout choices
(separation of interface and implementation codebases) or artificial
constraints (maven's predilections about directories) should influence
artifacts. These things are also confusing -- do I need both the
ifact and impl JARs? (Ultimately, if it's not for public use, then it
should be package private anyway...)
--
paulrbrown@gmail.com
http://mult.ifario.us/
Re: cxf packaging
Posted by Dan Diephouse <da...@envoisolutions.com>.
I too would like to see a bundle jar so users don't have to manage all the
cxf-* jars.
Currently we have a manifest jar which helps in setting up the classpath
(you only have to reference cxf-incubator.jar), but managing the cxf-* jars
is unwieldy and a PITA.
I would like to see us have a bundle jar which includes the most commonly
used modules. Then people could add the jbi, jca, etc jars if they wanted.
- Dan
On 3/26/07, Hani Suleiman <ha...@formicary.net> wrote:
>
> I agree, the packaging is very awkward right now, and it's hard to
> find out why anyone would think that having 8+ jars to deploy what is
> essentially one framework is a good idea. Obviously this isn't about
> dependencies, but rather about the cxf-* jars. Modularising them
> makes sense, but for some things it's hard to understand what the
> thought process was when deciding that 'api' should be separate from
> 'core'. When would you deploy one without the other?
>
>
> On Mar 26, 2007, at 3:06 PM, tog wrote:
>
> > Hi folks
> >
> > Thanks a lot for all the work you have done so far. I am
> > enthousiastic user.
> > My goal is to link cxf with a dynamic languages namely Groovy.
> > Among the
> > difficulty I currently have is the selection of jar files would it be
> > possible to have different kind of packaging for example (this is
> > only a
> > proposal) a full jarfile (including dependencies) cxf-all.jar, a
> > minimum jar
> > file (not including the dependencies) for example based on aegis.
> > Of course
> > this does not prevent you to propose the single jars. Such jars
> > will ease
> > the integration and does not require much additional effort.
> >
> > Best Regards
> > Guillaume
> >
> > --
> >
> >
> > <a target="_blank"
> > href="http://www.google.com/calendar/render?cid=guillaume.alleon%
> > 40gmail.com
> > "><img src="http://www.google.com/calendar/images/ext/
> > gc_button1_en.gif"
> > border=0></a>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: cxf packaging
Posted by Hani Suleiman <ha...@formicary.net>.
I agree, the packaging is very awkward right now, and it's hard to
find out why anyone would think that having 8+ jars to deploy what is
essentially one framework is a good idea. Obviously this isn't about
dependencies, but rather about the cxf-* jars. Modularising them
makes sense, but for some things it's hard to understand what the
thought process was when deciding that 'api' should be separate from
'core'. When would you deploy one without the other?
On Mar 26, 2007, at 3:06 PM, tog wrote:
> Hi folks
>
> Thanks a lot for all the work you have done so far. I am
> enthousiastic user.
> My goal is to link cxf with a dynamic languages namely Groovy.
> Among the
> difficulty I currently have is the selection of jar files would it be
> possible to have different kind of packaging for example (this is
> only a
> proposal) a full jarfile (including dependencies) cxf-all.jar, a
> minimum jar
> file (not including the dependencies) for example based on aegis.
> Of course
> this does not prevent you to propose the single jars. Such jars
> will ease
> the integration and does not require much additional effort.
>
> Best Regards
> Guillaume
>
> --
>
>
> <a target="_blank"
> href="http://www.google.com/calendar/render?cid=guillaume.alleon%
> 40gmail.com
> "><img src="http://www.google.com/calendar/images/ext/
> gc_button1_en.gif"
> border=0></a>