Community
Participate
Working Groups
Created attachment 170013 [details] proposed feature In order to define an Equinox starter kit we need a feature that captures the simple/common/core functionality needed by Equinox systems. This is not intended to be the ultimate minimal feature but rather something that is easy to understand and widely useful. I've attached a proposed feature structure. Would like to get this in for Helios as we want to make the Equinox Starter Kit available in that timeframe.
Some comments: - Usually our feature ids don't contain the word "feature". The resulting IU in p2 would be org.eclipse.equinox.core.feature.feature.group. - Is there any intended relationship between this feature and org.eclipe.equinox.core.sdk feature? They seem similar except for the additional source in the core.sdk, but there are some other differences: for example core.sdk includes equinox.security but core.feature does not. The similar names might lead people to think equinox.core.sdk is just equinox.core + source. - The set of bundles seems somewhat arbitrary. Why jobs and registry but not security and eventadmin for example? In the context of equinox I'm not sure what "core" means so it would be interesting to know what use cases we have in mind for this. - Should the other equinox features be re-shapped in terms of this core feature? For example have things like the p2 server and equinox.core.sdk features include this one rather than including overlapping sets of bundles? - RC3 seems awfully late for slipping in something like this. Our final build is eight days away, and it seems there is no time here to get community feedback and tweak the shape/contents of the features before we ship. I can see this as "nice to have" for the community but not really pressing enough for a last minute fire drill. Should we just make it available as a "sample" feature somewhere, and then tweak it based on community feedback into something more concrete for the next release?
(In reply to comment #1) > Some comments: > > - Usually our feature ids don't contain the word "feature". The resulting IU > in p2 would be org.eclipse.equinox.core.feature.feature.group. I was discussing this with Jeff and there seemed to be some confusion on that point. My recollection was the same as yours John, that we did not want to include the word feature in the name. > > - Is there any intended relationship between this feature and > org.eclipe.equinox.core.sdk feature? They seem similar except for the > additional source in the core.sdk, but there are some other differences: for > example core.sdk includes equinox.security but core.feature does not. The > similar names might lead people to think equinox.core.sdk is just equinox.core > + source. There is no intended relationship here. We struggled a bit for a good name. I suggested something like org.eclipse.equinox.runtime, but that also has some drawbacks. The SDK feature is only intended to provision target platforms and is not intended to provide input to feature base products where the equinox.core.feature is intended to provide the core equinox functionality needed to build feature base products. > > - The set of bundles seems somewhat arbitrary. Why jobs and registry but not > security and eventadmin for example? In the context of equinox I'm not sure > what "core" means so it would be interesting to know what use cases we have in > mind for this. The set of bundles ended up being the parts that got split out of org.eclipse.core.runtime + DS. Somewhat arbitrary, but is really a "core" set of bundles we find useful for a base equinox runtime. This is not to say there are not other combinations of bundles that are just as useful but this base is a good starting point. > > - Should the other equinox features be re-shapped in terms of this core > feature? For example have things like the p2 server and equinox.core.sdk > features include this one rather than including overlapping sets of bundles? Likely but we did not want to consider that now. > > - RC3 seems awfully late for slipping in something like this. Our final build > is eight days away, and it seems there is no time here to get community > feedback and tweak the shape/contents of the features before we ship. I can see > this as "nice to have" for the community but not really pressing enough for a > last minute fire drill. Should we just make it available as a "sample" feature > somewhere, and then tweak it based on community feedback into something more > concrete for the next release? I agree it is late. I think if we don't do something in equinox it is likely the jetty folks will simply create their own feature in helios with a similar set of bundles.
(In reply to comment #2) > I was discussing this with Jeff and there seemed to be some confusion on that > point. My recollection was the same as yours John, that we did not want to > include the word feature in the name. I had the opposite recollection and looking through the current features we seem to have some with and some without. I'm not actually fussed about the IU id or the feature ID for that matter, people generally don't see them. It is a bummer that the project name would overlap with a yet to be created bundle by that name. If we ever get non-project feature capabilities then this is all moot. > > - The set of bundles seems somewhat arbitrary. Why jobs and registry but not > > security and eventadmin for example? In the context of equinox I'm not sure > > what "core" means so it would be interesting to know what use cases we have in > > mind for this. > > The set of bundles ended up being the parts that got split out of > org.eclipse.core.runtime + DS. Somewhat arbitrary, but is really a "core" set > of bundles we find useful for a base equinox runtime. This is not to say there > are not other combinations of bundles that are just as useful but this base is > a good starting point. What Tom said. Roughly we were guided by the core.runtime bundle. I'm completely open to additional things but would like to keep the "core" reasonably small. > > - Should the other equinox features be re-shapped in terms of this core > > feature? For example have things like the p2 server and equinox.core.sdk > > features include this one rather than including overlapping sets of bundles? > > Likely but we did not want to consider that now. Absolutely. > > - RC3 seems awfully late for slipping in something like this. Our final build > > is eight days away, and it seems there is no time here to get community > > feedback and tweak the shape/contents of the features before we ship. I can see > > this as "nice to have" for the community but not really pressing enough for a > > last minute fire drill. Should we just make it available as a "sample" feature > > somewhere, and then tweak it based on community feedback into something more > > concrete for the next release? > > I agree it is late. I think if we don't do something in equinox it is likely > the jetty folks will simply create their own feature in helios with a similar > set of bundles. Yeah, this was one of the motivators for keeping it small. I'd be quite happy to find a way of not committing to the particulars for Helios. Tom and I talked about putting "internal" in there or something. In the end we really just need something that can be put in the Equinox Starter Kit that was discussed at EclipseCon. The Jetty guys are putting this together along with a Jetty Starter Kit and found the problem with our feature structure. So either they define the feature or we do or we don't do the Equinox Starter Kit.
Jeff, Should this be dupped to bug327963?
Created attachment 181242 [details] updated proposed features hmmm, embarrassing when you open two different bugs that are basically the same... There is a slight variation in the proposed core feature contents and the new proposal has some additional p2-related features. I'll close the other as a dupe and move the attachment here as this bug has some discussion.
*** Bug 327963 has been marked as a duplicate of this bug. ***
I've some general-interest questions that are more related to the science(?) of how people construct features and their relationships. I don't currently have any use cases for this particular set of features ... but, you never know, could by the time Indigo is over :) From looking at the zip of features, there are three features in there. Are you saying there would be some new, fourth feature that includes these three features? Or just that this set of three is the minimal runtime set of feature, and someone just knows to get all three. I see the p2.extras feature "requires" the other two. What's the reasoning for that? If its purpose is to magically pull in the others (during an install) then seems a little counter intuitive (that someone would request the extras feature, in order to get core minimal functionality). That would be solved if there was a fourth "container" feature, that made sure the three when together. Also, how do you propose to handle the runtime vs. sdk sets of features. For each of these will there be a corresponding SDK feature, or in your view of the world are those completely separate constructions. I myself always like the close, parallel definitions, since easier to understand ... but, I'm sincerely asking just to learn how others do it. Hope you don't mind the slightly off topic questions.
(In reply to comment #7) > From looking at the zip of features, there are three features in there. > Are you saying there would be some new, fourth feature that includes these > three features? Or just that this set of three is the minimal runtime set of > feature, and someone just knows to get all three. These features are "handy collections" of equinox function that (hopefully) are convenient to consumers. That is, someone is building a system that they want to manage with p2, they can just go and get the p2.core feature (assuming no UI etc) rather than having to figure out list of 27 bundles they actually need. Which ones they use depends on their usecase. If they are just doing OSGi then get the equinox.core feature. If they are doing p2 where they need to publish, manage other profiles, ... get the p2.extras feature. > I see the p2.extras feature "requires" the other two. What's the reasoning for > that? If its purpose is to magically pull in the others (during an install) > then seems a little counter intuitive (that someone would request the extras > feature, in order to get core minimal functionality). That would be solved if > there was a fourth "container" feature, that made sure the three when together. Using p2 you will get "required" bits of the bundles in extras even without the feature requires statements. That is, getting extras will get you *most* of the core stuff. The problem is that bundle dependencies are not completely expressed. For example, none of the p2 bundles express a classloading dependency on the DS implementation but all need DS to be there and running. This is similar to the Help system needing a web server but not depending on any particular web server. By having the extras feature depend on the core features we are sure to get the "core" functional blocks. There are downsides to this of course but we have to remember that the features are not cast in stone. That is, you are free to make your own features and slice/dice the world to suit your needs. Side note, likely the dependency from p2.extras to p2.core should be an includes as these are likely quite tightly coupled and are unlikely to work well if mixed and matched. > Also, how do you propose to handle the runtime vs. sdk sets of features. For > each of these will there be a corresponding SDK feature, or in your view of the > world are those completely separate constructions. I myself always like the > close, parallel definitions, since easier to understand ... but, I'm sincerely > asking just to learn how others do it. IMHO SDKs and these features serve a very different purpose. The Equinox project may produce several overlapping runtime features such as the ones listed here. Having fine-grained SDKs for each usecase just raises the complexity bar for the developers. They have to understand all the runtime scenarios just to "get Equinox". Rather in the RT Target Components movement we have said, "here is the SDK for Equinox/Riena/... It has lots of great stuff. Use what you want out of it to create your solution". Developers can just get the SDK and discover as they go what features/bundles there are and incorporate them into their work. In short, the SDKs should be very simple and easy to consume whereas the runtime features *may* be quite subtle and overlapping. > Hope you don't mind the slightly off topic questions. Not at all. Thanks for asking.
The new features are now in the build as is an OSGi starter kit product that puts them together into a simple runnable app.
