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

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

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.

Agreed. The challenge is defining the starter kits.  Is it a stack of software? an example application? Is it a basic starter thing or does it include tons of technology?... Are there several of them?  Is it just server stuff?  What about EclipseRT on the client? 

BTW, if we are looking for a demonstration app then perhaps Toast (http://wiki.eclipse.org/Toast) is a good candidate.  It is already at Eclipse and we have demonstrated quite a number of EclipseRT technologies (Jetty, RAP, EMF, BIRT, Riena, ECF, p2, Teneo, EclipseLink, ...) integrated on both the server and the client. It has snazzy UIs and a whole book of documentation :-)

The other element is the form. What is this starter kit in actual fact? A zip you download? A project? Target Platform? and who is the audience and what workflow are they expecting?

For example, Dennis at the RT BOF was looking to have a simple Equinox platform that had the framework and p2. Users develop bundles and features, export them to p2 repos, then start the base platform and install/run their stuff.  This might include installing Jetty, EclipseLink, ...

A traditional PDE development flow would have developers write bundles and a .product file and then either launch that from the workspace or export and run it. They may add further bundles using p2 if the product is p2 enabled.

A traditional server developer ...  (actually I don't know with authority what they do)

The point here is not that any of these is right or wrong.  We simply need clarity in what we are trying to support as that drives the form and helps set expectations for the consumers.

FWIW, I strongly believe in the CODA approach. We should be stackless from the ground up. The trick is to make composition of the software *you* need trivially easy.  Think of Yoxos OnDemand (http://ondemand.yoxos.com/geteclipse/start) for runtime platforms. Yup, I would like some Equinox, some Jetty, a bit o EclipseLink, ...  In the end all you are doing is picking features (actually IUs) to compose. This could be in a launch config, .product file, export wizard, command shell, ... The trick is that these stacks are individual and just right for you.

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.

Great! so to recap, what is needed is a single Jetty SDK feature that *includes* the Jetty stuff (and not things from other projects) and can be categorized in the Target Platform category. 

You might also be interested in an Architecture Council discussion I described yesterday in list post.

[eclipse.org-architecture-council] On runtime, SDK and tooling features

Jeff