Bugzilla – Full Text Bug Listing
| Summary: | [Releng] Provide target platform for Sphinx | ||
|---|---|---|---|
| Product: | [Automotive] Sphinx | Reporter: | Stephan Eberle <stephaneberle9> |
| Component: | Core | Assignee: | Stephan Eberle <stephaneberle9> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christian.k.2510, jftilman, quoclan |
| Version: | 0.7.0 | ||
| Target Milestone: | 0.7.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Stephan Eberle
Providing the target platform as an update site is perhaps not the best idea. It would require the management of a kind of mirror of the official download places for each classic Eclipse component. I would prefer a mechanism to rebuild the target platform on the user side, based on the targetdefs file, by downloading each component directly from its official download site. (In reply to comment #1) > ... I would prefer a mechanism to rebuild the target platform on the user side, > based on the targetdefs file, by downloading each component directly from its > official download site. Rebuild target platform on the user side - yes Download directly from official download/update site - yes Based on Sphinx *.target files that reference these update sites instead of local folders - no The problem with the 3rd point is, that users would be forced to download a separate copy of the target platform for each workspace. Even worse: all of these copies must then be individually kept up to date when the target platform changes. Given that many people will have to develop Sphinx on multiple branches in parallel, this approach seems a bit heavy load and is likely to create lots of confusion. We therefore would prefer a solution, were users can download the target platform to one location on their hard disk and then point at it from multiple workspaces using an environment variable based *.target file (just as we have them now). The only thing that would change compared to Artop is that we wouldn't check the target platform out from SVN but install it via a to be defined update site mechanism. For the moment, people who are not members of Artop can not get the correct target platform to run Sphinx. They have to recreate it from scratch. In the wiki I have written a page to explain the procedure to setup the environment and get Sphinx from SVN (http://wiki.eclipse.org/Sphinx/environment). I propose a temporary procedure to handle the target platform. The first step consists in using another target definition which only refers to accessible update sites. The second step consists in recreating a local target platform from the target platform in cache. The alternative target definition I provide is not exactly the same. Some versions of the components are slightly different because I have not found everything on update sites. However, it seems to work. I think that Sphinx SVN could contain such a target definition based on update sites. It would be a reference for a possible alternative solution like the current local target platform definition. (In reply to comment #3) > For the moment, people who are not members of Artop can not get the correct > target platform to run Sphinx. They have to recreate it from scratch. That's correct, and I agree that this is a problem. I've personally already been contacted by two non-Artop Sphinx users regarding this issue. > In the wiki I have written a page to explain the procedure to setup the > environment and get Sphinx from SVN > (http://wiki.eclipse.org/Sphinx/environment). > > I propose a temporary procedure to handle the target platform. The first step > consists in using another target definition which only refers to accessible > update sites. The second step consists in recreating a local target platform > from the target platform in cache. Thank you for coming up with this idea and implementation. I have reviewed it and came to the conclusion that there is a little problem. It actually works well if the user proceeds exactly as you have described, opens only one update site based target definition file, and copies the resulting bundle pool from the workspace's metadata to a dedicated location on your hard disk. However, if there are multiple update site based target definitions, e.g., for Eclipse 3.5 and Eclipse 3.6, and for some reason the user opens all of them and then copy the bundle pool, you will end up with all plug-ins and features referenced by any of those target definitions in the dedicated hard disk location (even if none of the target definitions is ever activated by clicking on the "Set as Target Platform" link in the target editor, the bundle pool is already populated while the target definitions get resolved!) The second target definition which you propose simply points at the dedicated hard disk location as a whole but doesn't provide any information which of the available plug-ins and features should be used. So the content of the copied target platform depends on the interactions that the user performs on the target definitions before copying the bundle pool and the use of the second target definition that pulls the content of the copied target platform may have the consequence that the code gets compiled against multiple Eclipse versions in parallel. > The alternative target definition I provide is not exactly the same. Some > versions of the components are slightly different because I have not found > everything on update sites. However, it seems to work. I have reviewed the update site based target definition for Eclipse 3.6 which you have provided and corrected some of the entries, removed some unnecessary entries and added missing entries. I've also added an update site based target definition for Eclipse 3.5. The little extra challenge is that we currently use patched versions of two plug-ins from Graphiti and Xpand (bugs have been reported to the corresponding Eclipse projects and we hope to be able to replace the patches by newer versions of the original plug-ins later on). To cope with this I have provided copies of the patched plug-ins right inside the org.eclipse.sphinx.targetdefs project and an Ant script with a launch configuration that can be used to copy the patched plug-ins over the original ones inside the bundle pool. With both, i.e., one of the update site based target definitions and the Ant script, it is now perfectly possible for everybody to retrieve a fully operational Sphinx target platform for any of the supported Eclipse releases. > I think that Sphinx SVN could contain such a target definition based on update > sites. It would be a reference for a possible alternative solution like the > current local target platform definition. To be honest, your proposal has inspired me, and I've changed my mind wrt what I said in comment #2. I'm now thinking we should stop making rocket science by attempting to provide a super complicated and semi-proprietary local target platform system. Let's concentrate on our main objective, i.e., to enable non-Artop users to work with Sphinx, and therefore simply use the mechanism that Eclipse provides, i.e., update site based target definitions. Sure, it will cost some extra time in each workspace when switching to another target definition for the first (but only the first) time because all referenced and required plug-ins and features need to be downloaded to the bundle pool. But this extra waiting time is IMO tolerable given that update site based target definitions are an instantly working solution to our main problem and provide the following extra benefits: * Only directly required Eclipse components and Orbit plug-ins need to be referenced by the target definition; all indirectly required Eclipse components are pulled in automatically (e.g., it is sufficient to reference only the Graphiti update site instead of Graphiti and GEF update site - required GEF plug-ins will be resolved automatically) - this is very helpful and elegant * Update site based target definitions and the fact that referenced and required plug-ins and features are cached at workspace level provide an elegant way of enabling different branches of Sphinx to be based on differently composed target platforms; if we pointed from all workspaces to the same target platform provided at one dedicated location on the hard disk, then we would end up with all branches of Sphinx being forced to use exactly the same target platform - this gives us more flexibility and reduces maintenance effort for elder branches of Sphinx in case of target platform updates on newer branches of Sphinx Summary: I've committed update site based target definitions for Eclipse 3.5 and Eclipse 3.6 and the Ant script for applying the patched plug-ins to org.eclipse.sphinx.targetdefs. If everybody agrees then I'd say that we try to live with that, update the Sphinx Wiki accordingly (i.e., basically remove the target platform optimization step) and resolve this bug. Currently the patched plug-ins in the target platform are not considered during the automated Buckminster builds. A possibility to make the patched plug-ins available to the automated builds would be to provide the patched plug-ins via a publicly accessible update site together with a patch feature. This update site could then be referenced in the sphinx.rmap file. The patch feature would be referenced in the SDK feature and the corresponding .cspex file. Fixed by providing *.target files for Eclipse 3.7 and Eclipse 4.2 pointing at relevant Eclipse.org p2 update sites. No patched plug-ins/features are any longer required. Additionally, *.target files for Sphinx adopters including Sphinx itself have been provided. Mass-closing Resolved tickets |