[rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclip

[Greg Wilkins <gregw@xxxxxxxxxxx>]

All,


I'd just like to follow up on Jesse's email with a little more
information.

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
eclipse servers.

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,
JTA etc.

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.

cheers