Community
Participate
Working Groups
There is no real use case for having the artifactId different from the ID specified in the artifact (i.e. feature/bundle). The fact that this is currently possible just leads to confusion and adds unnecessary complexity. Therefore Tycho should enforce that feature/bundle ID is equal to the artifactId. This change also fixes a couple of issues in Tycho where the assumption that artifactId=bundle/feature ID was already implicit in the code.
This proposal has been originally been discussed in bug 347775.
Things that don't work if artifactId != bundle/feature ID: - feature root advices (bug 347775) - source bundle generation - version update with the versions plugin
Created attachment 201792 [details] introducing validate step to enforce artifactID == bundle/feature id
Created attachment 201793 [details] fix tycho-its projects that violate the rule that is enforced now To fix the ids, I simply took the ids from the manifest or feature.xml and put it into the pom.xml. There may be a more sophisticated way to fix this, especially in the case where we now have org.codehaus instead of org.eclipse again in the GAV.
The patches were both good - I don't think that anyone really cares about the IDs in test data. ID enforcement is active with 54b9b4a.
(In reply to comment #0) > There is no real use case for having the artifactId different from the ID > specified in the artifact (i.e. feature/bundle). The fact that this is > currently possible just leads to confusion and adds unnecessary complexity. It looks like there was a bad assumption here. There is a real use case for this, and it is quite common: having bundles and features with the same name. This Tycho change seems to be breaking lots of people, for example: http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00223.html http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg01321.html I'm not familiar with the Tycho concepts of "group id" and "artifact id", but is there any way to support this common use case in Tycho with this new restriction? Could the feature and bundle be separate artifacts to avoid this?
(In reply to comment #6) > It looks like there was a bad assumption here. There is a real use case for > this, and it is quite common: having bundles and features with the same name. We are aware of this use case, and it is still supported: - Leave the feature and bundle IDs as they are - In the pom.xml corresponding to the feature/bundle, make sure that artifactId is the same as in the ID in the feature.xml/MANIFEST.MF - Make sure that you still have unique (groupId, artifactId) tuples for each feature/bundle, e.g. by using one groupId for all bundles and another groupId (e.g. with a ".features" suffix) for all features. The groupId value is typically inherited from the parent POM, so the most elegant solution is to introduce a new parent POM for all your features - but just adding a <groupId>org.eclipse.myproject.features</groupId> to all POMs of features will also do.
(In reply to comment #6) > http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00223.html See http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00230.html
Thanks Tobias. I had heard from a few different places that people thought they had to rename their features to accommodate this Tycho change, so your description of how to handle this without feature renames is very helpful.
(In reply to comment #7) > (In reply to comment #6) > > It looks like there was a bad assumption here. There is a real use case for > > this, and it is quite common: having bundles and features with the same name. > > We are aware of this use case, and it is still supported: > - Leave the feature and bundle IDs as they are > - In the pom.xml corresponding to the feature/bundle, make sure that artifactId > is the same as in the ID in the feature.xml/MANIFEST.MF > - Make sure that you still have unique (groupId, artifactId) tuples for each > feature/bundle, e.g. by using one groupId for all bundles and another groupId > (e.g. with a ".features" suffix) for all features. The groupId value is > typically inherited from the parent POM, so the most elegant solution is to > introduce a new parent POM for all your features - but just adding a > <groupId>org.eclipse.myproject.features</groupId> to all POMs of features will > also do. Alternative approach would be to use the original groupId but change artifactId to <featureId>.feature.group. This is the naming convention used by p2 to disambiguate feature and bundle IDs, so I think it is reasonable to use the same convention in Tycho too.
