[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tm-dev] Converting TM to tycho-same feature and plugin ids problem

Hi Anna,

I'm leaning towards keeping ID's as they are, and disambiguating by using a different Maven GroupID for the features [1],[2].

To be sure, I've just asked on the cross-project mailing list if that makes sense and what other projects do (attached).

Are you subscribed to the cross-project-issues-dev mailing list [3] already?

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=353384#c7
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=288644#c31
[3] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

-----Original Message-----
From: Anna Dushistova [mailto:anna.dushistova@xxxxxxxxx] 
Sent: Dienstag, 13. Dezember 2011 01:58
To: tm-dev
Cc: Oberhuber, Martin
Subject: Converting TM to tycho-same feature and plugin ids problem

Hi All,

I started working on the tycho build for TM and I found out that it doesn't allow same ids for different bundles:

[ERROR] Two or more projects in the reactor have the same identifier, please make sure that <groupId>:<artifactId>:<version> is unique for each project: {org.eclipse.tm:org.eclipse.rse.useractions:1.1.300-SNAPSHOT=[/Users/anna/tycho/TM-releng-workspace/features/org.eclipse.rse.useractions-feature/pom.xml,

Tycho doesn't seem to allow that and at the same time it requires ids to match the manifest ones:

Does anyone has an idea how we are going to deal with it?

--- Begin Message ---

Hi all,


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,


-          New / incubating projects typically rename their features e.g. by appending a “.feature” postfix, e.g. “org.eclipse.rse.feature”

-          But this is a breaking change for consumers including features, so some projects rename the branding plugin instead (e.g. appending a “.core” postfix)

-          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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=353384#c7


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 [1] 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:

-          org.eclipse.dstore

-          org.eclipse.rse

-          org.eclipse.rse.features

-          org.eclipse.tm

-          org.eclipse.tm.features


Does that sound acceptable, or should we rather fold the .dstore groupID into the .rse namespace ?


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=288644





Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6


--- End Message ---