| Re: [cross-project-issues-dev] Tycho and FeatureID == BundleID |
|
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: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin Sent: Dienstag, 13. Dezember 2011 13:04 To: Cross project issues (cross-project-issues-dev@xxxxxxxxxxx) 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 cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev |