Re: [rt-pmc] jetty packaging at eclipse-rt: status and questions

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

On 2010-04-07, at 7:40 PM, Hugues Malphettes wrote:

> Thanks for the review.
> 
> On Wed, Apr 7, 2010 at 1:26 PM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
>> It is certainly possible have something the Eclipse downloads site.  It would be great to get some other things there as well so we could have an EclipseRT section of the page.  Having said that, in various discussions of late we have been simultaneously shying away from making "stacks" but recognizing that consumers will benefit from "starter kits". It is a balance we need to walk.
> 
> I answered to Ian with an RT-hat: it should be an RT distribution that
> contains more than jetty: we demoed EclipseLink + Jetty already at
> eclipse-con.

My point was that the creation of "packages" can easily get out of hand and end up being counter productive. We have to balance between the convenience of having a few "starter kits" and the horror of a Vietnamese restaurant menu approach of combinatorial explosion in choice.  A good guide here should be the CODA whitepaper that outlines the EclipseRT philosophy.
See http://www.eclipse.org/eclipsert/whitepaper/eclipseRT.php

>> This is an interesting approach.  Basically it is a zipped up generic project that contains an eclipse install that includes Jetty. The stuff at the top level is all the infrastructure/configuration directory structure needed to populate and run Jetty. I can certainly see this being useful as a starter for people.
>> 
>> The challenge is that the one thing is; runnable, a project and a target platform. These multiple roles will inevitably conflict and not line up with or leverage the conventional Eclipse/PDE workflows etc. The key her is to also supply the elemental parts of this archive.
>> 
>> - Target platform content as a p2 repo
>> - Eclipse product definition
>> - Basic template of a Jetty system
>> 
>> I'll take each of these in turn.
>> 
>> Target platform: Here you are 95% of the way. You have all the features, source bundles, ... all you need is that published as a p2 repository. p2 has a "publisher" that can accomplish that for you. I would also suggest adding one more feature, the Jetty SDK, that references all the features you have here. Then nominate that feature to be categorized in the Target Platform category of the Helios repo. Then users can simply add that feature to their target and combine it whatever else they need/want.
> 
> In fact that is what we are doing for Jetty to be on the Helios train.
> Here is the site
> http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/trunk/jetty-features/org.eclipse.jetty.site/site.xml
> The features there are the jetty ones, the jsp one and they import
> bundles provided by other eclipse projects.

Super.  We should talk a bit about the features and categorization. I'd like to see one Jetty SDK feature that, when added to the target platform using p2, delivers all the various Jetty bundles and features. 

>> Product definition: For people building runnable Jetty based systems they like to click and run a product.  The product captures all the runtime libs (bundles) as well as program and vm args and other configuration info.  You can supply your users with starter product files that they can use to create their systems.  At one point you mentioned that you had to have an application. Since 3.5 the product definition editor does not require you to do this.  Take a look at how things are structured in the Toast examples (http://wiki.eclipse.org/Toast).
>> 
>> Basic template: I'm inferring here but it seems that Jetty works well with a particular layout on disk. From an Eclipse product point of view these are "root files". The question here is whether or not you expect users to modify these during development  or if they export and then drop stuff in these dirs. The approach here depends on that answer.
> 
> In fact this is quite decoupled already: the system property
> "jetty.home" points to a folder where we find that traditional jetty
> layout.
> We can:
> - put it somewhere else for example: inside eclipse/configuration.
> - trim down the configuration file so that we don't need this at all.
> This layout is nice to support legacy webapps and the shared class
> folder. It is not useful if the users are going to develop web bundles
> alone.
> The rest of the jetty team keeps telling me "we don't need jetty.home".

The decoupling I'm after is different. Ideally developers would not have to get any zips/archives or put any bundles in their workspace. The Jetty SDK feature should just be in the Helios repo in the Target Platform category. With that they can add it to their target very easily and have great flexibility in how they manage their targets.

The downside is that they still need a product definition to start from and the basic file system layout if that is important to them. So, if you take your current zip, remove all the targets, bundles and features, then you have the decoupling I'm talking about. I'm not sure of all the details of how Jetty discovers or uses these locations but hopefully it is independent enough that a product definition can be constructed.

>> Just to be clear, are the jars coming from Maven (assuming you mean Maven central here) Jars that have come from Eclipse (either from Jetty, Orbit or some other Eclipse project)?
> 
> They all coming from eclipse-3.6 P2 repo except for:
> - the jetty jars. This is temporary and as soon as the jetty jars are
> signed and available in eclipse-3.6 P2 I'll remove the maven's ones
> from the pom.xml
> - the eclipse java compiler. I could not find it on eclipse P2
> repository. The one on eclipse downloads would do fine. It is not
> signed either.

Interesting.  It should be in the repo.  I suspect it is not signed for performance reasons.  When you load a signed JAR using a conventional classloader (actually, JarFile) it is very slow as it verifies all the entries. The Equinox infrastructure is smarter about that and does not by default check the sigs at load time.

>> Generally sounds good. I'd be happy to talk with you more about the details.  As I say I think you are 95% there and I'd love to get the last 5% to get full Jetty integration into the Eclipse workflows.
> 
> I will make it work with jetty as my primary use case and will keep
> you updated if other projects wants to do something similar or add
> their bundles to the distribution.

Just to reiterate, please separate between the creation of a package/distribution and your contribution to the Helios repo and categories. I am mostly talking about the latter and want to ensure that Jetty is easily consumable via the PDE workflows.

Jeff