Changes to start.jar for jetty-7

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Changes to start.jar for jetty-7

Greg Wilkins

All,

for many years Jetty has been started with

  java -jar start.jar

and the default behaviour has been to be put all the jars found in $jetty-home/lib  onto the classpath
and to run the etc/jetty.xml.    This is all controlled by the start.config file that is backed into start.jar.

We had the attitude that if you don't want something, just delete it from lib.  If you do want something,
then build it from source.


BUT

the problem with this approach is that it discourages a full build of all the
contrib and extra components. For example, we exclude wadi and grizzly from the
default build, because if they put their artifacts into lib they will be available
on the classpath.  This can be confusing and also break some things (as wadi
includes a commons logging impl etc.).

Also the lib is currently organized by optional component, with each option
including it's dependencies.   But if two options both need a common component,
then they both will include it.     Plus we increasing need to integrate with
distros like jpackage and debian that have their own layouts for libraries of
jars.

So I am thinking that rather than invent our own lib layout, we just pick one.
So I'd pick maven and we just make lib into a maven repository of jars for
jetty and for it's dependencies.  At least with the same structure for jars,
if not the actual meta-data in poms etc.

A smart start.config like option 2c) below would be able to resolve the
common dependencies and pick the libraries out of the repository.  It could
be easily pointed at a shared repository or converted to jpackage/debian if
need be (and they don't provide a mock m2 repo themselves).



So start.jar will need to be updated to cope with this.

I see two broad directions that we can go:

1) We could follow the apache like example of having libs-enabled and libs-available
All jars would be installed in libs-available, and we would link/copy jars into
libs-enabled.   A standard start.config would then work.

This has the advantage of making the options very apparent on the disk.
But it really is inventing our own new approach for jars.



2) Complete jar repository with configurable start.jar

The $jetty.home/lib directory would be a complete repository with all optional
modules (jsp, plus, wadi, grizzly, etc) and their dependencies.

The start.config would be limited to by default only including the core jetty
jars and moderately standard options (ssl and jsp ?).

If you wanted optional modules then you would need to:

 2a) provide a new start.config on the command line, and configure the options within the config file

     java -DSTART=etc/start.config -jar start.jar

 2b) provide start config files:

     java -DSTART=etc/start.config,etc/start-plus.config -jar start.jar

 2c) provide config options on the command line

     java -DOPTIONS=jsp,plus,ssl -jar start.jar

   The option names would trigger named sections of the start.config file.



Thoughts greatly appreciated before we start messing with this important component.


cheers.



PS>   here is an example of what a parameterized start.config could look like.



