We've used different groupIds for GMF Tooling and we are pretty happy
with it.
So we have groupIds:
* org.eclipse.gmf.tooling for artifactId "parent" (root pom.xml)
* org.eclipse.gmf.tooling.plugins for all artifacts in folder "plugins"
* org.eclipse.gmf.tooling.tests for all artifacts in folder "tests"
* org.eclipse.gmf.tooling.features for all artifcts in folder "features"
and so on...
Then it is quite easy to map an artifact with a location in the
codebase, and everything is under the org/eclipse/gmf/tooling folder in
M2_REPO. It's easy to clean.
My 2c.
Regards,
On 13/12/2011 13:19, Sievers, Jan wrote:
there was discussion on tycho-dev
http://dev.eclipse.org/mhonarc/lists/tycho-dev/msg00369.html
we don't want to push established projects to break API.
At the same time tycho needs a mapping of OSGi/eclipse artifact ids to maven
artifact ids.
For now I think your only option is to use a different groupId.
Feel free to comment on the proposal above which would allow to use the same
groupId
for features and bundles with the same id and instead append ".feature.group"
to the maven artifactId of the feature (inspired by how p2 solved a similar
problem for the IU namespace)
Regards,
Jan
From: [email protected]
[mailto:[email protected]] On Behalf Of Oberhuber,
Martin
Sent: Dienstag, 13. Dezember 2011 13:04
To: Cross project issues ([email protected])
Subject: [cross-project-issues-dev] Tycho and FeatureID == BundleID
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
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Mickael Istria
R&D Engineer, Eclipse Plug-in RCP Developer
PetalsLink <http://www.petalslink.com> - Open Source SOA
My blog <http://mickaelistria.wordpress.com> - My Tweets
<https://twitter.com/#%21/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
