Skip to main content

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

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


























Back to the top