Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[rt-pmc] jetty dependency's and 'releasing' within eclipse

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


Back to the top