Bugzilla – Full Text Bug Listing
| Summary: | Improve galileo capability process | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | davidms, richard.gronback, thomas, tjwatson, vroldanbet |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
David Williams
What's the timeline for this change? M7? RC1? I know it's relatively minor, but we already went through an approval process for this particular release train requirement and now we're changing it really late in the process... This leaves every project with an extra feature that's worse than useless on its own. When I run with just the capabilities plug-in I created for EMF (and not with the galileo plugin), I see no EMF UI, and no capabilities that I could use to enable it in Preferences > General > Capabilities (though the Enable All button does do the trick). Obviously that's not something I would want any of my users to install. Will every project have to take some steps to hide this feature from their unsuspecting users? I really don't think this is a good time to throw yet another burden on every project in Galileo. It's apparent than many are already strained to fill the existing requirements: http://www.eclipse.org/projects/galileo_status.php Yes, M7 was the goal, but understandable if some needed more time. Brian and Dave, you raise some good points, but I think the current scheme and process is broken. Nothing's versioned, so far, and from what I can see, the jars are not conditioned or signed. So some fix, somewhere, is needed. If someone is willing to take ownership of fixing the problem for all projects, so that each project doesn't have to do the work, then they can propose that. Perhaps a "compromise" is for someone to volunteer to do the "capabilities build" as whole separate thing, then they'd do that for everyone this release, and then contribute that to the Galileo build? Any volunteers? Any other ideas? Brian, I don't see this as a change in the requirement ... just a change in the process for getting there. If anyone has any other proposals to fix the issues, then that's fine. Please help. (In reply to comment #2) > Will every project have to take some steps to hide this feature from their > unsuspecting users? > No, those features will never be mirrored to the Galileo site. Their content will end up in one single org.eclipse.galileo feature. (In reply to comment #4) > No, those features will never be mirrored to the Galileo site. Their content > will end up in one single org.eclipse.galileo feature. But the Galileo site is fed from the individual project sites. I believe that, as things are set up right now, I can't feed something into Galileo without having it on my project's site. And I definitely wouldn't want non-Galileo users of my project to see this capabilities feature. I think I can see Dave's point. While I'm sure it could be "hidden" (just uncategorized) I can see how it could be a change for some teams. I do not really understand why it's so bad if some user happened to install it (by which I mean, I'm pretty ignorant of "capabilities") but that's a problem for the future. As I think about how to do this ... wouldn't it be insanely easy just to set up a separate CBI type build to just build just this "galileo capabilities feature". It would not even (really) require a download site or anything. There's no reason it can not be done a head of time, and then just becomes part of the input to the rest of the build process? Now ... who could set up a new CBI build? :) If someone could do that, it might have least impact to current process and teams, and at the same time, not have to rely on the Bucky Builder to actually "build" anything. (In reply to comment #6) > Now ... who could set up a new CBI build? :) > I can set that up. But as I mentioned earlier, it will make the build significantly slower. It will also require that anyone who wants to run the builder must install SVN from external repositories since some of the source referenced in the map files resides in SVN repositories. And with that, I think the hope of having projects run the builder for themselves for verification purposes is gone. All in all, I think it's a clunky solution to a very simple problem that needs to be resolved sooner or later anyway. (In reply to comment #7) > (In reply to comment #6) > > Now ... who could set up a new CBI build? :) > > > I can set that up. But as I mentioned earlier, it will make the build > significantly slower. It will also require that anyone who wants to run the > builder must install SVN from external repositories since some of the source > referenced in the map files resides in SVN repositories. And with that, I think > the hope of having projects run the builder for themselves for verification > purposes is gone. > Well, but I meant _completely_ separate. Almost as if it were in a different project, rather then in o.e.g.build ... not that I think it needs to be physically separate now, but conceptually. So someone wanting to verify their own .build file would not really need to "build" the capability feature. It'd just be another entry in a .build file. In that case, when would it be built and by who? How can a project verify that capabilities are correctly contributed? (In reply to comment #9) > In that case, when would it be built and by who? How can a project verify that > capabilities are correctly contributed? > I'm not sure about the who, but suspect this could be set up in a builder like Hudson, and either triggered automatically (when map file changes) or those making changes would be responsible for "manually" triggering it. Then, if we can't figure out how to automate it (easily) someone would have to update the feature version in the .build file periodically so it'd be picked up in the "next" bucky build. Is this the kind of answer you were looking for? Or am I missing your question? It sounds like something that can be done although it will increase the burden significantly for the build manager (he becomes a project contributor of his own, with all that that implies). Is this really what people want? For our project, I'm much more in favor of managing *one* external Galileo file then three of them. What approach would we take going forward (post Galileo)? Will this remain in effect until Galileo is out of the door sometime next spring? If the answer is yes, and we decide to do it differently in the next release train, wouldn't everyone be better off if we made the switch now so that there's one known way of doing this instead of two? I added some functionality to the builder so that it will now support both schemes and it's also capable of merging the capabilities regardless of what scheme that is used. Scheme 1. Like today and with Davids suggested CBI build. The build must result in a repository that contains the org.eclipse.galileo feature and all capability bundles. This repository must be appointed by the Galileo contribution. Scheme 2. Add a capabilities feature (or just a bundle) to your contribution. It must of course be present in the contributed repository. I'm still experimenting with this but I should be able to publish it before the days end. An interesting observation is that if you are capable of publishing a bundle to your update site without including it in a feature, then there is no need for a special capabilities feature. The concern that it would show up as an installable thing is then no longer an issue since bundles don't show up in the UM. I just discovered that a CBI build of the org.eclipse.galileo feature is needed regardless of other solutions since it also includes the "branding plug-in" where all capability categories (not to be confused with site categories) are defined. There's no way around that if these categories are to be managed in a central place. So I'd like to add an optional step to the build that: 1. Sets up a workspace with the org.eclipse.galileo feature and all referenced bundles (using the map). 2. Compiles the relevant projects and creates an update site. 3. Includes the compiled feature and bundles in the mirror. The step must be optional and will not be possible to execute unless the builder is equipped with PDE, CVS, and SVN. Buckminster is well equipped for this. We also have a complete headless SVN feature published at Cloudsmith (since Eclipse EMO has issues with LGPL) which will make installing a simple task for anyone who'd like to try it out. The central builder att Eclipse.org must of course always have this step enabled. I think this approach would leave all doors open and still enable for anyone who'd like to try a full build, including everything concerning capabilities, on his own computer. Once in place, I'd lite to lobby for moving things out to the projects. First, there's no need to define categoryActivityBinding entries centrally. Only the category definitions should live there IMO. Second, there's no need to manage the capabilities bundles in a central feature. Each project should contribute their bundles in their respective repositories. But that can all be done later (post Galileo). Does that sound agreeable to everyone? (In reply to comment #13) > > Does that sound agreeable to everyone? > It does to me. I'm not sure about the post-Galileo stuff ... that'll obviously take some more thought and discussion (and education on my part) but your plan for an optional step to do a build of the feature in the Buckminster Builder sounds good. I'd encourage you to conceptualize it as a three-way choice, "always build feature", "never build", "build if changed". The last one we might not really have to implement right away, but my view of how this often happens is that there will be some days (when many project contributing) we might need 10 builds a day before people get their update sites and .build files correct and stable ... so just seems potentially wasteful to rebuild the capabilities feature, if we know the map files haven't changed. Just a suggestion to leave open to that possibility, no need to actually implement the "only if changed" option right now. Thanks I have the build in place now and will release something today but I have some concerns about the current shape of the org.eclipse.galileo feature. It includes a whole lot of bundles that I don't see the need for. Here's the complete list: Bundles that should be there: org.eclipse.galileo org.eclipse.gmf.ui.capabilities org.eclipse.datatools.capabilities org.eclipse.actf.ui.capabilities org.eclipse.tptp.ui.capabilities org.eclipse.rse.ui.capabilities org.eclipse.uml2.uml.capabilities org.eclipse.mylyn.ide.capabilities org.eclipse.emf.activities Other included bundles: org.eclipse.ecf org.eclipse.ecf.identity org.eclipse.ecf.filetransfer org.eclipse.equinox.concurrent org.eclipse.ecf.provider.filetransfer.httpclient org.eclipse.ecf.provider.filetransfer org.apache.commons.httpclient org.eclipse.ecf.ssl org.eclipse.ecf.provider.filetransfer.ssl org.apache.commons.codec org.eclipse.ecf.provider.filetransfer.httpclient.ssl Why is this? The feature also requires the bundle org.apache.commons.logging which leads to build problems since its not normally include in any target. The only relevant requirement IMO, would be to org.eclipse.ui bundle since it defines the org.eclipse.ui.activities extension point. It's however not included nor required. I would like to update this feature, remove the unnecessary includes and requirements and add the one that's relevant. That's unless I'm completely missing the point here and the feature has some other purpose that I'm unaware of. I agree. Looking at this history of the file, looks like Rich added those ... and I bet he was just playing around :) ... or, perhaps, to get the "galileo product" to act like a product ... which we don't really need. Rich, please let us know the history/theory/need for these extra bundles. But, I'd remove them, and add them back if they were required for some (other) reason. (In reply to comment #16) > Rich, please let us know the history/theory/need for these extra bundles. I guess I don't understand the question. As stated above, each capabilities bundle is added to this feature so that the build would include them through the normal fetch/build/assemble process. The additional ones are likely the result of using update dependencies in the feature manifest editor. If they're being provided as jars elsewhere and included using the build model, then you can certainly clean up the list. But, they were certainly there for a reason. (In reply to comment #17) > But, they were certainly there for a reason. > The "update dependencies" would explain the 'requirements', but not the 'plugins'. What was the reason to include the following? org.eclipse.ecf org.eclipse.ecf.identity org.eclipse.ecf.filetransfer org.eclipse.equinox.concurrent org.eclipse.ecf.provider.filetransfer.httpclient org.eclipse.ecf.provider.filetransfer org.apache.commons.httpclient org.eclipse.ecf.ssl org.eclipse.ecf.provider.filetransfer.ssl org.apache.commons.codec org.eclipse.ecf.provider.filetransfer.httpclient.ssl I'm running the build without them and it seems to be fine. But I want to be absolutely sure that I don't miss anything. The ECF bundles could be an old workaround for when there was no matching ECF repo for the selected platform version. If it's working without them, I'd say you're OK to remove them. (In reply to comment #19) > The ECF bundles could be an old workaround for when there was no matching ECF > repo for the selected platform version. If it's working without them, I'd say > you're OK to remove them. > These ECF bundles are used by p2 in the Eclipse SDK, they should be included in the Eclipse SDK repo or galileo build input I think. (In reply to comment #13) > Does that sound agreeable to everyone? As one of the grousers on this bug, I must say yes and thank you! > Once in place, I'd lite to lobby for moving things out to the projects. First, > there's no need to define categoryActivityBinding entries centrally. Only the > category definitions should live there IMO. Second, there's no need to manage > the capabilities bundles in a central feature. Each project should contribute > their bundles in their respective repositories. But that can all be done later > (post Galileo). I think the idea was to make the activities and activity-pattern bindings reusable in different products (Galileo consumers, presumably) that might want to define different categories. Whether that's particularly useful or not is debatable, I suppose, and I agree we can do that post-Galileo. So just to confirm... We're leaving things as they were done earlier with the caveat that there's now a special process that Thomas is going through to generate what's required for the Galileo build and we will then farm out these various feature plug-in projects to the projects in a post-Galileo timeframe (and provide specifics as to the shape of those changes when the time is right)? Yes, Brian. Things are as they were. For better or worse. I think this is essentially fixed as much as we're going to, to my knowledge, in the latest build in http://download.eclipse.org/releases/staging/ Take a look, open new bugs for issues. . |