Thursday, June 28, 2012
Eclipse p2 Frustrations
Eclipse p2 continually frustrates me. For years I have been working around it and we have been peacefully coexisting. I recently tried to dip my toes back in the water to see if I could better understand it and use it better. I have what seems to me a simple situation that would be common in the Eclipse world but I cannot find a satisfactory solution.
I have an Eclipse feature comprised of many plugins. These are intended to be installed in an Eclipse-based IDE and the assumption is that it should be possible to install it via the update manager UI of Eclipse or the Marketplace client. My feature extends a lot of other Eclipse plugins that need to be installed. For example, it needs Subclipse, Mylyn, GEF and several other plugins. Some of these are hosted on eclipse.org and some are on other sites. I want someone to be able to install my feature and have any other features that are needed discovered and installed automatically and seamlessly.
The peaceful coexistence I have talked about is that I have been able to make this work by hosting all of the dependencies on the same update site as my feature. This is labor intensive and kind of annoying but it worked so that is what I did. I would much prefer to just publish a site that contains only my features and whatever pointers are needed for Eclipse to go get the rest of the plugins. I cannot figure out any way to do it and I have not seen any other sites that do this successfully so I just assume Eclipse cannot do this.
Am I wrong in thinking this should not only be possible, but easy?
I have tried adding associate sites to the site.xml. That did not do anything. I tried adding a p2.inf file to my feature JAR's. I could see that the UpdateSitePublisher added the instructions to the content.xml file, but it appears to add them in a place that would only be applied after my feature is installed. So it does not help for my scenario of needing to add these sites to find required dependencies. I am at a loss and about to go back to my ugly workaround.
Subscribe to:
Post Comments (Atom)
12 comments:
Sounds like you need a composite repository: http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_composite_repositories.htm&cp=2_0_20_3_1
Thanks for the pointer as I did read that doc but forgot to try it. That said, it does not seem to work for me. Maybe I did it wrong? The files are here:
http://downloads.open.collab.net/eclipse/dev-builds/e3.7/compositeContent.xml
All of the files are XML so you can view them easily with browser.
Think I might have figured it out. The composite repository needs to live on its own. So the composite points to my repos (in another location) and all the others. I then just give users the URL of my composite.
This might work.
The part that I don't understand and I haven't seen adequately explained is how composites intersect with repository categories... For the scenario like yours, you likely want your product features categorized (visible), but not your dependencies. The dependencies should be available for install as needed by your features, but people shouldn't be installing them directly from your repository.
Maybe you could try to use the b3 aggregator. That provides a nice model to create a composite repository, and then also creates it. Additionally, it also allows mirroring if required. See the b3 Aggregator Eclipse wiki page for details.
I have mixed feelings on that. First let me state that it apparently show all the categories and features from all the sites. I sort of like that because in my case the things that I have dependencies on have their own optional features that people will want. For example, I require Subclipse, but the user can still decide to install JavaHL or SVNKit. On the other hand, it is overwhelming because sites like Mylyn and GEF include a lot of things that I would rather hide, such as all of the SDK plugins. I can probably live with it.
I'd like to add that this "problem" isn't an exclusive in the p2 world.
This also happens with Debian apt repositories. And even more, with apt repositories you need to add the repository signatures before you can install packages without warnings.
An installed Debian package can add more repositories (having root privileges), but it needs to get installed first.
I kind of think that this is by design, so that the user is ultimately "in control" of what repositories they use. Otherwise, people's Eclipse would be cluttered with a lot of dependency repositories. I'm not yet sure if it will be better or worse than the current situation.
b3 aggregator looks interesting. I disregarded it in the past because thought you had to be using Maven/Tycho to use it. It looks like I could publish my site and then use b3 to create a custom aggregated site of all the plugins I want? Other than the maintenance burden that sounds like a better way to do what I do today.
P2 is a pain in the *ss: Consider this example: I want to deploy an eclipse product with Juno. I created the target platform using p2.mirror and mirrored every feature I needed. Then I start a PDE-Headless build against the target platform and even a mirror of the Juno repository (update site). Then p2 tells me that org.apache.lucene.core.2.9.0 cannot be found. And voilá there is not org.apache.lucene.core.2.9.0 in the target platform but only 2.9.1. But the target platform is containig all plugins that were required during mirroring, I presume. It's an aporia :)
I am very frustrated with that.
Hi Mark,
I'm not sure, but reading your post seems you have been facing a similar problem I had recently.
You said: "I would much prefer to just publish a site that contains only my features and whatever pointers are needed for Eclipse to go get the rest of the plugins. ".
Well more or less this is actually the same problem I had when trying to publish/test the update site of the project I'm currently working on.
I'm not a p2 expert and what I found out is given by a lot of google digging and article/forum posts reading.
Perhaps it's for sure not the best solution, it worked out.
Back in the days (Ganymede) it seems there were the use of the associateSitesURL attribute in the site.xml file.
After reading various posts like this, http://divby0.blogspot.it/2011/02/simplifying-p2-process-part-3-associate.html , I tried to modify directly the content.xml file inside the content.jar generated after building my update site.
In our project for example we put these lines as last child of the repository tag.
<references size="4">
<repository uri="http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/" url="http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/" type="0" options="1"/>
<repository uri="http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/" url="http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/" type="1" options="1"/>
<repository uri="http://updates.yakindu.com/indigo/milestones/" url="http://updates.yakindu.com/indigo/milestones/" type="0" options="1"/>
<repository uri="http://updates.yakindu.com/indigo/milestones/" url="http://updates.yakindu.com/indigo/milestones/" type="1" options="1"/>
</references>
You can find the working content.jar example here: http://jasperstudio.sourceforge.net/updates/content.jar
This way the "extra" update sites can be "suggested and found" and your installation works fine.
Again, it's not the best approach for sure and maybe we can call it a dirty trick but it works :-)
Hopes it can help you!
Regards,
Massimo.
Using composite sites worked for me, for instance, this is the MAIN composite site of one of my projects
http://heanet.dl.sourceforge.net/project/xsemantics/updates/composite/releases/compositeArtifacts.xml
http://switch.dl.sourceforge.net/project/xsemantics/updates/composite/releases/compositeContent.xml
The first location is the url of Xtext composite update site and the second one is the url of the composite site of my project (composite sites can be composite recursively).
Then, the release composite site of my project (not the MAIN one shown above) can be easily automatically created and maintained as shown here: http://www.eclipse.org/forums/index.php/mv/msg/358650/882836/#msg_882836
Hi Lorenzo,
I got your use of the composite update site.
But if you enter the following URL (correct me if it is wrong):
http://heanet.dl.sourceforge.net/project/xsemantics/updates/composite/releases/
you are presented with the list of all the Xtext stuff besides Xsemantics.
A more clean view, would be in my opinion to see only the XSemantics feature.
Then it's selection would install all required accessory features.
That's what I would like to achieve... and what I was able to do with the modification of the content.xml (inside the jar). But again I would like to do it in a more clean way.
Do you know if this is possible using composite sites? Any information would be nice.
Thanks!
Massimo.
Post a Comment