Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse 

On Jul 14, 2009, at 6:36 PM, Greg Wilkins wrote:


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.
Geronimo specs are all osgi-bundle-ized already. Servicemix has bundlelized a considerable number of other common jars, but I don't know details on exactly what. 



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.
Does jsp here == jasper? (the geronimo jsp spec is already bundleized). Due to the lack of a trunk release for over 2 years geronimo has recently produced an internal fork of tomcat 6.0.x and also a toolkit for producing tomcat forks built with maven. This forked build produces osgi bundles. If you can figure out the problems with tomcat's jasper compared to sun's jasper you could either... 1. fix the geronimo jasper and use it (may require annotation processing adjustments) 
2. make your own fork using the toolkit.

thanks
david jencks



cheers








































Jesse McConnell wrote:

Hey folks,

There has been some discussion on CQ3432
(https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3432) that we have
been asked to bring to this list for further discussion.  I think I
best start by laying out some basic information so everyone can get up 
to speed and then offer up some bullets at the end for discussion.

First off for anyone that hasn't been following our development over
the last few months, jetty7 has been pushing towards the 7.0.0 release 
with full steam and we are now publishing weekly release candidates.
We have gone through the IP validation process and have recently
gradated from Incubation and are now considered a Mature project.
Rather amusing considering jetty has been under development for well
over a decade!  Anyway, we are currently publishing our artifacts to
the maven central repository with each milestone and release candidate 
that we create.  For those unfamiliar with maven that means that our
jar files and associated dependency metadata are available for users
of maven and other transitive dependency aware build tools at the
following location.

http://repo2.maven.org/maven2/org/eclipse/jetty/
This is where we start getting into somewhat murky water in regards to Eclipse IP. All of our transitive dependency linkages point to other 
artifacts in the maven central repository.  This enables anyone to
checkout our project from svn and run one command 'mvn install' and it 
will build and test the software from top to bottom.  It will also
generate a distribution bundle that mainstream users of jetty are very 
familiar with that lets them unzip it, drop their war file into a
webapps directory and run 'java -jar start.jar' and it starts up jetty and deploys their webapp. The vast majority of our users are familiar 
and comfortable working with jetty in this way, either via the
distribution bundle or as declared dependencies in their build systems which pull our artifacts from the central repository as well as any of 
our dependencies.  We have invested some time into producing an
eclipse update site that follows the eclipse conventions and makes use 
of at least one of the approved eclipse bundles (servlet-api 2.5) an
we have that update site available for usage but it does not contain
the full features of jetty as it is and almost entirely manual process 
involving copying, renaming, restarting, etc of jars, eclipse and PDE
things.

Anyway what is means is that the distribution bundle that we produce
and make available for download to our users contains artifacts from
the central maven repository as they are declared in our transitive
dependencies that we build against.  We maintain our IPLog according
to standard eclipse procedures, endeavoring to make sure that we are
logically linked up to approved versioned eclipse bundles for things
like the ASM (dependency for processing annotates i believe). However 
we do not grab the asm 'bundle' from the eclipse foundation and place
it in our distribution lib directory, we use the standard one from the 
maven central repository.  This means that our distribution is not a
one stop shop for anyone that would use jetty for equinox osgi
purposes, it is instead the jetty7 version of the standard jetty
distribution that our normal jetty container and maven users are
intimately aware of and used to using.  We have made allowances for
previous integrations that we would not have been able to get past the 
Eclipse IP validation process due to dependencies that we previously
have shipped or would greatly like to ship with our jetty
distribution, for example it would be nice if we were able to ship our 
terracotta integrations with jetty but we don't really have control
over getting the terracotta dependencies passed through the eclipse IP process so we maintain those integrations at The Codehaus and have yet 
to really address how we are going to make it easy for our users that
have sort of come to expect those things from our normal
distributions.

Which brings us to JSP support and where we are right now [1] for jsp
support.  We identified this issue a long time ago as something that
we would have to resolve and we have talked to both Jeff McAffer and
Simon Kaegi about it in the past I believe...but there is no super
solution to it as JSP has been plagued by many historical problems.
Fundamentally the take away here is that jetty is widely in use as
both a traditional servlet container and as an embedded servlet
container, both of which have wide jsp usage.  There is no existing
jsp artifact that we can easily adapt to our needs that exists in a
simple jar format that we can get passed through the eclipse IP
process.  There are multiple copies of the jasper jsp implementation
under varying degrees of patched status for years worth of bug fixes
and security issues.  Everyone in their brother seems to maintain
their own copy of jasper.  So what jetty has decided to do is use the
glassfish copy of jasper as at the time it seemed to be kept the most
current and we check out the source from a tag in their svn, modify it 
slightly to patch any bugs our users have detected that have not been
picked up by glassfish yet and to adapt it so as it embeds with jetty
well into any of our users that make use of embedded jetty jsp
containers.  Given the eclipse ip validation process we decided early
on (at least I did, if I was wrong I'll take the blame) that we didn't 
want to tackle that beast of a audit.  Code that originated from
Tomcat X years ago, got forked into Glassfish Y years ago and has had
committers contributing to it a fashion that we don't directly know
about seemed an insurmountable challenge to take in parallel to the
jetty codebase validation which was actually pretty easy when all was
said and done.

We were content to leave this out for the incubation process but now
that we are moving towards our 7.0.0 official release we have to bring 
it back up as can not really skip out on JSP support for our official
jetty releases for jetty7.

What I would really like to see is the following:
Allow jetty to have three modes of 'release' from the eclipse foundation. 

1) A standard standalone distribution that is allowed to package
whatever integrations and third party artifacts as it has in the past. 
This would let us provide JSP support as we require and also package
in things like the terracotta integration and win32 service wrappers.
Basically allow jetty to offer out the standard jetty distribution
that it always has only downloadable from the
http://www.eclipse.org/jetty download page.  If there are particular
notes or warnings that we would need to add to this distribution
absolving the foundation of any liability in terms of users
downloading it and not getting that eclipse IP validated source deal
we would be perfectly happy putting that text in place.  So it is
clear, no SOURCE would exist in the eclipse svn that violated any
eclipse rules, this option would simply allow use to continue
servicing our users the best by bundling (all license friendly of
course) artifacts in our downloadable distribution.

2) Normal maven artifacts published to the maven central repository.
(already doing this)

3) The eclipse update site that only contains the approved eclipse
bundles wired together into a p2 update site as I have been working on 
maintaining [2].  This would be a letter of the law mechanism that
users of osgi and followers of eclipse IP procedures could be entirely 
safe in their usage and probably more in keeping with the traditional
way that project in eclipse work.
I could go on but as this is personally my IDEAL solution to the issue of including JSP support into the downloadable distribution, basically 
granting us the exemption to package our integrations and things like
JSP support into our distribution.  Other options include trying to
get the JSP integrations passed through the ip validation process but
we run the risk of having to migrate our primary user downloaded
distribution from eclipse back to codehaus because of timing issues.
We could get an exemption for specifically the JSP artifacts as well
but if we are getting that exempted then we might as well do the
terracotta integration and some of the other things we maintain at the 
codehaus as well that our users would directly benefit from.

I eagerly await your responses!

jesse


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=282174
[2] http://download.eclipse.org/jetty/7.0.0.M4/update/

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev

Back to the top