As our TM/RSE project is starting migration to Tycho, we’re running into the Tycho limitation that some of our features include a branding plugin with the same name; and featureID == bundleID needs to be treated specially for Maven/Tycho.
From what I’ve seen so far,
<![endif]>New / incubating projects typically rename their features e.g. by appending a “.feature” postfix, e.g. “org.eclipse.rse.feature”
<![endif]>But this is a breaking change for consumers including features, so some projects
rename the branding plugin instead (e.g. appending a “.core” postfix)
<![endif]>But this is a breaking change for consumers which depend on the bundle, so some (particularly older) projects
use a special Maven groupID for the features as per
I’m leaning towards the 3rd option (special Maven GroupID for features) since I don’t want to break existing adopters. I’ve seen comments saying that two groupID’s in one project is confusing when cleaning a repo, but on the
other hand I understand that the groupID translates into a directory hierarchy in Maven. So appending a “.features” to the groupID ends up as a subdirectory which seems OK to me.
Any comments on the approach ?
What have others done ?
Regarding the groupID itself, there was
discussion  between “org.eclipse” flat for all, or “org.eclipse.(3rdBundleSegment)”, or “org.eclipse.(projectID)” … we have never officially resolved the original question, but it seems to me that the de-facto trend goes towards the 2nd option
with very few exceptions. So it looks like in TM/RSE we’re going to get 5 groupIDs in total:
Does that sound acceptable, or should we rather fold the .dstore groupID into the .rse namespace ?
Martin Oberhuber, SMTS / Product Architect – Development Tools,
direct +43.662.457915.85 fax +43.662.457915.6