Bugzilla – Full Text Bug Listing
| Summary: | [CBI] use the correct group IDs for all artifacts | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> | ||||||||||||||||||||
| Component: | Releng | Assignee: | Thanh Ha <thanh.ha> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||
| Severity: | major | ||||||||||||||||||||||
| Priority: | P2 | CC: | curtis.windatt.public, daniel_megert, david_williams, gunnar, irbull, jarthana, john.arthorne, Michael_Rennie, Silenio_Quarti, Szymon.Brandys, thanh.ha, tjwatson | ||||||||||||||||||||
| Version: | 4.2.1 | ||||||||||||||||||||||
| Target Milestone: | 4.2.2+ | ||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| Bug Depends on: | 401379, 401381, 401383, 401787 | ||||||||||||||||||||||
| Bug Blocks: | 372792, 397852 | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Paul Webster
See also bug 394831 for other "name changes" to make at same time. Based on bug 288644 the groupId for our features should be the first 3 segments.feature PW Paul, Thanh, can I ask your help spelling this out?
It appears there's not easy "global replace" that could be done ... at least, not with a simple regex pattern ... but as I've looked, I've some up with some questions.
First, you say the convention is "the first 3 segments of the plugin" ... do you mean that literally, even if a bundle has 5 or 6 segments?
Say for example,
<artifactId>org.eclipse.jdt.ui.tests</artifactId>
its groupId would still be
<groupId>org.eclipse.jdt</groupId> instead of its current
<groupId>eclipse.jdt.ui</groupId>?
and not
<groupId>org.eclipse.jdt.ui</groupId>
Second question ... how does this effect the "parent" definition?
For example, currently,
org.eclipse.ltk.ui.refactoring
has
<parent>
<artifactId>eclipse.jdt.ui</artifactId>
<groupId>eclipse.jdt.ui</groupId>
<version>3.8.0-SNAPSHOT</version>
</parent>
<groupId>eclipse.jdt.ui</groupId>
<artifactId>org.eclipse.ltk.ui.refactoring</artifactId>
<version>3.7.0-SNAPSHOT</version>
<packaging>eclipse-plugin</packaging>
What should the parent section be?
[This looks like a ton of work for committers ... a) is it worth it? :) b) any tools to help straighten these out? ]
(In reply to comment #3) > Paul, Thanh, can I ask your help spelling this out? > > It appears there's not easy "global replace" that could be done ... at > least, not with a simple regex pattern ... but as I've looked, I've some up > with some questions. > > First, you say the convention is "the first 3 segments of the plugin" ... do > you mean that literally, even if a bundle has 5 or 6 segments? > > Say for example, > <artifactId>org.eclipse.jdt.ui.tests</artifactId> > its groupId would still be > <groupId>org.eclipse.jdt</groupId> instead of its current > <groupId>eclipse.jdt.ui</groupId>? > and not > <groupId>org.eclipse.jdt.ui</groupId> > Yes, we'd use org.eclipse.jdt Group ID for all JDT repos and the Artifact ID will still have the full segments. > Second question ... how does this effect the "parent" definition? > For example, currently, > > org.eclipse.ltk.ui.refactoring > > has > > <parent> > <artifactId>eclipse.jdt.ui</artifactId> > <groupId>eclipse.jdt.ui</groupId> > <version>3.8.0-SNAPSHOT</version> > </parent> > <groupId>eclipse.jdt.ui</groupId> > <artifactId>org.eclipse.ltk.ui.refactoring</artifactId> > <version>3.7.0-SNAPSHOT</version> > <packaging>eclipse-plugin</packaging> > > What should the parent section be? > The parent section just needs to match the artifactId and groupId from it's parent, if no relative path is specified then the parent is ../pom.xml relative to the bundle. (In reply to comment #3) > First, you say the convention is "the first 3 segments of the plugin" ... do > you mean that literally, even if a bundle has 5 or 6 segments? > > Say for example, > <artifactId>org.eclipse.jdt.ui.tests</artifactId> > its groupId would still be > <groupId>org.eclipse.jdt</groupId> instead of its current > <groupId>eclipse.jdt.ui</groupId>? > and not > <groupId>org.eclipse.jdt.ui</groupId> Correct. There was some discussion about aligning bundles with features or components, but in the end it was decided in the obvious benefit of the 3 segment pattern: for any given bundle, it's maven co-ordinates are easy to find. org.eclipse.ltk:org.eclipse.ltk.ui.refactoring or org.eclipse.jdt:org.eclipse.jdt.ui. > Second question ... how does this effect the "parent" definition? > For example, currently, > > org.eclipse.ltk.ui.refactoring > > has > > <parent> > <artifactId>eclipse.jdt.ui</artifactId> > <groupId>eclipse.jdt.ui</groupId> > <version>3.8.0-SNAPSHOT</version> > </parent> > <groupId>eclipse.jdt.ui</groupId> > <artifactId>org.eclipse.ltk.ui.refactoring</artifactId> > <version>3.7.0-SNAPSHOT</version> > <packaging>eclipse-plugin</packaging> > > What should the parent section be? The parent section would be either org.eclipse:eclipse-parent (or what we rename it to) or the repo parent if they set extra configuration that's valid for that repo. The parent isn't bound by this change. PW (In reply to comment #3) > [This looks like a ton of work for committers ... a) is it worth it? :) b) > any tools to help straighten these out? ] Couldn't we use SED here? As far as I know every submodule has the same groupIds today. For example submodule "eclipse.jdt" has "<groupId>eclipse.jdt</groupId>". So I suspect we could locate "<groupId>eclipse.jdt</groupId>" and replace it with "<groupId>org.eclipse.jdt</groupId>" (In reply to comment #6) > (In reply to comment #3) > > [This looks like a ton of work for committers ... a) is it worth it? :) b) > > any tools to help straighten these out? ] > > Couldn't we use SED here? > > As far as I know every submodule has the same groupIds today. For example > submodule "eclipse.jdt" has "<groupId>eclipse.jdt</groupId>". So I suspect > we could locate "<groupId>eclipse.jdt</groupId>" and replace it with > "<groupId>org.eclipse.jdt</groupId>" Not quite. For example, the ltk example above. Its currently set as <groupId>eclipse.jdt.ui</groupId> because its in the jdt.ui repo, but it should be <groupId>org.eclipse.ltk</groupId> According to the "three segment" rule. But looking though the repos I have loaded, committers can use "multiple select" and then do a "global replace" on what they have selected, and shouldn't be too bad. Looking at org.eclipse.platform.runtime repo, for example, there's 9 that are currently <groupId>org.eclipse.platform.runtime</groupId> that should be <groupId>org.eclipse.core</groupId> and 4 that should be <groupId>org.eclipse.e4</groupId> What about the top level pom in each repo. They currently have repo name. Would the advice be to use "the most common groupId" in there repo? I'm not sure anyone inherits groupId from their repo pom ... but .. seems like they could in theory? And, just to ask in advance ... no special conventions for unit tests? Created attachment 227364 [details]
XSL that can fix the groupId in a pom
One option. We run this on the eclipse-plugin poms and a modified version on the eclipse-feature poms and just provide patches to each component
PW
Created attachment 227368 [details]
XSL I used to fix eclipse-plugins
I ran this with a shell script that looked like:
find * -name pom.xml -print0 | xargs -0 grep eclipse-plugin | cut -f1 -d: >/tmp/t1_$$.txt
for POM in $( cat /tmp/t1_$$.txt ); do
$ECLIPSE -noSplash \
-application org.eclipse.ant.core.antRunner -v \
-buildfile "$ANT_SCRIPT" \
-Dfile.sheet="$FIX_SCRIPT" \
-Dfile.in="$(pwd)/$POM" \
-Dfile.out="$(pwd)/${POM}.out"
xmllint --format "${POM}.out" >"${POM}"
rm "${POM}.out"
done
and the ant script was:
<project name="Run stylesheet" default="all" basedir=".">
<property name="file.in" value="content.xml"/>
<property name="file.out" value="out_${file.in}"/>
<property name="file.sheet" value="sort.xsl"/>
<target name="all">
<xslt in="${file.in}" out="${file.out}" style="${file.sheet}"/>
</target>
</project>
Created attachment 227369 [details]
XSL I used to fix eclipse-features
Ran it with the same ant script and:
find * -name pom.xml -print0 | xargs -0 grep eclipse-feature | cut -f1 -d: >/tmp/t1_$$.txt
for POM in $( cat /tmp/t1_$$.txt ); do
$ECLIPSE -noSplash \
-application org.eclipse.ant.core.antRunner -v \
-buildfile "$ANT_SCRIPT" \
-Dfile.sheet="$FIX_SCRIPT" \
-Dfile.in="$(pwd)/$POM" \
-Dfile.out="$(pwd)/${POM}.out"
xmllint --format "${POM}.out" >"${POM}"
rm "${POM}.out"
done
Created attachment 227370 [details]
Fix for eclipse.platform.ui
Fix for Platform UI. The only downside to the XSL is that to make the pom file look reasonable, I had to format it with xmllint. That had no effect on most poms, but I saw at least one with formatting changes.
I'm willing to live with that for platform.ui and platform.runtime, though.
PW
Created attachment 227371 [details]
change for platform.runtime
I'll hold off on this until I confirm that the change runs in a build.
PW
Just a note, all of this work is in master for now. PW (In reply to comment #12) > Created attachment 227370 [details] > Fix for eclipse.platform.ui My build was a success, and it looks like the IDs took. I'll apply platform.runtime and look at platform.ua PW I stashed the scripts I used to generate my patches at http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/scripts/xsl PW Apparently on linux I should just use xsltproc :-) PW To re-ask some questions I didn't see an answer to ... nothing special for tests, right? Only features get "special suffix". And, nothing needed for repository's root pom? It can stay with its repository name (since it doesn't really produce an artifact for itself, and is not the sort of thing that's normally inherited). Right? As with bug 394831, we are going to have a coordinated change on Monday, 2/25. To cover all time zones, lets say you can start any time after Sunday night's build completes ... say, Midnight (Eastern time). This change, if not made on Monday, probably will not cause a "build failure", but, just as well get it out of way since making other changes to all poms. Again, this change should be made in all branches (master, R3_8_maintenance, and R4_2_maintenance, for those that have R4_2_maintenance). This requires a change in each pom.xml file in your repository: for code bundles and tests the change is the same. For features, it is a tiny bit different. The "root" (parent) pom should NOT be changed. In short, each pom gets its "maven name" from the <artifactId> element. Those are currently named after the repo its in, but should be named with the first three segments of the bundle's symbolic ID. <groupId>org.eclipse.platform.runtime</groupId> that should be following for bundles starting with "org.eclipse.core" <groupId>org.eclipse.core</groupId> You can use the attached XSL Paul created if you like that approach, or, a little "find and replace" should work, but don't chnage the "parent" section. In many repos, all the artifacts end up with the same name, but some have a few different "families" of artifact. For exammple, the "ltk" bundles are in the repo named "eclipse.jdt.ui", so many bundles in that repo go from <groupId>eclipse.jdt.ui</groupId> to <groupId>org.eclipse.jdt</groupId> but a few go to <groupId>org.eclipse.ltk</groupId> The only thing that's a little different is features. They follow the same rules, but have ".feature" appended to the first three segments, by convention. This change shouldn't effect the "parent" section of your pom, only the "main" groupId, for the artifact itself. Feel free to ask questions or point out problem cases, if any. (In reply to comment #18) > To re-ask some questions I didn't see an answer to ... nothing special for > tests, right? Only features get "special suffix". Right, there wasn't anything special for the tests, as they're unique within the eclipse-plugin namespace. We just needed the extra segment groupId for features as they're not unique compared with plugins. > > And, nothing needed for repository's root pom? It can stay with its > repository name (since it doesn't really produce an artifact for itself, and > is not the sort of thing that's normally inherited). I don't think so. As you say, they only produce build artifacts (the poms, that we use to include special repo-level configuration). The alternative is to move them all into the org.eclipse.releng (or something similar) groupId. John, do you have an opinion here? PW As far as I can tell, there's no groupId in eclipse.platform.releng.aggregator that needs to be changed, since none of them are "deployable" artifacts? Thanh, or Paul, please correct if I'm not seeing something correctly. Done for master at eclipse.platform.resources. I've applied the changes to 3.8.2+ and/or 4.2.2+ as appropriate for: eclipse.platform.ui eclipse.platform.ua eclipse.platform.runtime I've created the R3_8_maintenance branch for eclipse.platform.runtime from the R3_8_1 tag, as it didn't exist before. PW Platform Debug is done: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=ae624bb688fb02190519d3a877466560fffa06e7 (In reply to comment #24) > Platform Debug is done: > > http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/ > ?id=ae624bb688fb02190519d3a877466560fffa06e7 Platform Debug 3.8.2+: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?h=R3_8_maintenance&id=5b25225b54f6e8062fe9a0e88d08401f5494ae0e JDT Debug done: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e9558e3abf0110a93c379020c30e5801a26df7eb and in 3.8.2+ http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?h=R3_8_maintenance&id=a41fe707bf0ce6e7678235126e67bc4ebd79db56 Done: org.eclipse.pde org.eclipse.pde.ui org.eclipse.pde.build http://git.eclipse.org/c/pde/eclipse.pde.git/commit/?id=e315152b033c68eb8d6bb38a2df1c57952ecd557 http://git.eclipse.org/c/pde/eclipse.pde.git/commit/?h=R3_8_maintenance&id=8d755c683d3f5d379b0d692879cc6f8341666d8e http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=9153884c95562ad9d4df00251a59da708dce8782 http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=R3_8_maintenance&id=9efaf8638378f2e88faf511a299dbd8d61dc6bbc http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=78dee56b8d7e16145db780923112e7caed068fe2 http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?h=R3_8_maintenance&id=5ce6c4ee75c07fc801971d3e5983b6ed6c15b056 Fixed in 'master' for: eclipse.jdt eclipse.jdt.ui eclipse.platform.team eclipse.platform.text Released the fix for master and R3_8_maintenance for repos: eclipse.jdt.core eclipse.jdt.core.binaries Fixed in 'master', 'R3_8_maintenance' and 'R4_2_maintenance' for: eclipse.platform.swt eclipse.platform.swt.binaries Done: rt.equinox.framework rt.equinox.bundles http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=3214312409e3d6ff320d965b2bb052d1a0d05fc8 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R3_8_maintenance&id=7f8c354b7286f2efc68cec85e86ede9573b8f9d8 http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=55c89972efa8e854f519fc7d2385fac03e42c395 http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?h=R3_8_maintenance&id=fdccfb3bbe26d673e87afe38d774cc4cba2e8d8c Note that for the framework 'bundle' I had to use simply org.eclipse.osgi as the group ID. I assume that is following the convention even though the symbolic name is only 3 segments. (In reply to comment #31) > > Note that for the framework 'bundle' I had to use simply org.eclipse.osgi as > the group ID. I assume that is following the convention even though the > symbolic name is only 3 segments. Yes, that's what I expect. PW I've done this p2. All our bundles have the groupID org.eclipse.equinox, *except 2*. There are two bundles (ie.wombat.jbdiff and ie.wombat.jbdiff.test) that I used the first three segments of their ID (ie.wombat.jbdiff). Sorry, I don't know what these bundles are for. There are three commit for each steam (bundles, features and examples). master: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=4ee94b126bc8413325f920c0f8539f1acf371180 http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=64c8a3f65fbc381ea3b914c69563ed30517f0ccb http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=1ee5884473b6b84d3868cdc2adddfb011dff3836 R3_8_maintence: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?h=R3_8_maintenance&id=2a9c37fde85c8e0458f618f720763284cd5422af http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?h=R3_8_maintenance&id=eb9abdff505d6e20d687f637dccfc1b242ef452a http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?h=R3_8_maintenance&id=6738bcd0dfc4cdfa4f4979afa1a3131f440582a9 (In reply to comment #33) > I've done this p2. All our bundles have the groupID org.eclipse.equinox, > *except 2*. There are two bundles (ie.wombat.jbdiff and > ie.wombat.jbdiff.test) that I used the first three segments of their ID > (ie.wombat.jbdiff). Sorry, I don't know what these bundles are for. There > are three commit for each steam (bundles, features and examples). jbdiff is a library that could be used in p2 to perform more efficient transfer of updates (for example on mobile devices or under slow connection scenarios). This was never shipped and is only used in tests. I think we could actually just remove these bundles and tests (or at least stop building them, remove their pom files). Created attachment 227570 [details]
example jdt core patch to correct parent group id
Jayaprakash, or other JDT committers, the bundles in JDT core were changed "too much" ... I think the search and replace I gave didn't work well for your particular repo.
I've attached a "sample", but suspect each of your bundles in jdt.core repo need similar fix. Only the <groupId> of "main artifact" should change. ... not the parent groupId, it's ok the way it was.
(In reply to comment #35) > Created attachment 227570 [details] > example jdt core patch to correct parent group id > > Jayaprakash, or other JDT committers, the bundles in JDT core were changed > "too much" ... I think the search and replace I gave didn't work well for > your particular repo. > > I've attached a "sample", but suspect each of your bundles in jdt.core repo > need similar fix. Only the <groupId> of "main artifact" should change. ... > not the parent groupId, it's ok the way it was. I'm not sure this is the correct patch. Created attachment 227571 [details]
jdt.core.patch to fix parent
Attached patch resolves parent issue with jdt.core.
Created attachment 227572 [details]
jdt.core.bin.patch
Attached patch resolves issues with jdt.core.binaries repo.
Created attachment 227573 [details]
error log from "pom updater"
Thanks for the review/corrections Thanh.
I'd take your word on maven issues any day.
Here I've attached the log from our "update poms" script (ran before a build) where it ways it "can't read 15 projects". For for completeness, if it helps.
Thanks again.
(In reply to comment #37) > Created attachment 227571 [details] > jdt.core.patch to fix parent > > Attached patch resolves parent issue with jdt.core. Thanks for the patch, Thanh! I was confused that the patch had some changes that were already on the repo. I have excluded that part and released only the change for the root pom. (In reply to comment #37) > Created attachment 227571 [details] [diff] > jdt.core.patch to fix parent > > Attached patch resolves parent issue with jdt.core. AFAIK this is wrong. All other repositories have the root 'pom.xml' as follows: they use the first 3 segments of the artifactId, which is the repository name, e.g. <groupId>eclipse.platform.ui</groupId> <artifactId>eclipse.platform.ui</artifactId> or <groupId>eclipse.jdt.ui</groupId> <artifactId>eclipse.jdt.ui</artifactId> So, I don't see why JDT Core should be an exception here and asked Jay to revert the changes to the artifact's group ID (the change to the parent was correct). If this is not correct, then everyone needs to go and touch their poms again :-( Fixed API Tools description features in 'master' with http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=ef26c6a2ba1f29ecf7d75aba3548897202957e6a Fixed eclipse.platform.resources\bundles\org.eclipse.core.filesystem\fragments\org.eclipse.core.filesystem.solaris.sparcv9\pom.xml with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=9ddf3e09f506b48695e7cbc9d2931e33303cd094 (In reply to comment #41) > (In reply to comment #37) > > Created attachment 227571 [details] [diff] [diff] > > jdt.core.patch to fix parent > > > > Attached patch resolves parent issue with jdt.core. > > AFAIK this is wrong. All other repositories have the root 'pom.xml' as > follows: they use the first 3 segments of the artifactId, which is the > repository name, e.g. > OK, I think I got it. For some reason JDT Core uses a different parent naming pattern in its projects/bundles than all others. Common pattern for root (artifactId = repo name, groupId = first 3 segments) : <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-platform-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../eclipse-platform-parent</relativePath> </parent> <groupId>eclipse.platform.ui</groupId> <artifactId>eclipse.platform.ui</artifactId> And the children/projects then use those ids, e.g.: <parent> <artifactId>eclipse.platform.ui</artifactId> <groupId>eclipse.platform.ui</groupId> <version>3.8.0-SNAPSHOT</version> <relativePath>../../</relativePath> </parent> <groupId>org.eclipse.core</groupId> <artifactId>org.eclipse.core.commands</artifactId> But JDT Core uses this in root: <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-platform-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../eclipse-platform-parent</relativePath> </parent> <groupId>org.eclipse.jdt</groupId> <artifactId>eclipse.jdt.core</artifactId> <version>3.8.0-SNAPSHOT</version> <packaging>pom</packaging> and hence the children also look different: <parent> <artifactId>eclipse.jdt.core</artifactId> <groupId>org.eclipse.jdt</groupId> <version>3.8.0-SNAPSHOT</version> </parent> <groupId>org.eclipse.jdt</groupId> <artifactId>org.eclipse.jdt.compiler.apt</artifactId> I'd prefer to use the same pattern for JDT Core and hence update the root pom and all the child poms. The only other repo where I found this anomaly is 'eclipse.platform'. Fixed poms of several test projects with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=72ee48e5280550809fa9798070cb101bbd941590 (In reply to comment #38) > Created attachment 227572 [details] > jdt.core.bin.patch > > Attached patch resolves issues with jdt.core.binaries repo. (In reply to comment #40) > (In reply to comment #37) > > Created attachment 227571 [details] > > jdt.core.patch to fix parent > > > > Attached patch resolves parent issue with jdt.core. > > Thanks for the patch, Thanh! I was confused that the patch had some changes > that were already on the repo. I have excluded that part and released only > the change for the root pom. Can these 2 patches be pushed into R3_8_maintenance branch as well? (In reply to comment #47) > Can these 2 patches be pushed into R3_8_maintenance branch as well? Done. I'd like to see the eclipse.jdt.core and eclipse.platform repositories fixed, so that they follow the pattern of all other repositories. The suggested changes are: 1. Change the groupId of the in the root pom.xml to match the first 3 segments of its artifactId: <groupId>org.eclipse.jdt</groupId> ==> <groupId>eclipse.jdt.core</groupId> <groupId>org.eclipse.platform</groupId> ==> <groupId>eclipse.platform</groupId> 2. Change the parent groupId in all child/project pom.xml files as follows: <groupId>org.eclipse.jdt</groupId> ==> <groupId>eclipse.jdt.core</groupId> <groupId>org.eclipse.platform</groupId> ==> <groupId>eclipse.platform</groupId> If I don't here any reasonable objection to this, we will make that change tomorrow, and by then also backport those groupdId changes, including the groupId changes for "my" repos (see comment 28). (In reply to comment #49) > If I don't here any reasonable objection to this, we will make that change > tomorrow, and by then also backport those groupdId changes, including the > groupId changes for "my" repos (see comment 28). One thing I'd like to point out after having used Nexus awhile on the Eclipse instance at: https://repo.eclipse.org When pushing to Nexus the Group ID is used to determine the folder location of the artifact. For example lets say we're pushing the following: groupId: org.eclipse.jdt artifactId: org.eclipse.jdt.core /org/eclipse/jdt/org.eclipse.jdt.core So if you ever use eclipse.jdt.core instead then if you ever push to Nexus it would place it in a directory: /eclipse/jdt/core Looking at Sonatype's Nexus instance I can see some projects don't use the "org.eclipse.jdt" format and others do: https://repository.sonatype.org I'm not suggesting that any format is better but thought I'd comment in case this detail is helpful in your decision. (In reply to comment #50) > (In reply to comment #49) > > If I don't here any reasonable objection to this, we will make that change > > tomorrow, and by then also backport those groupdId changes, including the > > groupId changes for "my" repos (see comment 28). > > One thing I'd like to point out after having used Nexus awhile on the > Eclipse instance at: > > https://repo.eclipse.org > > When pushing to Nexus the Group ID is used to determine the folder location > of the artifact. > > For example lets say we're pushing the following: > > groupId: org.eclipse.jdt > artifactId: org.eclipse.jdt.core > > /org/eclipse/jdt/org.eclipse.jdt.core > > So if you ever use eclipse.jdt.core instead then if you ever push to Nexus > it would place it in a directory: > > /eclipse/jdt/core > > > Looking at Sonatype's Nexus instance I can see some projects don't use the > "org.eclipse.jdt" format and others do: > > https://repository.sonatype.org > > > I'm not suggesting that any format is better but thought I'd comment in case > this detail is helpful in your decision. Thanks! Since currently all other root groupIds already start with "eclipse" and not "org" it is good to change the two strange repos. Fixed eclipse.platform with http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=ee82576443b1a1008d1c444a2d721da26d263b14 Fixed in 'R3_8_maintenance' for: eclipse.jdt eclipse.jdt.ui eclipse.platform eclipse.platform.resources eclipse.platform.team eclipse.platform.text I noticed Jan commented on Bug 401450 Comment 5 regarding recommended groupIds and linked to: https://docs.sonatype.org/display/Repository/Choosing+your+Coordinates I think we are done for Kepler release. Thanh, how are we doing for 422+ and 382+? All done? If not, can you remind those committers that you are waiting on? (In reply to comment #54) > I think we are done for Kepler release. > > Thanh, how are we doing for 422+ and 382+? All done? If not, can you remind > those committers that you are waiting on? Yes this is done for 422+ and 382+. Setting to Resolved. |