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

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Jeff McAffer wrote:

> My point was that the creation of "packages" can easily get out of hand and end up being counter productive. 

I could not agree more.  We already suffer from too many ways to bundle jetty.

But I also agree there is scope for an eclipseRT easy start download that is a
usable/demonstrable integration of RT components.   Maybe not quite a Petshop
like example... but maybe inspired by that.

>>> 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.

I think the decoupling already exists.   The jetty components certainly
have no requirements for any disk and/or bundle layout.

So it should just be a matter of wiring up the target platform category
to make the jetty bundles easily available.

cheers