[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rt-pmc] Re: Jetty-distribution
- From: Greg Wilkins <gregw@xxxxxxxxxxx>
- Date: Wed, 29 Jul 2009 09:48:27 +1000
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 22.214.171.124 (X11/20090608)
eclipse rt-pmc (cc jetty-dev),
Before the rt-pmc call today, I'd like to make a few comments regarding the
jetty distribution issues.
Firstly, no matter what is decided on the maven repository issue, we will be
providing all the jetty code as standard eclipse bundles available from a
standard eclipse update site using standard eclipse names. We have a bit
more work to do on that, but it is mostly available now.
Also note that other than the servlet-api, all jetty's external dependencies
could be described as works with relationships for optional components.
It is just that for many of these options, we have previously bundled
the dependencies so that they can work out of the box.
Thus the issues Jesse has raised, are not so much about how we can provide
jetty to the eclipse/OSGi community, but how we can continue to provide
an acceptable solution to the existing Jetty user base.
So for the existing jetty/maven user base, there are some things that we
are not able to change:
+ We can't setup a temporary maven repository and serve our dependencies.
One of the main features of maven is to have repeatable builds, so you
should only use repositories that you can have a reasonable expectation
of having a lifespan that will exceed that of the project. Thus we can
only switch to a repo that is non temporary in nature and has core support
from the organization that hosts it.
+ We can't have a maven repository that serves conditioned artefacts under
the same name space as the existing artefacts. The tuple of
groupID:artefactID:version must identify an immutable binary artefact
that is identical from all mirrors. Thus we can only switch to an
eclipse repository that has distinct naming. Design of this naming
is something that will need care and thought so that it will cater to
all eclipse projects and needs into the future. So again this
argues against a temporary maven repository solution.
+ The standard jetty distro package is based around maven naming conventions
that are distinct from eclipse naming conventions. While it would be
technically feasible to change the standard distro to use eclipse naming
conventions, I do not think if fair on our existing user base to force
yet another significant change on them as they have already been subject
to major disruptions.
When we moved the Jetty project to eclipse, we were always aware that there
would be some optional parts of the project that would be highly unlikely that
would ever be distributable from eclipse. Thus we have always described
it as jetty components @ eclipse, which are assembled into a jetty application
server @ codehaus.
The jetty project is quiet content to go forward on that basis. Ie we can
build a jetty bundle update site at eclipse, but not a downloadable
application server style distro. We can continue to build a application
server style distro with dependencies at codehaus.
I think this is perhaps the simplest way forward in the short term.
Of course there is desire to have an executable downloadable distribution
from eclipse. But we will need a carefully designed eclipse maven
infrastructure for that, plus a commitment to support it into the
future. We should not rush that design or commitment and we should
certainly involved other projects in it's formulation so that it is
not just a jetty facility.
But regardless of the maven repository, we will continue to CQ all
our dependencies so that our OSGi bundles will be clear and there is
scope to use the eclipse maven repository once available.