Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 353384

Summary: Enforce artifactId = bundle/feature ID
Product: z_Archived Reporter: Tobias Oberlies <t-oberlies>
Component: TychoAssignee: Tobias Oberlies <t-oberlies>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P2 CC: igor, john.arthorne, mn, sbouchet, steffen.pingel
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 347775    
Attachments:
Description Flags
introducing validate step to enforce artifactID == bundle/feature id
t-oberlies: iplog+
fix tycho-its projects that violate the rule that is enforced now t-oberlies: iplog+

Description Tobias Oberlies CLA 2011-07-29 04:43:00 EDT
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.
Comment 1 Tobias Oberlies CLA 2011-07-29 04:44:11 EDT
This proposal has been originally been discussed in bug 347775.
Comment 2 Tobias Oberlies CLA 2011-07-29 04:56:26 EDT
Things that don't work if artifactId != bundle/feature ID:
- feature root advices (bug 347775)
- source bundle generation
- version update with the versions plugin
Comment 3 Matthias Gradl CLA 2011-08-19 09:10:04 EDT
Created attachment 201792 [details]
introducing validate step to enforce artifactID == bundle/feature id
Comment 4 Matthias Gradl CLA 2011-08-19 09:15:26 EDT
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.
Comment 5 Tobias Oberlies CLA 2011-08-22 10:12:25 EDT
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.
Comment 6 John Arthorne CLA 2011-09-27 13:18:37 EDT
(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?
Comment 7 Tobias Oberlies CLA 2011-10-05 08:52:52 EDT
(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.
Comment 9 John Arthorne CLA 2011-10-05 12:53:36 EDT
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.
Comment 10 Igor Fedorenko CLA 2011-11-19 21:45:41 EST
(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.