$(jetty.class.path)                              always
$(jetty.lib)/**                                  exists $(jetty.lib)

# Set the jetty version
jetty.version=7.0-SNAPSHOT

# Try different settings of jetty.home until the jetty.jar is found.
jetty.home=.                                     ! exists $(jetty.home)/start.jar
jetty.home=..                                    ! exists $(jetty.home)/start.jar
jetty.home=/home/jetty                           ! exists $(jetty.home)/start.jar
jetty.home=/usr/lib/jetty                        ! exists $(jetty.home)/start.jar
jetty.home=/usr/share/lib/jetty                  ! exists $(jetty.home)/start.jar
jetty.home=/C:/jetty                             ! exists $(jetty.home)/start.jar
jetty.home=.                                     ! exists $(jetty.home)/start.jar

repository=$(jetty.home)/repo
jetty.repo=$(repository)/org/mortbay/jetty

# The main class to run
org.mortbay.xml.XmlConfiguration.class
$(start.class).class

# The default configuration files
$(jetty.home)/etc/jetty.xml                      nargs == 0

# Set the jetty common classpath
$(jetty.home)/lib/**                             always
$(jetty.home)/resources/                         always


[jetty,default,*]
$(jetty.repo)/servlet-api-3.0/$(jetty-version)/servlet-api-3.0-$(jetty-version).jar  ! available javax.servlet.Servlet
$(jetty.repo)/jetty-util/$(jetty-version)/jetty-util-$(jetty-version).jar
$(jetty.repo)/jetty/$(jetty-version)/jetty-$(jetty-version).jar


[ssl,default]
$(jetty.repo)/jetty-ssl/$(jetty-version)/jetty-ssl-$(jetty-version).jar


[jsp,default]
$(jetty.repo)/jsp-api-2.1/$(jetty-version)/jsp-api-2.1-$(jetty-version).jar   ! available javax.servlet.jsp.Page
$(jetty.repo)/jsp-2.1/$(jetty-version)/jsp-2.1-$(jetty-version).jar
$(repository)/ant/ant/1.6.5/ant-1.6.5.jar                                     ! available org.apache.tools.ant.Main
$(repository)/org/eclipse/jdt/core/3.1.1/core-3.1.1.jar


[plus]
$(jetty.repo)/jetty-plus/$(jetty-version)/jetty-plus-$(jetty-version).jar
$(jetty.repo)/jetty-naming/$(jetty-version)/jetty-naming-$(jetty-version).jar
(repository)/javax/activation/activation/1.1/activation-1.1.jar


[annotations]
$(jetty.repo)/jetty-annotations/$(jetty-version)/jetty-annotations-$(jetty-version).jar


etc. etc. etc.


It will be a little bit of a pain to keep dependency versions upto date,  but I'm
sure that can be automated.






















































---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

jan_bartel
Greg Wilkins wrote:

> We had the attitude that if you don't want something, just delete it from lib.  If you do want something,
> then build it from source.
Well, at least you could say that this approach had the advantage of simplicity :-)

> BUT
>
> the problem with this approach is that it discourages a full build of all the
> contrib and extra components. For example, we exclude wadi and grizzly from the
> default build, because if they put their artifacts into lib they will be available
> on the classpath.  This can be confusing and also break some things (as wadi
> includes a commons logging impl etc.).
Actually I think for a release we should always build and publish ALL of the
components (except obviously those that need a specific environment) to the
maven repo. That way people don't have to do their own builds, they can just
download the jars they want straight into jetty's lib.

> Also the lib is currently organized by optional component, with each option
> including it's dependencies.   But if two options both need a common component,
> then they both will include it.     Plus we increasing need to integrate with
> distros like jpackage and debian that have their own layouts for libraries of
> jars.
I agree we should look at a better organization of lib for jetty 7. It's a good
point about the common dependencies.

> So I am thinking that rather than invent our own lib layout, we just pick one.
> So I'd pick maven and we just make lib into a maven repository of jars for
> jetty and for it's dependencies.  At least with the same structure for jars,
> if not the actual meta-data in poms etc.
Well, I'm not sure that we need the depth and verbosity of a maven repo layout
(which is great for a general purpose repository, don't get me wrong). Do you
really think we need the whole directory naming structure by package and by
version? For example, we should never have 2 different versions of the same
external library, so we shouldn't ever have org/blah/foo/1.0/artifact-1.0.jar
and org/blah/foo/2.1/artifact-2.1.jar.

> A smart start.config like option 2c) below would be able to resolve the
> common dependencies and pick the libraries out of the repository.  It could
> be easily pointed at a shared repository or converted to jpackage/debian if
> need be (and they don't provide a mock m2 repo themselves).
Another option might be to make the existing jetty.class.path system property
a bit smarter and accept some wildcarding:

java -Djetty.class.path=lib/mystuff/**/*.jar:lib/special-goo.jar -jar start.jar

> So start.jar will need to be updated to cope with this.
>
> I see two broad directions that we can go:
>
> 1) We could follow the apache like example of having libs-enabled and libs-available
> All jars would be installed in libs-available, and we would link/copy jars into
> libs-enabled.   A standard start.config would then work.
Would we need a start.config with this? Why wouldn't we just put everything in
libs-enabled/ onto the runtime classpath?
 

> This has the advantage of making the options very apparent on the disk.
> But it really is inventing our own new approach for jars.
>
>
>
> 2) Complete jar repository with configurable start.jar
>
> The $jetty.home/lib directory would be a complete repository with all optional
> modules (jsp, plus, wadi, grizzly, etc) and their dependencies.
>
> The start.config would be limited to by default only including the core jetty
> jars and moderately standard options (ssl and jsp ?).
>
> If you wanted optional modules then you would need to:
>
>  2a) provide a new start.config on the command line, and configure the options within the config file
>
>      java -DSTART=etc/start.config -jar start.jar
>
>  2b) provide start config files:
>
>      java -DSTART=etc/start.config,etc/start-plus.config -jar start.jar
I think more than one is getting a bit complex, no?


