Bugzilla – Full Text Bug Listing
| Summary: | [Naming Conventions] enforce different id for plugins and feature | ||
|---|---|---|---|
| Product: | Community | Reporter: | Bouchet Stéphane <sbouchet> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, d_a_carver, gunnar, john.arthorne, marcel.bruch, matthias.sohn, mistria, nyssen, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Bouchet Stéphane
The convention is to use org.eclipse.<projectshortname>.*, e.g. org.eclipse.tycho.core. This is similar to the guidelines for package naming. We should update the Naming Conventions wiki page to reflect this. I am reassigning to the Architecture Council for their comments. By the way, an efficient solution for this problem is to use different groupId for features and plugins. http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00230.html So you are requesting that plugin and feature ids be different to workaround a bug in Tycho? This doesn't seem well motivated. For a very simple project or plugin I think it is fairly reasonable to have feature, bundle, and package names all the same. Also if a feature wants to provide branding information, the standard way to do this is provide a plugin with the same as the feature: http://help.eclipse.org/indigo/topic/org.eclipse.pde.doc.user/guide/tools/editors/feature_editor/overview.htm Adding something about feature names to the naming conventions makes sense though, along the lines suggested by Wayne in comment #1. (In reply to comment #2) > By the way, an efficient solution for this problem is to use different groupId > for features and plugins. > http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00230.html but this implies an incompatible change for all upstream maven builds (In reply to comment #4) > (In reply to comment #2) > > By the way, an efficient solution for this problem is to use different groupId > > for features and plugins. > > http://dev.eclipse.org/mhonarc/lists/tycho-user/msg00230.html > > but this implies an incompatible change for all upstream maven builds Indeed, but that's IMHO a minor issue compared to the one of changing plugin or artifactId. With Tycho, upstream builds usually read MANIFEST.MF and perform dependency resolution with p2, which totally does not care about the groupId. The issue you describe is probably true only for pom-first Tycho builds and pure Maven (non-Tycho) builds. I think it applies to a very few projects at Eclipse. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. I think comment 3 and comment 5 are "the answer" ... which can be summarized as "won't fix". It is working as designed, and desired, so no plans to change. (And, that's not to say everyone has to do it that way, but is a convenient "short cut" ... that has been in place for ?10 years? and it is supported by Tycho.) Also, to focus on comment 0, there is no need that the "workspace project" (either in the workspace, or in Git) *has* to have the same name as the feature id or plugin id. If they do, then they can not both be loaded in the workspace at the same time (with the same name). Hence, it's often convenient to name a feature in the workspace with something like "org.eclipse.platform-feature" even those it's feature Id is only "org.eclipse.platform", since there is a bundle also named "org.eclipse.platform". The naming "in Git" doesn't matter quite as much, if in different paths (as they often are, with features in "features" and bundles in "bundles" but then the .project file should have "org.eclipse.platform-feature" since with the right preference set, that will be the name of the workspace project when imported or checked out from Git. (So, often easier to have "workspace name" and "Git name" the same, both different than the literal "id"). Another place this "shows up" is working with Orbit bundles. There different versions, with same id, are stored in different branches of CVS. So, there, I often use "check out as" to assign a different workspace name, to the same bundle, say, com.ibm.icu can be checked out under different names, from different branches, to be able to compare, for example. Say checkout one as com.ibm.icu-50.1.1 and another as com.ibm.icu-50.1.2. In any case, in the end, only the literal bundle id (not workspace id) is used "in the build". Hope that clarifies the issues for others, though, I hope the original reason for opening this has long been settled? Thanks, |