> > 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:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 6:55 AM > To: [email protected] > 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
