|
»
»
too many jars? jetty-util jetty-io jetty-http ???
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
too many jars? jetty-util jetty-io jetty-http ???
by Gregw
::
Rate this Message:
All, with the move to Jetty-7, we refactored the server and client into more smaller jars. To run the client, you need jetty-util.jar jetty-io.jar jetty-http.jar jetty-client.jar So now to run a simple server you need: servlet-api.jar jetty-util.jar jetty-io.jar jetty-http.jar jetty-continuation.jar jetty-server.jar For a full server you need servlet-api.jar jetty-util.jar jetty-io.jar jetty-http.jar jetty-continuation.jar jetty-server.jar jetty-security.jar jetty-servlet.jar jetty-xml.jar jetty-webapp.jar jetty-deploy.jar Now for the maven users out there, wrangling such dependencies is easy and mostly transparent. The RPM and deb packages also hide this But for others, those lists of jars are a little counter the "simple" tag of Jetty. One thing we can do help this is the produce some aggregate jars. We already have the jetty-runner.jar, which includes a main to be able to run from the command line. 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 [ note that the modules excluded from this list (eg jetty-test-webapp) should be renamed not use the jetty- prefix (eg test-jetty-webapp) ] 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) 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. 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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by Gregw
::
Rate this Message:
I really should read my own emails before pushing the send button: s/One thing we can do help this is the produce some/One thing we can do to help this is to produce some/ cheers --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by janb
::
Rate this Message:
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@... > https://dev.eclipse.org/mailman/listinfo/jetty-dev -- Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by jmcconnell
::
Rate this Message:
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@... On Mon, May 25, 2009 at 19:01, Jan Bartel <janb@...> 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@... >> https://dev.eclipse.org/mailman/listinfo/jetty-dev > > -- > Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com > _______________________________________________ > jetty-dev mailing list > jetty-dev@... > https://dev.eclipse.org/mailman/listinfo/jetty-dev > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by Jesse McConnell-3
::
Rate this Message:
fyi:
feature wise for the p2 repository... http://download.eclipse.org/jetty/stable-7/update/ if you look at that core = j-util, j-http, j-io client = j-client server = j-server, servlet-api webapp = j-webapp that was just a simple slice so I could have something to work with for eclipse http osgi component and the plugin.. jesse -- Jesse McConnell jesse@... On Mon, May 25, 2009 at 20:29, Jesse McConnell <jesse.mcconnell@...> wrote: I'll expand tomorrow but I am of the mind that if we want to allow for |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by David Yu-3
::
Rate this Message:
"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." +1 with jesse This is what makes jetty7 different imo. Users can pick *only* the modules that they need without bringing in extra dependencies. As jesse said, if the demand is there, the aggregated assemblies can be generated in the future. Cheers On Tue, May 26, 2009 at 10:06 AM, Jesse McConnell <jesse@...> wrote: fyi: |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by Gregw
::
Rate this Message:
Jesse McConnell wrote:
> 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. That's what I was trying to do :) I think you (and dyu) are advocating my option c: >> c) leave io,http,continuation separate, but have a jetty-common >> aggregation module that builds an combined jar. and that is indeed my preferred option - to leave the current modules more or less as they are. So jetty-foo contains org.eclipse.jetty.foo and nothing else. > 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 at this stage, I'd like to start defining the conventions for aggregates - as there is already some demand for them (specially the client jar). What I want to avoid is what we've already done with jetty-runner, which is an aggregate, but it is not clear that it is. As we get more and more aggregates, it will be very important that we keep them distinct from the core modules, so that when jetty-kitchensink comes along, we don't have to rely on interpretation of the name to guess if it is an aggregate or not. Note that I've already started distinguishing names - as I've renamed: jetty-embedded-examples -> example-jetty-embedded jetty-test-webapp -> test-jetty-webapp So now there are example-* and test-* modules that are distinct from the core jetty-* modules So I'm still looking for a good naming convention to distinguish aggregates: jetty-client-aggregate // too long and aggregates. doesn't sort nice jetty-client-all // "all" is overloaded. doesn't sort nice jetty-all-client // "all" is overloaded. does sort nice - but not bad jetty-deps-client // deps implies client not included. does sort nice jetty--client // too subtle. does sort nice JETTY-client // even more subtle and does not sort on windows jetty-combined-client // hmmmmm currently my favourite is probably -- still , so we would have: jetty--http-client # just the HTTP client jetty--http-server # just the HTTP server jetty--server # The server + bells + whistle jetty--all # everything but I'm very open to be convinced about better names and/or boundaries thoughts --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: too many jars? jetty-util jetty-io jetty-http ???
by jmcconnell
::
Rate this Message:
I don't think we ought to rename the artifacts at all for client and
server....just add in a package space for deployment of them.. org.eclipse.jetty.bundle:jetty-client org.eclipse.jetty.bundle:jetty-server then they are segmented off from the normal artifacts in their own 'bundle' directory (which is not to be confused with the eclipse bundles...unless we decided to make these the specific artifacts feeding the p2 repo which is not a terrible idea...maybe, have to give it some thought this would look the same way as the toolchain would in the repo, artifacts that we depend on (or produce) for the project but are not polluting the main project space in the repo.. jesse -- jesse mcconnell jesse.mcconnell@... On Tue, May 26, 2009 at 00:00, Greg Wilkins <gregw@...> wrote: > Jesse McConnell wrote: >> 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. > > That's what I was trying to do :) > > > I think you (and dyu) are advocating my option c: > >>> c) leave io,http,continuation separate, but have a jetty-common >>> aggregation module that builds an combined jar. > > and that is indeed my preferred option - to leave the > current modules more or less as they are. So > jetty-foo contains org.eclipse.jetty.foo and nothing > else. > > > >> 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 at this stage, I'd like to start defining the conventions for > aggregates - as there is already some demand for them (specially > the client jar). > > What I want to avoid is what we've already done with jetty-runner, > which is an aggregate, but it is not clear that it is. > > As we get more and more aggregates, it will be very important that > we keep them distinct from the core modules, so that when > jetty-kitchensink comes along, we don't have to rely on interpretation > of the name to guess if it is an aggregate or not. > > Note that I've already started distinguishing names - as I've > renamed: > > jetty-embedded-examples -> example-jetty-embedded > jetty-test-webapp -> test-jetty-webapp > > So now there are example-* and test-* modules that are > distinct from the core jetty-* modules > > > So I'm still looking for a good naming convention to > distinguish aggregates: > > jetty-client-aggregate // too long and aggregates. doesn't sort nice > jetty-client-all // "all" is overloaded. doesn't sort nice > jetty-all-client // "all" is overloaded. does sort nice - but not bad > jetty-deps-client // deps implies client not included. does sort nice > jetty--client // too subtle. does sort nice > JETTY-client // even more subtle and does not sort on windows > jetty-combined-client // hmmmmm > > > > currently my favourite is probably -- still , so we would have: > > jetty--http-client # just the HTTP client > jetty--http-server # just the HTTP server > jetty--server # The server + bells + whistle > jetty--all # everything > > > but I'm very open to be convinced about better names and/or boundaries > > > thoughts > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > jetty-dev mailing list > jetty-dev@... > https://dev.eclipse.org/mailman/listinfo/jetty-dev > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
