Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] jetty packaging at eclipse-rt: status and questions



On 4/8/2010 9:03 AM, Jeff McAffer wrote:
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?

One thing I know is that if you try to answer all these questions no package will ever get built. Right now there is no/zero/nadda entry point into EclipseRT. There is a huge gap between the theory of OSGi/EclipseRT and the common developer that wants to get started. Most developersuse servlets today and do persistence of data. This is why I think the Jetty/EclipseLink scenerio is so compelling. I would start with that.

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 :-)

Sorry but Toast is way too complicated. It is a nice demo and a wonderful book but it is just too much go people to get started.


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?

Zip download.


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)

Focus on developers writing servlets and need data persistence. A simple CRUD application.


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.

CODA is an architecture approach that may come once people understand how to build applications using bundles. You can't start with CODA for a common developer. It is just too abstract.



Back to the top