[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse
- From: Greg Wilkins <gregw@xxxxxxxxxxx>
- Date: Wed, 15 Jul 2009 11:59:45 +1000
- Delivered-to: email@example.com
- User-agent: Thunderbird 184.108.40.206 (X11/20090608)
I'd just like to follow up on Jesse's email with a little more
It may be convenient to think of jetty in two ways.
Firstly there is the Jetty as a code base which includes the
core HTTP server/client and a servlet container. This core
is available as jars either from the central maven repository
or from the eclipse update site that we build.
Secondly there is Jetty as an application server, which includes
the jetty code base, but is bundled with other third party
code into something that can be downloaded and used with
"the usual" services associated with an application server.
These include JSP engine, clustering support, tools integrations,
transaction managers, JDBC drivers etc.
So for the core jetty code base, we are close to being OK.
We have CQs (or are getting CQs) for all of our dependencies
and there are no really difficult ones in there (other than
some standard APIs that have not yet been actually released
yet). The only real issue here is that we consume these
dependencies from the central maven store and not from
If eclispe could provided these CQ'd dependencies in a
maven repository, then jetty could consume them from there.
However, if these jars are processed into eclipse bundles,
then they will need to be identified slightly differently
to the artefacts from the central maven repository (perhaps
with an -eclipse classifier).
I think this is most necessary for the dependencies of
the core code base: servlet-api, slf4j etc.
It is the application server download that is the difficult
one. It would be considerable effort to IP clear all
the common inclusions in such a bundle: JSP, clustering,
So I see we have several choices:
a) Don't make such a download available from eclipse. Only
the jetty components would be available. For the
application server style download, you would either
need to get additional components or an optioned up
download from codehaus. This is the path that we
originally intended to take when we asked to move
the core to eclipse.
b) Put the full application server dependencies through
the standard eclipse IP process and eventually produce
an IP cleared application server. While possibly
the "correct" route, this may be confusing as it could
be seen as THE eclipse application server, even though
it is not using OSGi. It would also raise questions
about certification of the server as either a servlet
container, or JEE container etc.
c) Take a pragmatic middle ground. JSP is the key
additional dependency that many users would like in
both app server and embedded environments. Find
some way to IP clear the bundling of the JSP component
with the Jetty download so that many/most users would
be content with just that. For clustering, JTA, etc.
users would still be directed to codehaus for those
additional modules - but there could be ongoing efforts
to IP clear them and bring the code to eclipse.
We are continuing to work towards a)
But we have received feedback from eclipse members that
they really would like JSP to be included - so that is
suggesting we should aim for c)
If anybody wants b), then I think significant extra
resources need to be found to work on that.