Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] too many jars? jetty-util jetty-io jetty-http ???

I'll expand tomorrow but I am of the mind that if we want to allow for
an aggregate mechanism for people to consume jetty other then through
the maven dependency resolution or normal download bundles...we need
to take a step back a bit and look at all the different ways it is
consumed and look for the natural breaks.

this is the same discussion we had the other day re: packaging in
debian and rpms to generate, and the same as the 'which eclipse
features?' do we publish in the p2 repos for eclipse.

all of these things are aggregates of the development artifacts we are
working with...and I am totally behind having smaller more targeted
artifacts for development purposes and then aggregate as needed for
whatever deployment scenario we are looking for.  The current
structure in svn is good for developers as it provides a clean
building blocks approach to what makes up jetty that will be clouded
somewhat by whatever distribution related format we want to go for.

personally, I think we ought to stick with what we have in svn right
now...and then let users as us for aggregations that they might want
or need down the road.  It is super easy to make aggregation
assemblies, but once we start making 2,3,10 of these different
aggregations, coupled with debs, rpms, p2 update sites, distribution
downloads (zip, tgz, etc), yadda yadda yadda...most people will be
consuming through one of these mechanisms anyway...

So building out a good clear break for what deliverables we publish is
a great thing for us right now imo....but shoving the kitchen sink
into util or combining other things together again might not be the
answer to that...

imo at least.

in bullets:

* smaller, concise clear development artifacts == good
* aggregates can be good for the right reasons
* +1 for clearly delinating the
core/client/server/webapp/jmx/jndi/etc/etc/etc mnemonic between
deb/rpm/p2/artifact for distribution purposes?

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Mon, May 25, 2009 at 19:01, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> Greg,
>
> [snip]
>>
>> I'd like to add a jetty-all.jar  module on the eclipse
>> project that will produce an aggregate bundle of all
>> jetty@eclipse jars, currently:
>>
>> jetty-ajp
>> jetty-annotations
>> jetty-client
>> jetty-continuation
>> jetty-deploy
>> jetty-http
>> jetty-io
>> jetty-jaspi
>> jetty-jmx
>> jetty-jndi
>> jetty-plus
>> jetty-rewrite
>> jetty-security
>> jetty-server
>> jetty-servlet
>> jetty-servlets
>> jetty-util
>> jetty-webapp
>> jetty-xml
>
> +1 to the jetty-all jar
>
>
>> But I'm wondering if we have been a little to pure with the breakout
>> of modules.  Specifically, do we really need util, io and http to
>> be separate?
>>
>> To that end, I have three proposals:
>>
>>
>> a) merge io,http,continuation back into jetty-util and it
>> will be slighly wrongly named as it will have classes from
>> not just the util package.
>>
>> b) merge io,http,continuation and util into a jetty-common
>> module.
>>
>> c) leave io,http,continuation separate, but have a jetty-common
>> aggregation module that builds an combined jar.
>>
>>
>> I like c)  as advanced users could still directly depend on the
>> smaller modules if they wanted (and exclude jetty-common.jar)
>
> Merging them all back into one jar might not be possible - I thought
> the main driver for separation was cyclic dependencies?
>
> +1 for option c) to maintain separate jars but a convenience jar
> with those combined. Not sure on the naming of this jar - see
> below for more.
>
>> The final question I have is on naming of aggregate jars.
>> Ie do we want to differentiate aggregate jars from normal package
>> jars?  So for the common aggregate jar, I can see the following
>> naming options:
>>
>>    jetty-common-aggregate
>>    jetty-common-agg
>>    jetty-aggregate-common
>>    jetty-agg-common
>>    jetty-a-common
>>    jetty--common
>>
>>
>> I like the last two because they will sort so that all aggregate
>> modules are together.   I know the -- is pretty arbitrary, but
>> it is after all a convention that regardless of name will need
>> to be backed up by documentation.
>
> -1 on the -- naming convention. Too subtle and looks like a typo.
> Maybe some systems won't parse that correctly either. "Common"
> makes it sound like you have to have that _in addition_ to other
> jars.
>
> Perhaps jetty-xxx-all ?
>
>  jetty-util-all:
>    jetty-util
>    jetty-io
>    jetty-http
>    jetty-continuation
>
>  jetty-server-all:
>   jetty-util
>   jetty-io
>   jetty-http
>   jetty-continuation
>   jetty-server
>   jetty-security
>   jetty-servlet
>   jetty-xml
>   jetty-webapp
>   jetty-deploy
>   jetty-jmx
>   jetty-jaspi
>   jetty-jmx
>   jetty-jndi
>   jetty-plus
>   jetty-rewrite
>
>  jetty-client-all:
>   jetty-util
>   jetty-io
>   jetty-http
>   jetty-client
>
>  jetty-all:
>   jetty-ajp
>   jetty-annotations
>   jetty-client
>   jetty-continuation
>   jetty-deploy
>   jetty-http
>   jetty-io
>   jetty-jaspi
>   jetty-jmx
>   jetty-jndi
>   jetty-plus
>   jetty-rewrite
>   jetty-security
>   jetty-server
>   jetty-servlet
>   jetty-servlets
>   jetty-util
>   jetty-webapp
>   jetty-xml
>
>
> Jan
>
>>
>>
>> Regardless of the name, I can see us quickly doing the following
>> aggregate jars:
>>
>> jetty--common-aggregate
>>    jetty-util
>>    jetty-io
>>    jetty-http
>>    jetty-continuation
>>
>> jetty--server
>>    jetty-util
>>    jetty-io
>>    jetty-http
>>    jetty-continuation
>>    jetty-server
>>    jetty-security
>>    jetty-servlet
>>    jetty-xml
>>    jetty-webapp
>>    jetty-deploy
>>    jetty-jmx
>>    jetty-jaspi
>>    jetty-jmx
>>    jetty-jndi
>>    jetty-plus
>>    jetty-rewrite
>>
>> jetty--client
>>    jetty-util
>>    jetty-io
>>    jetty-http
>>    jetty-client
>>
>> jetty--all
>>    jetty-ajp
>>    jetty-annotations
>>    jetty-client
>>    jetty-continuation
>>    jetty-deploy
>>    jetty-http
>>    jetty-io
>>    jetty-jaspi
>>    jetty-jmx
>>    jetty-jndi
>>    jetty-plus
>>    jetty-rewrite
>>    jetty-security
>>    jetty-server
>>    jetty-servlet
>>    jetty-servlets
>>    jetty-util
>>    jetty-webapp
>>    jetty-xml
>>
>>
>>
>> thoughts ?
>>
>>
>>
>> cheers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
> --
> Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top