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

[Hugues Malphettes <hmalphettes@xxxxxxxxxxx>]

Jeff,

I updated the bug about the jetty features:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=307571

On Thu, Apr 8, 2010 at 8:08 AM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
>>> 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.
>
> I agree that doing something simple is good. The thing I really want to avoid is putting out one simple sample and then spending years countering the initial image that EclipseRT is Equinox+Jetty+EclipseLink. We have seen this time and again.  People's first impression is very powerful. That cuts both ways. If it is too abstract, they don't get it. If it is too concrete then it gets pigeon holed.

Greg and the rest of the jetty team suggested to distribute at eclipse
exclusively the equinox based packaging of jetty: we can avoid the
confusion between EclipseRT and jetty if we simply call that
distribution Jetty-Equinox-Distro; or Jetty-EclipseLink-Equinox or
something.

>
> So, I am not against any of this but I do want us to at least put some thought into the message we are sending and the impact of that message. This could result in something as simple as what we name the package to how many packages or what's in them. For example, consider the different messaging in naming Equinox+Jetty+Eclipse link the following ways:
>        EclipseRT Platform
>        EclipseRT Server Starter Kit
>        Jetty Distro
> These all set completely different contexts and expectations and implications.
>
> Related, if there is only one then the implication is, this is it, this is *the* EclipseRT deliverable. Two admits the possibility of options.  Three allows induction.
>
>>> 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 Toast backend is a couple of servlets and some persistence. It is independent of the client. Toast has been specifically designed in the CODA model where you can take as much or as little as you want/need. You are right that Toast in its entirety is too much for an intro example. So the approach should be to deliver just the base backend stuff as the initial example and then show how it can be extended with all the other EclipseRT tech in more advanced examples.
>
>>> 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.
>
> Sorry but what does someone do with the zip download? It if is a sample app, I get it. download, unzip and run. I'm not sure that is really the "package" we are talking about putting on the main download site. Or is it? If the developer is expecting to develop against this package, then I'm not sure that the zip download is doing them any favors.  That is why we are moving away from that in the broader context.

At my work, the type of runtime we are looking for
1- Follows the CODA principles.
2- Is installed and maintained completely outside of any UI and if
possible any tools at all.
3- Integrates nicely with the tooling for the developers and the
Continuous Build.

It is almost a requirement that the architecture of the runtime does
not look 100% biased towards eclipse-tooling; this addresses the IT
administrators and teams who have a knee-jerk reaction with eclipse.

Is not it a very thin line between a starter-kit and an actual runtime?
Making sure that the runtime can be used as an alternative entry point
into the development cycle is very important to us:
we can take any build and start debugging it.

Scott's product configuration
(http://wiki.eclipse.org/EclipseRT_for_Amazon_EC2) and the Toast
product configuration look like they might support do what we need.
So we can continue experimenting with this.

I hope this helps.
Hugues.

>
>>> 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.
>
> I'm talking about how they develop not what the develop. What is the workflow the audience of this package expects? What workflow do we want them to use? That directly impacts the form and content.
>
>>> 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.
>
> Agreed 100%. But that does not mean we abandon CODA as the underlying principle of our approach so that as devs get more comfortable/familiar the shift is not a paradigm change but a transition along a spectrum. CODA should inform our direction.
>
> Jeff_______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>