[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse
|
David,
I don't think the issue has ever been a real lack of jsp artifacts
that could be used and I know that a number of us have reached out to
various implementations or forks to help address the embedded issues
and the specific jetty uses cases in the past. What I don't have a
good read on is how we could reasonably expect the eclipse foundation
IP folks to be able to take something like that jasper codebase that
you guys have branched yourselves and then run it through the same
rigor that was applied to the jetty codebase. License wise we should
be totally fine doing that, even with the existing implementation we
use today from the patched glassfish source...we were lucky in that we
had a solid tracking of all contributors and license agreements and
what portions were questionable were small and able to be rewritten by
us on the import in the eclipse svn. Sounds like a nightmare to try
and do that to a codebase we don't work on directly at all. I know
they have approved some jasper in the past as an old version is
available in ORBit but I don't have a clue how that would relate to
say the glassfish source we patch and build the jsp artifacts off of.
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Wed, Jul 15, 2009 at 01:35, David Jencks<david_jencks@xxxxxxxxx> wrote:
>
> 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
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
