Community
Participate
Working Groups
Created attachment 232992 [details] log where NPE is thrown during "pom updater" I dont' see any obvious reasons why this build would fail, but will attach log.
Created attachment 232993 [details] diff -r of localMavenRepo which worked (the 'bak' one) and one that didn't work Just for completeness I'm attaching a "diff" in the "local maven repo" that is created as we start of our build ... usually containing "pre-reqs" to do the build with. We've learned to get "reliablying accruate" builds, we should "clean" that repo before any substantial build, but instead of just deleting it, I move it to "localMavenRepo.bak" so if things seem unusual, we can do a diff to see what's changed.
Jan, thanks for your tip as to reason why build might have failed (missing group IDs?) ... and the possibility of using 0.19.0-SNAPSHOT to work around it. But, we have had several successful builds with 0.18.0 with things as they are. So 1) I'm wondering what else might have changed? and 2) I'd like to find the pom's without a proper groupId rather then simply move to 0.19.0-SNAPSHOT to work around them missing. Any "tips" you can give to find those? (Other than some brute force search?) Does this refer to missing groupId on our artifacts/parents? Or in specifying our pre-reqs?
For the record, on mailing list, Jan said this looked related to bug 409912 fixed in tycho 0.19.0-SNAPSHOT.
Not sure if this is causing the issue, but it looks like this commit did not update the pom.xml version for the artifact: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=920d2b2d15b09018408a7f604f62095f679a91fa
(In reply to comment #2) > Jan, thanks for your tip as to reason why build might have failed (missing > group IDs?) ... and the possibility of using 0.19.0-SNAPSHOT to work around > it. > > But, we have had several successful builds with 0.18.0 with things as they > are. So 1) I'm wondering what else might have changed? and 2) I'd like to > find the pom's without a proper groupId rather then simply move to > 0.19.0-SNAPSHOT to work around them missing. > > Any "tips" you can give to find those? (Other than some brute force search?) > > Does this refer to missing groupId on our artifacts/parents? Or in > specifying our pre-reqs? (In reply to comment #2) > Jan, thanks for your tip as to reason why build might have failed (missing > group IDs?) ... and the possibility of using 0.19.0-SNAPSHOT to work around > it. > > But, we have had several successful builds with 0.18.0 with things as they > are. So 1) I'm wondering what else might have changed? and 2) I'd like to > find the pom's without a proper groupId rather then simply move to > 0.19.0-SNAPSHOT to work around them missing. > > Any "tips" you can give to find those? (Other than some brute force search?) > > Does this refer to missing groupId on our artifacts/parents? Or in > specifying our pre-reqs? see the sample project attached to bug 409912 something like this will cause the NPE <build> <plugins> <plugin> <!-- missing groupId element here --> <artifactId>maven-assembly-plugin</artifactId> <version>2.3</version> </plugin> </plugins> </build> to find the poms, off the top of my head I'd use find and grep. AFAIK the plugins with implicit groupId org.apache.maven.plugins all have artifactId maven-*-plugin. The search find . -name pom.xml -exec grep -HE -B1 "<artifactId>maven-.*-plugin" {} \; should give you a list of candidates. If you find one that has no <groupId> preceding line, that could be the one. Note that artifactId and groupId have no strictly defined XML element order in pom.xml though so you may hit false positives with the grep above. Another way would be to list all commits since the last time the build succeeded. Something like this in your aggregator git repo git submodule foreach git log -u --since=2013/06/25
(In reply to comment #4) > Not sure if this is causing the issue, but it looks like this commit did not > update the pom.xml version for the artifact: > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=920d2b2d15b09018408a7f604f62095f679a91fa probably unrelated as far as I can see
another simple workaround option is to go back to tycho 0.17.0 (or forward to 0.19.0-SNAPSHOT) just for the update-poms call. in your script where you call the update-pom goal, you can make the tycho version to be used explicit (implicit means latest released i.e. 0.18.0). See docs [1] Sth. like this mvn org.eclipse.tycho:tycho-versions-plugin:0.17.0:update-pom [1] http://eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/update-pom-mojo.html
Created attachment 232998 [details] Ouput using your "find/grep" command according to running your find/grep command, we may be missing LOTS of group IDs, especially for "antrun-plugin", but some others. (As you say, some of these may be false positives, but I did check a few, and many appear "valid"). I did a "diff" from last I-build, and could not see where any "group-ids" were removed. (So, still wondering what in "infrastructure" changed?) We did do some mass updates for "parent pom" version, so ... wondering if might be related to that and not "group id" per se? I've been running LOTS of test builds (both "4.3 maintenance" and a few "4.4 I-builds") on my local test machine and no problems until today. I'm trying local M-build now to confirm it still runs. (local I-build does fail, in same way, as on eclipse.org ... this morning). Before changing to try 0.19.0-SNAPSHOT may try things like "recloning" all repos, just to make sure, not some oddities going on.
(In reply to comment #8) > Created attachment 232998 [details] > Ouput using your "find/grep" command > > according to running your find/grep command, we may be missing LOTS of group > IDs, especially for "antrun-plugin", but some others. (As you say, some of > these may be false positives, but I did check a few, and many appear > "valid"). > > I did a "diff" from last I-build, and could not see where any "group-ids" > were removed. (So, still wondering what in "infrastructure" changed?) > > We did do some mass updates for "parent pom" version, so ... wondering if > might be related to that and not "group id" per se? > > I've been running LOTS of test builds (both "4.3 maintenance" and a few "4.4 > I-builds") on my local test machine and no problems until today. > > I'm trying local M-build now to confirm it still runs. (local I-build does > fail, in same way, as on eclipse.org ... this morning). > > Before changing to try 0.19.0-SNAPSHOT may try things like "recloning" all > repos, just to make sure, not some oddities going on. going back to 0.17.0 only for the update-pom goal is your easiest option I think
(In reply to comment #9) > (In reply to comment #8) > > going back to 0.17.0 only for the update-pom goal is your easiest option I > think Ok, I'll try that next. But, for the record, my local M-build is working just fine.
David, you may also want to try reverting the commit mentioned in comment 4 (i.e. set eclipse.platform.team back to parent commit 0bde93181378cc4a8f0fd38811403dfdc54e02db). Since most Eclipse developers now use the pom.xml validation in the releng.tools plug-in, we probably haven't tested the pom updater at all for a while, since we never had anything to update. So I wouldn't rule out that commit as the one that reveals the NPE in tycho now.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > > > going back to 0.17.0 only for the update-pom goal is your easiest option I > > think > > Ok, I'll try that next. But, for the record, my local M-build is working > just fine. Well, Jan was right, as usual. :) Using 0.17.0 got "passed" the NPE and indeed did find a pom needed updating ... the one in "team". So, I conclude the "rule" is that as long as nothing needs updating 0.18.0 works fine (like maintenance, and my recent test I-builds) but if a POM does need updating, then it will hit the NPE.). I'd still like to find out more about what/how/why we have so many group IDs unspecified and how to fix them (easily) ... are there "warnings" among our 50,000 warnings? But, thanks greatly, Jan. = = = = diff --git a/bundles/org.eclipse.compare/pom.xml b/bundles/org.eclipse.compare/pom.xml index f010fa6..0f6265b 100644 --- a/bundles/org.eclipse.compare/pom.xml +++ b/bundles/org.eclipse.compare/pom.xml @@ -19,6 +19,6 @@ </parent> <groupId>org.eclipse.compare</groupId> <artifactId>org.eclipse.compare</artifactId> - <version>3.5.400-SNAPSHOT</version> + <version>3.5.500-SNAPSHOT</version> <packaging>eclipse-plugin</packaging> </project>
Since build is cooking, I'm closing as fixed. I have updated both master and R4_3_maintenance branch to use :0.17.0: explicitly (only for pom-updater). As follow up, I've opened bug 412131 to find and fix missing group Ids and bug 412135 as a reminder to move up to fixed version of pom-updater, whether that's 0.18.1 or 0.19.0.
(In reply to comment #2) > But, we have had several successful builds with 0.18.0 with things as they > are. So 1) I'm wondering what else might have changed? For the record, here is what (I think) happened: I guess that in your update-pom script, you did not specify an explicit version of tycho to be used for the update-pom goal. That means it's using "latest released" which was 0.17.0 for most of the Kepler development timeframe. Then we released tycho 0.18.0 with regression bug 409912. AFAIK the "latest released" version resolution for standalone goal execution relies on some kind of index on nexus which is updated asynchronously. This is how it's possible that you did not see the bug for some time even after tycho 0.18.0 was released. Regarding the missing groupId for build plugins, this is valid and I checked that maven does not warn about it. So you might have lots of places where this is the case and as it's tolerated normally.
(In reply to comment #14) > (In reply to comment #2) > > Regarding the missing groupId for build plugins, this is valid and I checked > that maven does not warn about it. So you might have lots of places where > this is the case and as it's tolerated normally. Just to make sure I'm interpreting this comment correctly ... are you saying it is valid (and normal) to not name the groupId for every plugin? Or just that its ok (and normal) not to since it is normally tolerated (and inferred correctly)? I'm just wondering if bug 412131 is a valid enhancement, or something that we should skip?
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #2) > > > > > Regarding the missing groupId for build plugins, this is valid and I checked > > that maven does not warn about it. So you might have lots of places where > > this is the case and as it's tolerated normally. > > Just to make sure I'm interpreting this comment correctly ... are you saying > it is valid (and normal) to not name the groupId for every plugin? Or just > that its ok (and normal) not to since it is normally tolerated (and inferred > correctly)? > > I'm just wondering if bug 412131 is a valid enhancement, or something that > we should skip? it's kind of a sloppy shorthand notation (probably for historical reasons in maven) that only works for plugins in groupId org.apache.maven.plugins. As a matter of fact the default groupId value org.apache.maven.plugins became API and people rely on it, so I would skip bug 412131
