Community
Participate
Working Groups
Created attachment 276830 [details] Screenshot AFAIK it is good practice to not add the version number for features in the product as the build qualifier will regulary change. But if I use the "Add..." button in the product editor, the version number is added. I suggest to add new feature entries without version number in the editor.
Julian, something for you?
New Gerrit change created: https://git.eclipse.org/r/134875
Thanks, Julian.
Gerrit change https://git.eclipse.org/r/134875 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=6750f578dac6566e30c5e3339cb7e99450614d66
Hey guys I agree with the fact that we should have an easy way of clearing the version number but I think this implementation is a little bit too hasty. There are many cases where you want to have a specific version number. Also if you leave the version to .qualifier then the build will fill in the specific version number. For example, this avoids the problem that Tycho unintentionally pulls in old plugins from the local .m2 directory. This is just one case where I see this failing but it does not look like you considered all the corner cases of the product build. Please consider a version toggle instead like we have fixed the root toggle [1]. Also, the properties dialog should have a convenient way of restoring the version number.
(In reply to Wim Jongman from comment #5) > There are many cases where you want to have a specific version number. Also > if you leave the version to .qualifier then the build will fill in the > specific version number. For features a version range is supported. I think the whole scenario you are describing is validate for features which we have not change. For products it is a simple text match which is very limited so I typically recommend to not use feature versions in products.
(In reply to Wim Jongman from comment #5) > Also, the properties dialog should have a convenient way of restoring the > version number. How about adding content assist to the properties dialog? It could suggest available versions with current qualifier and ".qualifier".
(In reply to Julian Honnen from comment #7) > (In reply to Wim Jongman from comment #5) > > Also, the properties dialog should have a convenient way of restoring the > > version number. > > How about adding content assist to the properties dialog? It could suggest > available versions with current qualifier and ".qualifier". AFAIK .qualifier is not supported for product configuration. Is that not true?
(In reply to Lars Vogel from comment #8) > AFAIK .qualifier is not supported for product configuration. Is that not > true? Seems like it is widely used: https://github.com/search?q=.qualifier+extension%3Aproduct&type=Code&ref=advsearch&l=&l=
I was looking in the EPP packages. I was convinced they heavily used version but they don't. However, they do use .qualifier for their own features. https://github.com/eclipse/epp.packages/tree/master/packages
(In reply to Wim Jongman from comment #10) > I was looking in the EPP packages. I was convinced they heavily used version > but they don't. > > However, they do use .qualifier for their own features. > > https://github.com/eclipse/epp.packages/tree/master/packages For own features it will work as both .qualifiers are replaced during the build.
(In reply to Julian Honnen from comment #7) > (In reply to Wim Jongman from comment #5) > > Also, the properties dialog should have a convenient way of restoring the > > version number. > > How about adding content assist to the properties dialog? It could suggest > available versions with current qualifier and ".qualifier". +1. I agree with the version number blanking [1] but it would be nice if we have some means of restoring the version number in case needed. No one wants to type a version number. Maybe a button next to the list "Set version number" that would just pick the latest known version number? Just brainstorming. I'm happy with any solution. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=543060
*** Bug 543060 has been marked as a duplicate of this bug. ***
Can bug reporter or bug assignee please verify this defect for 4.11M3?