Jan

>  2c) provide config options on the command line
>
>      java -DOPTIONS=jsp,plus,ssl -jar start.jar
>
>    The option names would trigger named sections of the start.config file.
>
>
>
> Thoughts greatly appreciated before we start messing with this important component.
>
>
> cheers.
>
>
>
> PS>   here is an example of what a parameterized start.config could look like.
>
>
>
> $(jetty.class.path)                              always
> $(jetty.lib)/**                                  exists $(jetty.lib)
>
> # Set the jetty version
> jetty.version=7.0-SNAPSHOT
>
> # Try different settings of jetty.home until the jetty.jar is found.
> jetty.home=.                                     ! exists $(jetty.home)/start.jar
> jetty.home=..                                    ! exists $(jetty.home)/start.jar
> jetty.home=/home/jetty                           ! exists $(jetty.home)/start.jar
> jetty.home=/usr/lib/jetty                        ! exists $(jetty.home)/start.jar
> jetty.home=/usr/share/lib/jetty                  ! exists $(jetty.home)/start.jar
> jetty.home=/C:/jetty                             ! exists $(jetty.home)/start.jar
> jetty.home=.                                     ! exists $(jetty.home)/start.jar
>
> repository=$(jetty.home)/repo
> jetty.repo=$(repository)/org/mortbay/jetty
>
> # The main class to run
> org.mortbay.xml.XmlConfiguration.class
> $(start.class).class
>
> # The default configuration files
> $(jetty.home)/etc/jetty.xml                      nargs == 0
>
> # Set the jetty common classpath
> $(jetty.home)/lib/**                             always
> $(jetty.home)/resources/                         always
>
>
> [jetty,default,*]
> $(jetty.repo)/servlet-api-3.0/$(jetty-version)/servlet-api-3.0-$(jetty-version).jar  ! available javax.servlet.Servlet
> $(jetty.repo)/jetty-util/$(jetty-version)/jetty-util-$(jetty-version).jar
> $(jetty.repo)/jetty/$(jetty-version)/jetty-$(jetty-version).jar
>
>
> [ssl,default]
> $(jetty.repo)/jetty-ssl/$(jetty-version)/jetty-ssl-$(jetty-version).jar
>
>
> [jsp,default]
> $(jetty.repo)/jsp-api-2.1/$(jetty-version)/jsp-api-2.1-$(jetty-version).jar   ! available javax.servlet.jsp.Page
> $(jetty.repo)/jsp-2.1/$(jetty-version)/jsp-2.1-$(jetty-version).jar
> $(repository)/ant/ant/1.6.5/ant-1.6.5.jar                                     ! available org.apache.tools.ant.Main
> $(repository)/org/eclipse/jdt/core/3.1.1/core-3.1.1.jar
>
>
> [plus]
> $(jetty.repo)/jetty-plus/$(jetty-version)/jetty-plus-$(jetty-version).jar
> $(jetty.repo)/jetty-naming/$(jetty-version)/jetty-naming-$(jetty-version).jar
> (repository)/javax/activation/activation/1.1/activation-1.1.jar
>
>
> [annotations]
> $(jetty.repo)/jetty-annotations/$(jetty-version)/jetty-annotations-$(jetty-version).jar
>
>
> etc. etc. etc.
>
>
> It will be a little bit of a pain to keep dependency versions upto date,  but I'm
> sure that can be automated.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

Johannes Brodwall
Just my two cents:

The way we're using Jetty, we don't care much for configuration files
and the like. So we don't use start.jar (or any Jetty-XML, for that
matter). Instead, we build our own jar that knows what we want.

Given that there is a limited number of options, I would like for you
to consider having start-jetty-grizzly, start-jetty-jsp-grizzly etc.
For the most popular options, this would reduce the need for
configuration files.


~Johannes

On Sun, Apr 6, 2008 at 4:54 AM, Jan Bartel <[hidden email]> wrote:

> Greg Wilkins wrote:
>
>  > We had the attitude that if you don't want something, just delete it from lib.  If you do want something,
>  > then build it from source.
>  Well, at least you could say that this approach had the advantage of simplicity :-)
>
>
>  > BUT
>  >
>  > the problem with this approach is that it discourages a full build of all the
>  > contrib and extra components. For example, we exclude wadi and grizzly from the
>  > default build, because if they put their artifacts into lib they will be available
>  > on the classpath.  This can be confusing and also break some things (as wadi
>  > includes a commons logging impl etc.).
>  Actually I think for a release we should always build and publish ALL of the
>  components (except obviously those that need a specific environment) to the
>  maven repo. That way people don't have to do their own builds, they can just
>  download the jars they want straight into jetty's lib.
>
>
>  > Also the lib is currently organized by optional component, with each option
>  > including it's dependencies.   But if two options both need a common component,
>  > then they both will include it.     Plus we increasing need to integrate with
>  > distros like jpackage and debian that have their own layouts for libraries of
>  > jars.
>  I agree we should look at a better organization of lib for jetty 7. It's a good
>  point about the common dependencies.
>
>
>  > So I am thinking that rather than invent our own lib layout, we just pick one.
>  > So I'd pick maven and we just make lib into a maven repository of jars for
>  > jetty and for it's dependencies.  At least with the same structure for jars,
>  > if not the actual meta-data in poms etc.
>  Well, I'm not sure that we need the depth and verbosity of a maven repo layout
>  (which is great for a general purpose repository, don't get me wrong). Do you
>  really think we need the whole directory naming structure by package and by
>  version? For example, we should never have 2 different versions of the same
>  external library, so we shouldn't ever have org/blah/foo/1.0/artifact-1.0.jar
>  and org/blah/foo/2.1/artifact-2.1.jar.
>
>
>  > A smart start.config like option 2c) below would be able to resolve the
>  > common dependencies and pick the libraries out of the repository.  It could
>  > be easily pointed at a shared repository or converted to jpackage/debian if
>  > need be (and they don't provide a mock m2 repo themselves).
>  Another option might be to make the existing jetty.class.path system property
>  a bit smarter and accept some wildcarding:
>
>  java -Djetty.class.path=lib/mystuff/**/*.jar:lib/special-goo.jar -jar start.jar
>
>
>  > So start.jar will need to be updated to cope with this.
>  >
>  > I see two broad directions that we can go:
>  >
>  > 1) We could follow the apache like example of having libs-enabled and libs-available
>  > All jars would be installed in libs-available, and we would link/copy jars into
>  > libs-enabled.   A standard start.config would then work.
>  Would we need a start.config with this? Why wouldn't we just put everything in
>  libs-enabled/ onto the runtime classpath?
>
>
>  > This has the advantage of making the options very apparent on the disk.
>  > But it really is inventing our own new approach for jars.
>  >
>  >
>  >
>  > 2) Complete jar repository with configurable start.jar
>  >
>  > The $jetty.home/lib directory would be a complete repository with all optional
>  > modules (jsp, plus, wadi, grizzly, etc) and their dependencies.
>  >
>  > The start.config would be limited to by default only including the core jetty
>  > jars and moderately standard options (ssl and jsp ?).
>  >
>  > If you wanted optional modules then you would need to:
>  >
>  >  2a) provide a new start.config on the command line, and configure the options within the config file
>  >
>  >      java -DSTART=etc/start.config -jar start.jar
>  >
>  >  2b) provide start config files:
>  >
>  >      java -DSTART=etc/start.config,etc/start-plus.config -jar start.jar
>  I think more than one is getting a bit complex, no?
>
>
>  Jan
>
>
>
>  >  2c) provide config options on the command line
>  >
>  >      java -DOPTIONS=jsp,plus,ssl -jar start.jar
>  >
>  >    The option names would trigger named sections of the start.config file.
>  >
>  >
>  >
>  > Thoughts greatly appreciated before we start messing with this important component.
>  >
>  >
>  > cheers.
>  >
>  >
>  >
>  > PS>   here is an example of what a parameterized start.config could look like.
>  >
>  >
>  >
>  > $(jetty.class.path)                              always
>  > $(jetty.lib)/**                                  exists $(jetty.lib)
>  >
>  > # Set the jetty version
>  > jetty.version=7.0-SNAPSHOT
>  >
>  > # Try different settings of jetty.home until the jetty.jar is found.
>  > jetty.home=.                                     ! exists $(jetty.home)/start.jar
>  > jetty.home=..                                    ! exists $(jetty.home)/start.jar
>  > jetty.home=/home/jetty                           ! exists $(jetty.home)/start.jar
>  > jetty.home=/usr/lib/jetty                        ! exists $(jetty.home)/start.jar
>  > jetty.home=/usr/share/lib/jetty                  ! exists $(jetty.home)/start.jar
>  > jetty.home=/C:/jetty                             ! exists $(jetty.home)/start.jar
>  > jetty.home=.                                     ! exists $(jetty.home)/start.jar
>  >
>  > repository=$(jetty.home)/repo
>  > jetty.repo=$(repository)/org/mortbay/jetty
>  >
>  > # The main class to run
>  > org.mortbay.xml.XmlConfiguration.class
>  > $(start.class).class
>  >
>  > # The default configuration files
>  > $(jetty.home)/etc/jetty.xml                      nargs == 0
>  >
>  > # Set the jetty common classpath
>  > $(jetty.home)/lib/**                             always
>  > $(jetty.home)/resources/                         always
>  >
>  >
>  > [jetty,default,*]
>  > $(jetty.repo)/servlet-api-3.0/$(jetty-version)/servlet-api-3.0-$(jetty-version).jar  ! available javax.servlet.Servlet
>  > $(jetty.repo)/jetty-util/$(jetty-version)/jetty-util-$(jetty-version).jar
>  > $(jetty.repo)/jetty/$(jetty-version)/jetty-$(jetty-version).jar
>  >
>  >
>  > [ssl,default]
>  > $(jetty.repo)/jetty-ssl/$(jetty-version)/jetty-ssl-$(jetty-version).jar
>  >
>  >
>  > [jsp,default]
>  > $(jetty.repo)/jsp-api-2.1/$(jetty-version)/jsp-api-2.1-$(jetty-version).jar   ! available javax.servlet.jsp.Page
>  > $(jetty.repo)/jsp-2.1/$(jetty-version)/jsp-2.1-$(jetty-version).jar
>  > $(repository)/ant/ant/1.6.5/ant-1.6.5.jar                                     ! available org.apache.tools.ant.Main
>  > $(repository)/org/eclipse/jdt/core/3.1.1/core-3.1.1.jar
>  >
>  >
>  > [plus]
>  > $(jetty.repo)/jetty-plus/$(jetty-version)/jetty-plus-$(jetty-version).jar
>  > $(jetty.repo)/jetty-naming/$(jetty-version)/jetty-naming-$(jetty-version).jar
>  > (repository)/javax/activation/activation/1.1/activation-1.1.jar
>  >
>  >
>  > [annotations]
>  > $(jetty.repo)/jetty-annotations/$(jetty-version)/jetty-annotations-$(jetty-version).jar
>  >
>  >
>  > etc. etc. etc.
>  >
>  >
>  > It will be a little bit of a pain to keep dependency versions upto date,  but I'm
>  > sure that can be automated.
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this list, please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

Greg Wilkins
Johannes Brodwall wrote:

> Just my two cents:
>
> The way we're using Jetty, we don't care much for configuration files
> and the like. So we don't use start.jar (or any Jetty-XML, for that
> matter). Instead, we build our own jar that knows what we want.
>
> Given that there is a limited number of options, I would like for you
> to consider having start-jetty-grizzly, start-jetty-jsp-grizzly etc.
> For the most popular options, this would reduce the need for
> configuration files.

Johannes,

there are quiet a lot of options:

jsp
annotations
plus
jmx
grizzly
wadi
xbean
ssl
ajp

So that's 512 different configurations off the top of my head!

If you don't use start.jar - then this would not affect you as
you build your own classpath.

This is really just about better parameterization of the already
existing start.config file.  Currently it uses existance on the
disk as the main criteria to include a jar or not.   But that
is a poor way to assemble all our options as it means some options
are left out of lib simply so our demo does not run with them.

I'm looking favourably at the option of adding
[name]   sections to the existing start.config file

cheers



--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

Johannes Brodwall
On Sun, Apr 6, 2008 at 11:59 PM, Greg Wilkins <[hidden email]> wrote:

>
>  there are quiet a lot of options:
>
>  jsp
>  annotations
>  plus
>  jmx
>  grizzly
>  wadi
>  xbean
>  ssl
>  ajp
>
>  So that's 512 different configurations off the top of my head!
>

Yes, that is true. How many of these are in common use? Personally,
the only place I might consider deviating from the "recommendede
standard" is jsp. If most people's experience is like mine, they don't
even use ssl, as this is terminated in apache + mod_proxy/mod_jk.
(Furthermore, I have heard recommendations against ajp, but I don't
know whether there's anything to these warnings. But that's a
different discussion)

>
>  If you don't use start.jar - then this would not affect you as
>  you build your own classpath.
>

True. But based on the doc, I get the feeling that you'd like for
people to be using start.jar, and I prefer to follow the straight and
narrow when I can. If you consider using your own classpath just as
valid as doing start.jar, I agree totally with you.


~Johannes

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

Jesse McConnell
In reply to this post by jan_bartel

> the problem with this approach is that it discourages a full build of all the
> contrib and extra components. For example, we exclude wadi and grizzly from the
> default build, because if they put their artifacts into lib they will be available
> on the classpath.  This can be confusing and also break some things (as wadi
> includes a commons logging impl etc.).
Actually I think for a release we should always build and publish ALL of the
components (except obviously those that need a specific environment) to the
maven repo. That way people don't have to do their own builds, they can just
download the jars they want straight into jetty's lib.

I whole heartedly agree, and have this included in a draft of a release post mortem for 6.1.9...we should be building and publishing everything out for each release....its not realistic to expect someone to build minor libraries on the off hand chance they need them.

 

> Also the lib is currently organized by optional component, with each option
> including it's dependencies.   But if two options both need a common component,
> then they both will include it.     Plus we increasing need to integrate with
> distros like jpackage and debian that have their own layouts for libraries of
> jars.
I agree we should look at a better organization of lib for jetty 7. It's a good
point about the common dependencies.

> So I am thinking that rather than invent our own lib layout, we just pick one.
> So I'd pick maven and we just make lib into a maven repository of jars for
> jetty and for it's dependencies.  At least with the same structure for jars,
> if not the actual meta-data in poms etc.
Well, I'm not sure that we need the depth and verbosity of a maven repo layout
(which is great for a general purpose repository, don't get me wrong). Do you
really think we need the whole directory naming structure by package and by
version? For example, we should never have 2 different versions of the same
external library, so we shouldn't ever have org/blah/foo/1.0/artifact-1.0.jar
and org/blah/foo/2.1/artifact-2.1.jar.

both really good points, I like the organizational structure of the maven2 repository, its increasingly a standard and it separates things out cleanly...but jan has a point about an actual release not needing the complexities of a full fledged maven2 repo.  Also when you have multiple jetty installations there is no point in having multiple repositories in that case...or upgrading between versions could be a hassle in that you might want to merge repositories between versions...

If we were to go with the maven2 repository what about having the configuration mechanic grok maven coordinates? 

then you could do something like

# list jetty maven2 repositories
file:///home/jesse/installs/jetty/repository
file:///home/jesse/.m2/repository

# list classpath corrdinates
org.apache.maven:maven-project:1.0
org.mortbay.jetty:jetty:6.1.9

could have a couple of configurations on there for different components the user could uncomment and then the user would have the flexibility to add components to the classpath as desired....just throwing that out there...

jesse


--
jesse mcconnell
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Changes to start.jar for jetty-7

Greg Wilkins

I've implemented in jetty-7 the options mechanism within the single
start.config file.

So the start.config file can now be broken into sections like:

[jetty,*]
...
[jsp,default]
...
[ssl,default]
...
[jmx]
...
[annotation]
...




So if you want to run with jetty+jsp+ssl, it is just

  java -jar start.jar


If you want to run with Jetty+JMX

  java -DOPTIONS=jmx -jar start.jar
or
  java -DOPTIONS=jetty,jmx -jar start.jar


If you want to run with Jetty+JSP+JMX

  java -DOPTIONS=jsp,jmx -jar start.jar


If you want just core jetty

  java -DOPTIONS=jetty -jar start.jar



I think this is independent of any restructuring of the lib to be
a repo.   I'm now building everything all the time.... gee it's taking
a little while.... good old jetty 5 still compiles everything in about 10s!

cheers





--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email