Community
Participate
Working Groups
In order to create update-able features outside of the original product, you must install root level features into an eclipse product. http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html It would be nice if we could do this with tycho. So we would perform a product build as usual using the eclipse-repository package type, but be able to specifiy additional root level features that we would want to install into the product as a part of the build.
I think it makes sense to implement this as part of the eclipse-repository cleanup bug 348586. Installable units could be defined something like this in the eclipse-product: <includes> <include> <iu id="productIU-id" version="productIU-version"/> <iu id="featureIU-id" version="featureIU-version"/> </include> </includes>
Hi, This would be very useful to have this, in order to be able to update features independently of the product itself ( when re-using eclipse features for example )
Hi, I am also very interested in this option. I need to compile a specific IDE for my team. I am using the p2-director plugin to create such IDE. In my case it is necessary to have updateable plugins/features installed on top. I already customized the p2-director locally for my needs which I would like to share with you as an proposal. I added two new configuration options: additionalRepositores and additionalIUs which are used in the DirectorMojo to extend the arguments artifactrepository, metadatarepository and installIU - so that when calling the P2 Director within the mojo the product will be compiled and the additional IUs will be installed on top. This extension allows me to configure updatable products in the following way in the configuration of the P2 director plugin: <configuration> <additionalIUs> <additionalIU>org.eclipse.egit.feature.group</additionalIU> ... </additionalIUs> <additionalRepositories> <additionalRepository>http://download.eclipse.org/egit/updates-1.3/</additionalRepository> </additionalRepositories> </configuration> Please find attached my patched version of the DirectorMojo (original taken from Tycho 0.14) which can deal with this configuration. What do you think? It would be great if this could become part of the P2 director plugin.
Created attachment 211228 [details] Customized DirectorMojo for updateable plugins
I'm a bit puzzled by this request as I've been following Andrew's approach using Tycho for well over a year now. The key is that your p2.inf file has to be named XXX.p2.inf and put in the same directory as the XXX.product file. My .product doesn't actually specify any features or plugins: they're all pulled from the .p2.inf file.
(In reply to comment #5) > I'm a bit puzzled by this request as I've been following Andrew's approach > using Tycho for well over a year now. The key is that your p2.inf file has to > be named XXX.p2.inf and put in the same directory as the XXX.product file. My > .product doesn't actually specify any features or plugins: they're all pulled > from the .p2.inf file. So do you have an example of what what p2.inf commands you need to add to install root level features? I would like to give this approach a try.
Can you simply add things like this below into the XXX.p2.inf to have it install those into the resulting product? requires.1.namespace = org.eclipse.equinox.p2.iu requires.1.name = org.eclipse.cvs.feature.group requires.1.range = [1.1.100, 1.2.0) requires.2.namespace = org.eclipse.equinox.p2.iu requires.2.name = org.eclipse.mylyn_feature.feature.group requires.2.range = [3.2.0, 3.3.0)
I just tried Andrew's suggestion using p2.inf and it does indeed perform the additional install of the features, however, they are not listed as the top level but instead nested under my XXX product. So it appears we do need a change to tycho. What is the status of the patch? What would be required for us to get this patch into 0.15.0 ?
Wrt p2.inf: I think the director calls are purely cosmetic — I'm able to update the features independently of the product (within the version ranges, of course). But for root-level installs, some Tycho support will b necessary.
I'm not a Tycho dev, but for Peter's contribution to be taken it needs to be in the form of a patch with tests. See <http://wiki.eclipse.org/Tycho/Contributor_Guide>.
I have implemented this patch on top of some other changes we have been using, the commits are listed here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351487#c36
Hi, using tycho 0.19.0, i have still the issue described here. is the patch is really functionnal ?
(In reply to comment #12) > using tycho 0.19.0, i have still the issue described here. is the patch is > really functionnal ? Did you fetch the sources, apply the patch, build Tycho, and then tried to install root level features? "patch" only means that there is a patch attached to this bug report.
OK, i've misunderstood c11, that's why this is still open.
I've updated the DirectorMojo from Peter Muessig[1] to the current 0.20 source base. If there is a chance that this patch will be accepted, I could also write tests for the additional feature and create a gerrit review for this patch. [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=361722#c3
@Hendrik, can you upload a Gerrit review for the patch?
(In reply to Hendrik Still from comment #15) > If there is a chance that this patch will be accepted, I could also write > tests for the additional feature and create a gerrit review for this patch. yes this is on our plan for 0.20.0 (see target milestone). Patches welcome. I did not have the time look into the details of Peter's patch but I think we would only need a way to specify additional IUs (probably also optionally with a version as the p2 director supports this AFAIK). The additional p2 repositories should not be added here, they should go into the normal build target platform instead so this is off topic here and the usecase should already covered today as far as I can see. As for the tests, I could imagine an integration test that covers the scenario "update feature independently of product" another thing to consider is that you can have multiple products published in one eclipse-repository module, so the configuration of additional IUs should be product-specific I think.
I create a gerrit review, but without the test. https://git.eclipse.org/r/#/c/19957/ With this patch it is possible to install root level features by adding a additionalIU. <execution> <id>materialize-products</id> <configuration> <additionalIUs> <additionalIU>org.eclipse.egit.feature.group</additionalIU> </additionalIUs> </configuration> <goals> <goal>materialize-products</goal> </goals> </execution> The as you said the versioning is already supported by the p2 director. "-installIU: a comma separated list of IUs to install. Each entry in the list is in the form <id> [ '/' <version> ]. If you are looking to install a feature, the identifier of the feature has to be suffixed with ".feature.group"." So it should be possible to use it the following way. <additionalIU>org.eclipse.egit.feature.group/<3.2.0.201311130903-m3></additionalIU>
The problem with all patches that I have seen so far is that they don't work if the additional, root level feature is not part of the resolved dependencies of the eclipse-repository module, i.e. the additional feature is not required via the product or a category.xml. However, this case should also work. There are two basic approaches to solve this problem: 1. Make the DirectorMojo install using the target platform as input, rather than the resolved project dependencies. Making this possible in general is something that I've been working for for years (bug 364134, bug 393004, bug 412416, ...), but it currently isn't. And given that we want to have this fixed for 0.20.0, I'd rather not wait for this. 2. Treat the root level features as project dependencies. Technically, we could have the dependency resolution read the director configuration from the POM and consider it for dependency resolution. However I don't think that reading different configuration parameters from multiple mojos scales. Instead, the extraRequirements configuration could be re-used for root-level features. In the most simple solution, every configured extraRequirement could be treated as root level IU for product installations. However introducing this could be a surprising behaviour change for many users. So instead, we could extend the extraRequirements syntax by a "scope" attribute, and only install extraRequirements as root level IUs if they have the scope "assembly".
(In reply to Tobias Oberlies from comment #19) > So instead, we could extend the extraRequirements syntax by a "scope" > attribute, and only install extraRequirements as root level IUs if they have > the scope "assembly". If I get it right this would add the additonal IUs to all products with no way to configure additional IUs per product.
(In reply to comment #20) > (In reply to Tobias Oberlies from comment #19) > > So instead, we could extend the extraRequirements syntax by a "scope" > > attribute, and only install extraRequirements as root level IUs if they have > > the scope "assembly". > > If I get it right this would add the additonal IUs to all products with no way > to configure additional IUs per product. Correct. However in the mid-term (i.e. with "eclipse-product") this problem goes away, when we anyway only allow one product per module. One module per product is an option today if you need different root level features. However, this requires p2.inf magic if you need to get the two product definitions into one p2 repository.
> So instead, we could extend the extraRequirements syntax by a "scope" > attribute, and only install extraRequirements as root level IUs if they have > the scope "assembly". So this would be the preferable way? Where do I find the extraRequirements parameter?
FYI: EPP starts using Tycho, I guess they need root level features too. See Bug 366430.
(In reply to Hendrik Still from comment #22) > > So instead, we could extend the extraRequirements syntax by a "scope" > > attribute, and only install extraRequirements as root level IUs if they have > > the scope "assembly". > > So this would be the preferable way? > Where do I find the extraRequirements parameter? here is an example of similar code in the surefire plugin that uses extraRequirements: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n714 as for the "scope" idea, I think that is something more general that we would have to provide, I think you can go with extraRequirements without scope for now.
How does the normal Eclipse SDK deal with this problem?
(In reply to Erik Englund from comment #25) > How does the normal Eclipse SDK deal with this problem? The current Eclipse SDK has the same problem and does not support rootlevel features. Only the EPP Packages like "Eclipse Standard" support this. (In reply to Jan Sievers from comment #24) > as for the "scope" idea, I think that is something more general that we > would have to provide, I think you can go with extraRequirements without > scope for now. I'm sorry, but currently I've no time to work on this topic. But I'd love to see tycho installing root level features :-) .
Is there any timeline for the inclusion of this, resp. the 0.20.0 release? Thanks!
(In reply to Marco Descher from comment #27) > Is there any timeline for the inclusion of this, resp. the 0.20.0 release? From experience of past years, we'll probably do the release before EclipseCon North America.
I'd like to be included in the list of people for which this feature would be a huge improvement over the current status. This would be very useful for my Clojure plugin Counterclockwise's standalone product https://github.com/laurentpetit/ccw
(In reply to comment #19) > In the most simple solution, every configured extraRequirement could be treated > as root level IU for product installations. On the tycho-users mailing list, someone (sorry, don't remember who) had the idea to just add a flag to install all features listed in the product file as root level features. This idea would have the advantage, that for the dependency resolution, we don't have to read any additional file or configuration. This is a big plus. However, a global flag isn't quite what you'd want because then there would be only root level features, and the product would no longer contain any features at all. So instead, we'd need a flag per included feature. This flag would determine whether the feature is installed at root level or included in the product. The main disadvantage of this approach is that we'd extend the product file format, although we (Tycho) don't own it. So this format extension should also be contributed to p2 and the PDE. We need to start the discussion with p2 and PDE, but we don't need to wait for them but could completely implement this approach in Tycho. I'll link the p2&PDE bug once I've opened them.
A global flag would work for us, we want all features as root level features. So if that is easy to implement, that would be a big win (for us).
(In reply to Lars Vogel from comment #31) > A global flag would work for us, we want all features as root level > features. So if that is easy to implement, that would be a big win (for us). +1 for global flag, too.
(In reply to Tobias Oberlies from comment #30) > > However, a global flag isn't quite what you'd want because then there would > be only root level features, and the product would no longer contain any > features at all. So instead, we'd need a flag per included feature. This > flag would determine whether the feature is installed at root level or > included in the product. I wouldn't want to see a global flag, that's *way* too course grained for my usecases and I wouldn't be able to use it. What about being able to read a flag or extra information from the product.p2.inf file? rootIU.0.name=org.eclipse.platform.feature.group rootIU.1.name=org.eclipse.egit.feature.group This assumes that p2 will either accept or allow/ignore those properties. PW
The EPP use-case is a bit different, and I doubt that a global flag would help us (unless it marks *all* features as root-level feature independent from their position in the dependency tree). I'd prefer a solution with a p2.inf file like the one Paul described in comment #33. All EPP packages have their own product configuration in its own module. This product configuration defines a dependency to a single EPP package feature. This EPP package feature defines the content of a package by requiring the features of the various Eclipse projects. This historical structure is hard to change (though not impossible). With all its inherent drawbacks it has the advantage that users of package X can install the EPP feature of package Y and get the content of both.
-1 for the global flag, too. I think it is way too general and would solve only some of our needs. Personally I would prefer to put this in the pom - like described in comments 1 and 3.
+1 for the p2 solution as in comment 33 - why learn how to configure it for tycho if you already learnt it for p2?
(In reply to Marco Descher from comment #36) > +1 for the p2 solution as in comment 33 - why learn how to configure it for > tycho if you already learnt it for p2? It we're giving instructions to tycho specifically, that would weigh on the side of putting it in the pom file for the product. That would be fine by me as well (I just like expressing IU things in p2.inf files :-), as long as it's opt-in and you have to specify the features you want to have special treatment. PW
(In reply to comment #33) > What about being able to read a flag or extra information from the > product.p2.inf file? The problem here is that Tycho up to now doesn't interpret the p2.inf format itself, and I'd like to keep it this way. It would be possible to encode the information via the p2.inf, but this would be a lot more than the one line per feature (see proposal in bug 427563). (In reply to comment #36) > +1 for the p2 solution as in comment 33 - why learn how to configure it for > tycho if you already learnt it for p2? What do you mean with "learned it for p2"? There is no way to make p2 install root level features (unless you called the director yourself). (In reply to comment #37) > It we're giving instructions to tycho specifically, that would weigh on the side > of putting it in the pom file for the product. That would be fine by me as well > (I just like expressing IU things in p2.inf files :-), as long as it's opt-in > and you have to specify the features you want to have special treatment. pom.xml is a good option, too, except that there won't be editor support (which we may get if we extend the product file) and the configuration has to be done in a somewhat obscure way (because of it's cross-cutting effect, see comment #19 option 2).
> (In reply to comment #36) > > +1 for the p2 solution as in comment 33 - why learn how to configure it for > > tycho if you already learnt it for p2? > What do you mean with "learned it for p2"? There is no way to make p2 > install root level features (unless you called the director yourself). Sorry, for that! We have a buckminster build here, where we call an ant-script which executes the respective director call. So yes, we do it ourselves :)
In a p2 bug, Tobias has started discussing a solution, however I would like to make sure we agree on the changes desired on the final product. And especially what kind of operations you are expecting your user to be able to perform. Today, the product allows to group a set of functionalities together and control those relatively tightly. This is nice for serviceability because I can just ask my customer to read me the version number of the product and I know everything that is installed. So what kind of features are you expecting your user to be able to perform: 1 - I want my user to be able to uninstall a features of my product 2 - I want my user to be able to upgrade a feature of my product 3 - I want my user to be able to upgrade a feature of my product but limited to a certain set of versions specified in the product
(In reply to Pascal Rapicault from comment #40) > So what kind of features are you expecting your user to be able to perform: > > 1 - I want my user to be able to uninstall a features of my product > 2 - I want my user to be able to upgrade a feature of my product > 3 - I want my user to be able to upgrade a feature of my product but limited > to a certain set of versions specified in the product For me 1.) + 2.)
(In reply to Pascal Rapicault from comment #40) > In a p2 bug, Tobias has started discussing a solution, however I would like > to make sure we agree on the changes desired on the final product. And > especially what kind of operations you are expecting your user to be able to > perform. > > Today, the product allows to group a set of functionalities together and > control those relatively tightly. This is nice for serviceability because I > can just ask my customer to read me the version number of the product and I > know everything that is installed. > > So what kind of features are you expecting your user to be able to perform: > > 1 - I want my user to be able to uninstall a features of my product > 2 - I want my user to be able to upgrade a feature of my product > 3 - I want my user to be able to upgrade a feature of my product but limited > to a certain set of versions specified in the product For us, 3. is the best. :D
(In reply to Pascal Rapicault from comment #40) > 1 - I want my user to be able to uninstall a features of my product > 2 - I want my user to be able to upgrade a feature of my product > 3 - I want my user to be able to upgrade a feature of my product but limited > to a certain set of versions specified in the product 2 or 3... with a small preference for 3.
(In reply to Markus Knauer from comment #43) > 2 or 3... with a small preference for 3. Just FYI - In my training session people frequently ask if they can uninstall a feature from a EPP package. For example they downloaded the RCP/RAP package and had issues with a certain plug-in and wanted to de-install the related feature instead of downloading a new SDK version and installing all the other plug-ins.
(In reply to Lars Vogel from comment #44) > Just FYI - In my training session people frequently ask if they can > uninstall a feature from a EPP package. Good to know that... my personal feeling is that some packages have grown too much. If there's a pattern please open bugs with these improvements!
For me, the main point is 2). The possibility of 1) is also interesting. Why ? I develop a plugin for Clojure. The target is Eclipse the IDE. For users not used to the Eclipse ecosystem, I provide a pre-packaged Eclipse IDE with a bunch of customizations: my plugin, third party plugins, modifications of defaults, special branding. But then, I'd like to let the users as free as possible to update / "tweak" their install.
(In reply to comment #40) > Today, the product allows to group a set of functionalities together and control > those relatively tightly. This is nice for serviceability because I can just ask > my customer to read me the version number of the product and I know everything > that is installed. This is the advantage of the tight coupling, but this bug is explicitly about breaking this coupling. > So what kind of features are you expecting your user to be able to perform: > > 1 - I want my user to be able to uninstall a features of my product > 2 - I want my user to be able to upgrade a feature of my product > 3 - I want my user to be able to upgrade a feature of my product but limited to > a certain set of versions specified in the product With the approach described in Andrews blog (linked in comment #0), one can already achieve option 2 and/or option 3 (AFAIK with the limitation that you'd only get updates as a side-effect of another installation/upgrade. AFAIK "Check for updates" does nothing if none of the root units has updates.) So this bug is explicitly about going one step further: the possibility to install features at root level (i.e. as siblings of the product). So the versions of the root level features are only known for the original distribution and can be freely changed thereafter (option 1 and option 2).
(In reply to Pascal Rapicault from comment #40) > So what kind of features are you expecting your user to be able to perform: > > 1 - I want my user to be able to uninstall a features of my product > 2 - I want my user to be able to upgrade a feature of my product > 3 - I want my user to be able to upgrade a feature of my product but limited > to a certain set of versions specified in the product I'd expect to do 2 and 3. I wouldn't want them to do 1 PW
Implementation update: I have a first quick implementation working. I'll put it into Gerrit next week. @All who don't want their users to uninstall features from your product (option 1), this enhancement may not be the right feature for you. Instead, you will have to continue using the p2.inf approach described in the blog linked in comment #0. I could imagine a way to make this more convenient (e.g. by adding a third installMode "reference"), but this is outside the scope of this bug. ("outside the scope..." = hint: if you want this, open a new "enhancement" bug)
Submitted: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=81857b98fda09c786a335c443d96776b32263ffa It is now possible to have a feature installed at root level in a product distribution by adding the attribute installMode="root" to the feature in the product file, e.g. <features> <feature id="org.eclipse.egit" installMode="root"/> </features> Note that the PDE is currently not aware of this attribute, so you'll have to insert it with a text editor and make sure the PDE editor doesn't remove it. An example product file can be seen here: [1] [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects/product.installation/eclipse-repository/main.product
Hi, i've tried today. the solution is working for us. We use the p2.inf with ranges to avoid uninstallation of features, and the features are correctly installed on root, so are updatable. Thanks !
(In reply to comment #51) > Thanks ! It's a pleasure to make 18 voters happy ;-) I've added an example in the (renovated) documentation here: https://wiki.eclipse.org/Tycho/eclipse-repository
Note that the new installMode="root" attribute, which is needed to make use of this feature, is currently not recognized by the PDE product editor. So check your diffs when using the PDE product editor, and re-add the attribute in case the PDE editor removes it. There is a request to have the PDE editor preserve the attribute: bug 429902. Vote for it if this is a problem for you - or even better: contribute a patch :-)
(In reply to Tobias Oberlies from comment #52) > (In reply to comment #51) > > Thanks ! > It's a pleasure to make 18 voters happy ;-) > > I've added an example in the (renovated) documentation here: > https://wiki.eclipse.org/Tycho/eclipse-repository Very nice Tobias, I just switched to Tycho 0.20 and this is a huge usability improvement for our adopter product. Appreciate your work on this!
