| [p2-dev] 3rd party installers, droplets, etc |
|
(this is response to the threads on 3rd party installers
(http://dev.eclipse.org/mhonarc/lists/p2-dev/msg05226.html) and
droplets) Hi, Sorry for taking so long getting back to you. I have been away and did not feel like dealing with this issue as soon as I got back because this is likely to be long discussion :) First let's start by comments on the wiki page (http://wiki.eclipse.org/Equinox/p2/Plan/3rd_party_installers) - I think this page should be renamed to be "3 party installers on linux" as other systems generally have no issue invoking the p2 director. - It would be good to give a description of the problem you are running into with the current solution. You are mentioning the pb about "uniqueness" of libraries, but iirc there are other problems. Having all the problems listed will make sure that the solution we are creating will address them all, rather than discovering the problems piece meal and shoehorning a solution afterward. - Why should feature.xml contain ranges? what do you define as "external dependencies"? - I find the processing of droplets to be too complex. I think that a droplets needs to be a runnable repo plus something that identifies the feature(s) that must be installed. This way the work to be done by the droplet becomes easier. Wdyt? More generally, when we met at EclipseCon France, we blue-skied the concept of droplets as a potential solution and it is great to see that you are making progress. However, given the other requirements that I gather from some of your comments on the wiki page, I'm wondering if the droplet approach is the way to go. For example, we could also decide to go with an approach that generates a profile on the fly (or start from a stub profile) or structure the metadata differently to make it easier for you to patch, etc. Finally, a minor point, in the mail [1], you are saying "The rationale is quite trivial: in the devops times centralized deployment is something that completes common build infrastructure. One has to have the possibility to quickly build and deploy Eclipse and Eclipse components to developers. It's just too expensive to let them download each new version :-)." and this is misleading. Indeed, since its inception p2 has always supported a model where Eclipse can be completely updated from one build to another. This is not just a feature on paper. This is automatically tested but more importantly this is actively being used everyday by the development team which updates from one I-build to the next using p2, or by the EPP package maintainers when they verify that the SR0 package can be updated to SR1, and even to the next release. And, finally this is even works on Linux when Eclipse is installed by the user (downloading the eclipse archive). What you are describing is a situation specific to the way Eclipse is distributed on Linux by the package managers. Pascal [1] http://dev.eclipse.org/mhonarc/lists/p2-dev/msg05226.html |