Community
Participate
Working Groups
Created attachment 123701 [details] first cut at a "core" feature Getting p2 setup to run in a basic system can be a challenge. The inclusion of the p2 SDK feature has helped people get RCP apps up and running. (some review of that usecase should be done but that is not the topic here). For the very basic headless case it should be possible to define a feature that adds provisioning function to a system. I'll attach a first cut at this. This one only works on the filesystem but people can add additional ECF providers for whatever transports they like (that 's the whole idea of using ECF :-) The only thing that sticks in my mind is the inclusion of ExamplarySetup. Ideally we would be able to get rid of this but I'm not sure that is possible. Note that I randomly chose p2.core.feature as the name. Could not think of anything better at the moment.
In order to help draw a line, could you describe the use cases that this will help with? Is the point of trying to provide something functional to install plug-ins or just a minimal core? Also I noticed that it does not include org.eclipse.equinox.p2.updatesite. Is this intentional? ECF, we need to have it be required instead of being included so we can express ranges. I would also add org.eclipse.ecf.provider.filetransfer.ssl. and org.eclipse.ecf.ssl
This feels strange, as there are no other "core" features that I'm aware of. Does this lead to creating "core" slicings of rcp, platform, jdt, etc? Is this just a convenience because the p2 bundle granularity is so small?
The purpose of this feature is to supply the bare minimum required for provisioning using p2. No UI, no particular transports (other than the file transport which we could remove if needed) etc. Basically remove all assumptions about what and how things are being provisioned but yet supply the core provisioning function. From here people can reasonably simply add the transprots they require as well as the UI bits they want and any other tooling (publisher, ...) This feature is directly useful in server side provisioning configurations for example. updatesite is intentionally left off. Many realworld situations are isolated and simply do not have update sites. ssl and the other transports are added as required. The "coreness" of this is partially because of the granularity. It could be argued that the RCP feature is indeed the "core" of the Eclipse Platform. Note here core is not really meant to denote GUI vs headless. More like essential. Like I said, i was not particularly inspired wrt naming.
What is the thinking here? This would be very useful to have in general. note that if bug 262331 is not fixed, ew have to add the publisher to the feature.
I think that this is also related to bug# 249525 (Scott requests a headless installer). Here's the scenario that I would like to cover. The current version of the headless Buckminster command is available as a zip file. An ant script can download and configure it with various features (CVS, Subversion, PDE support, etc.) and then use it for subsequent work during the build. The new version that I'm working on right now is slightly different. No zip file. Instead, we make everything (including the headless command interpreter) available as IU's in a P2 repo. One link is missing however. How do I get the product? Ideally, I'd like to see a minimalistic headless director app zipped and packaged for download. My ant script could then download, unzip, and then use it to install my product. Is such a zip something that could be considered as a complement to the current installer? I would be happy to help out fixing this but I'm not sure where to start. The "core" feature is a good start but how do we get from there to something that can be downloaded adjacent to the current installer?
Thomas, I think you are requesting something different than what Jeff is in the sense that you are after a "product" whereas Jeff is after providing a cut of the world easing the re-consumption of p2 in headless scenarios. For now I would recommend open a separate bug, because I don't see this one coming to an agreement quickly because there is just way to many ways to slice and dice the p2 plug-ins in interesting reusable pieces.
OK, I added bug# 267623 for the "headless director product".
Created attachment 150004 [details] proposed p2 core feature The attachment is a zip with three feature projects: 1) org.eclipse.equinox.core.feature 2) org.eclipse.equinox.p2.core.feature 3) org.eclipse.equinox.servletbridge.feature Feature #1 includes just org.eclipse.osgi and org.eclipse.equinox.common bundles (equinox core). These could be put in #2 or elsewhere, but I wasn't sure what was desirable. Feature project 2 contains bundles for headless p2. Feature project 3 requires features 1 and 2, and has the remaining bundles necessary for creating an Equinox server deployed via war file as described by bug 245267. I'm expecting that feature project 3 will change as appropriate given the recent work by Simon on the servletbridge extension bundle, and the addition of a template project. So feature project 2 is the one associated directly with this bug. 1 and 3 are present in the zip for context.
I added this to bug 291397 but thought I'd duplicate it here as well... I suggest looking at the org.eclipse.example.toast.server.*.feature in the Examples project repo. There are a couple features there for the solo jetty case and the embedded/servlet bridge case. These features should really be in Equinox as something we ship. They allow one to switch their product between the simple, jetty and war based HTTP service support just by swapping the features. For a p2 milli war you would also add in a (to be created?) p2 milli agent feature that would add generic p2 function to any app (server or otherwise). On top of that people just add the ECF transports they need etc and away you go. this approach creates the basic building blocks and lets people assemble them as needed. Take a look at the .product files in the Toast project in CVS for examples. We did not break out the basic p2 agent feature per se. The "org.eclipse.examples.toast.backend.p2.feature" is sorta close to what would be needed but there is a fundamental decision to be made around duplicate bundles in features. For example, that feature includes equinox.security cause p2 needs it. But it is entirely likely that in many cases the bundle will be there for some other reason. Are we ok with the duplication? With hard version binding in feature includes it may become a prolbem.
Removing target. For now we've carve out the slice of p2 we need for server-side apps and put them in a feature specifically for server applications. This is in the "org.eclipse.equinox.server.p2" feature in the server-side folder of the equinox repo. This might be a good place to start if we had a p2 core feature but not planning on doing anything further for now.
Here is an alternative composed of multiple features, trying to separate things in reusable blocks not requesting an all or nothing approach. - org.eclipse.equinox.p2.core (just the core things, w/o any touchpoint) engine director ecf metadata gc - org.eclipse.equinox.p2.equinox (support to manage an equinox instance with p2) native touchpoint eclipse touchpoint - org.eclipse.equinox.p2.ui (the p2 ui bundles + the operations) operations p2.ui bundles - org.eclipse.equinox.p2.discovery (the discovery ui bundles) - org.eclipse.equinox.p2.eclipse.sdk (the integration of p2 in the eclipse SDK) dropins update.site
Obviously I am in favour of this move. We can argue over bundle X in feature A but the general direction is good. A few general comments - I'd avoid the use of "sdk" in the feature name. Perhaps tooling or ide or ... SDK has other implications. Actually in this case, we should likely avoid both! - Not sure discovery merits a distinct feature. Could be but I'd caution against having a lot of features. - WRT ECF, have to decide what transports etc are to be included. - operations seems like something core. - places to look for consumers include the server side and Toast features mentioned in previous comments.
differing.
My apologies for commenting on this bug on the late. In the context of a headless p2 on which jetty could be installed we would need: Requirements - local and remote provisioning: start and provision jetty from the eclipse helios update site. - no SWT, no UI: traditional server-side developers react question those. Nice to have for our case: - dropins support. disclaimer: it is limited, complex, buggy and comes with a "don't go in production that way". but it does lower the adoption barrier for developers who "just" create a couple of bundles. It is closer to the life-cycle of a traditional webapp (export an artifact, put it in a folder) and also to what apache-felix does. - Probably something related to the bug #267623: no OS dependent launcher; shell and batch scripts is what traditional server-side developers are comfortable with. I hope this helps. I'll be trying things in an incubation area of the jetty svn based on the various attachments here, the Toast cvs, equinox-server-side feature (Simon's feature: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/server-side/features/org.eclipse.equinox.server.p2/feature.xml?revision=1.9&root=RT_Project&view=markup) and the amazon-Ec2 example.
Sorry for linking the wrong bug, you will find the right one here: bug 315467
Please ignore my comment. I commented the wrong bug.
Jeff has introduced a number of new features as part of the 3.7, including one called org.eclipse.equinox.p2.core.feature.
