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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

I'll also add that my initial thoughts on it would also allow use to
bundle the cometd.war file from the cometd project which is also a
major component of what makes jetty cool out of the box for some
people.  If we don't put that cometd.war file in the downloadable
distribution we are going to get endless questions asking if we have
dropped out of the box support, etc etc..

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Mon, Jul 13, 2009 at 11:53, Jesse McConnell<jesse.mcconnell@xxxxxxxxx> 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
>