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

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.

>
> On a related topic, we had a discussion in the RT PMC call this morning around EclipseRT projects providing content in the Helios Target Platform repo category. IMHO this is the critical enabler for the EclipseRT community. They need to be able to get their chosen runtime technology into the target and develop, compile and build against it. To facilitate that I volunteered to work with any project wanting to get their content into shape for this.
>
> Looking at what you have in Jetty it seems you are pretty close. Some comments and thoughts embedded below...
>
>>> 1- An update site with a few features and their associated source features:
>>> http://www.intalio.org/public/maven2/org/intalio/osgi/updatesite-7.0.2.v20100331-03/
>
> Potentially minor thing but is this really and Update Site or is it a p2 repo? Project contributing to the Helios repo need to be making p2 repos I am told.
It is a P2 repository
(http://www.intalio.org/public/maven2/org/intalio/osgi/updatesite-7.0.2.v20100331-03/content.xml),
sorry for the confusion.
Everything we do consists of generating a set of features and then a
p2-repository.
Even the standalone distribution prototype is first a p2 repo:
http://www.intalio.org/public/maven2/org/intalio/osgi/updatesite-7.0.2.V20100331-standalone/content.xml
We then use a maven plugin to package the bundles slightly differently.

>
>>> 2- A standalone distribution of equinox, jetty and their source-bundles:
>>> http://www.intalio.org/public/maven2/org/intalio/osgi/updatesite-7.0.2.V20100331-standalone/org.eclipse.jetty.dist-7.0.2-SNAPSHOT.tar.gz
>>> The layout is biased towards jetty. In the context of eclipse-RT we
>>> should definitly place all the jetty's related folders inside the
>>> configuration area
>>> (eclipse/configuration/org.eclipse.jetty.osgi.boot).
>>> The layout supports the legacy webapps and other J2EE shared classes
>>> folder: we could certainly choose to remove all this and use a jetty
>>> config that supports only web-bundles.
>
> 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.

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

>
> Aside, I would suggest moving the "eclipse" dir up a level essentially eliminating it. just have plugins and features at the top level.
>
>>> Everything here was built with maven3-tycho pointing against the
>>> eclipse-3.6 update site and the jetty jars released on maven
>
> 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.

>
>>> The idea of pointing the IDE directly on build to start debugging and
>>> hacking is something that is very convincing from a developer and
>>> management perspective.
>
> Absolutely. It would be interesting to talk more about who the target for this is...
>
>>> Future improvements: managing installations and updates with P2
>
>>> -----------------------------------------------------------------------------------------------
>>> The current prototype is based on the old
>>> org.eclipse.update.configurator plugin.
>
> Boooooo ;-)
>
>>> We would like to be able to manage this runtime with P2.
>
> Yaaaahhhh
>
>>> I have been looking at defining an eclipse application based on Scott
>>> Lewis suggestion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=245267
>>> Here is the work in progress:
>>> http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/eclipse/trunk/jetty-features/org.eclipse.jetty.product/
>
> Making a p2 enabled backend certainly is interesting.  You've mentioned Scott's stuff. You may also want to look at the Toast direction.  Very similar. In the end it comes down to what you are wanting to facilitate.

Scott offered his help and pointed me to his work with the servletbridge.
I'll look at this one too.

>
>>> Although I am not sure I am heading in the right direction as PDE
>>> would not let me export a product that does not define an application.
>>> I have not convinced maven3-tycho to build this product either.
>
> there must be something in what you are going that is causing PDE problems. The OSGi and Equinox book, Toast examples and our commercial courses use application-less products all the time.  Must be something simple in the details.

OK thanks for the link to Toast. Just knowing that this is the way to
go is great help.

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

Thanks,
Hugues.

>
> Jeff
>


Back to the top