Bugzilla – Full Text Bug Listing
| Summary: | tycho-versions-plugin changes plugin version if same as parent pom version | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Andrew Overholt <overholt> |
| Component: | Tycho | Assignee: | Project Inbox <tycho-inbox> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, digulla, gregory.amerson, gunnar, igor, jjohnstn, t-oberlies |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 418013 | ||
| Bug Blocks: | |||
|
Description
Andrew Overholt
I think current behaviour is the least confusing for majority of users and I vaguely remember this was discussed on tycho-users some time last year. (In reply to comment #1) > I think current behaviour is the least confusing for majority of users and I > vaguely remember this was discussed on tycho-users some time last year. So you think that inherited and matching but defined in parent and child versions should act in the same way? But this is giving unwanted results when I want to change the parent version only without touching the child ( I may not even know that the versions were matching exactly). Although personally I tend to like "your" proposed behaviour better, I believe most users will expect parent and module version change if both versions happen to be the same. I could be wrong, so bring this up on tycho-users and if the consensus is that parent/pom versions should be treated separately, then I'll be happy to apply a quality patch ;-). (In reply to comment #3) > Although personally I tend to like "your" proposed behaviour better, I believe > most users will expect parent and module version change if both versions happen > to be the same. I could be wrong, so bring this up on tycho-users and if the > consensus is that parent/pom versions should be treated separately, then I'll > be happy to apply a quality patch ;-). I'll be on vacation next week but I'll bring it to the mailing list as soon as I get back. (In reply to comment #3) > Although personally I tend to like "your" proposed behaviour better, I believe > most users will expect parent and module version change if both versions happen > to be the same. I could be wrong, so bring this up on tycho-users and if the > consensus is that parent/pom versions should be treated separately, then I'll > be happy to apply a quality patch ;-). We just ran into this problem again. The features/plug-ins versions are independent of the overall project version. When we use the tycho-versions-plugin, any feature or version with the same version as the top-level release get changed as well and SNAPSHOT and .qualifier are removed. This results in required manual editing and in our case, respins. Can I propose that you simply add an option to exclude eclipse-feature and eclipse-plugin packaging types from the change (e.g. -DexcludeFeaturesPlugins) thereby leaving the default behaviour intact but making this usable in such a scenario as ours? Wouldn't it be better if you could tell the plugin which artifacts to update? There is an "artifacts" parameter mentioned in the documentation but it's not documented :-( http://www.eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/set-version-mojo.html (In reply to comment #6) > Wouldn't it be better if you could tell the plugin which artifacts to update? > > There is an "artifacts" parameter mentioned in the documentation but it's > not documented :-( > http://www.eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/ > set-version-mojo.html According to the documentation that is there, it is selecting ${project.artifactid) by default which is our top-level id: linuxtools-parent and we do want the version for that changed. It appears to then be changing all artifactids below that which match the version value. Some of these we do want to change: parents for particular components (e.g. linuxtools-changelog-parent for the changelog features/plug-ins, linuxtools-valgrind-parent for the valgrind features/plug-ins, each of which have linuxtoos-parent as their parent). We just don't want the features/plug-ins underneath those changed. If we were to actually specify the top-level artifactId (linuxtools-parent) as one of our choices, would it act any differently or would it still be recursive and cause the same issues? I would prefer a specific list of artifact coordinates (group + artifact ids). Projects could create small script files to update everything. Alternatively, the plugin could print a list of plugins which it wants to change to the console and ask "is this OK?" with an option to remove some entries. (In reply to comment #8) > I would prefer a specific list of artifact coordinates (group + artifact > ids). Projects could create small script files to update everything. > That would be fine by us. > Alternatively, the plugin could print a list of plugins which it wants to > change to the console and ask "is this OK?" with an option to remove some > entries. As long as there could be a single "for all" response so it could be done as part of our Hudson jobs. I thought that the described behaviour is the intended behaviour. But the intended behaviour really needs to be clarified (see bug 418013). Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only. |