You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ro...@pjm.com on 2015/08/26 20:45:31 UTC
Using build-helper-maven-plugin in bundle projects causing problems
with in -SNAPSHOT builds
All,
NOTE: I've cross posted this on the Mojohaus list.
We're having a problem using build-helper-maven-plugin to deploy features.xml files in projects that also deploy a bundle/.jar. The maven-metadata.xml in Nexus has wrong <buildNumber>. We have projects that have features.xml files that are deployed to Nexus using the build-helper-maven-plugin along with the bundle/.jar and POM. The maven-metadata.xml will have, for example, <buildNumber> 51, but the <value> tags in the <snapshotVersion> enties will be -50.
I am attaching build-test.zip which includes a set of projects that will demonstrate the issue, as well as the file maven-deploy-notes.txt which shows some TCP log results, and a set of maven-metadata.xml files (renamed for differentiation) showing the <buildNumber> and <value> entries we're seeing.
This issue causes a problem when we try to do on-demand builds that need to be installed on the TEST environment, which _must_ go through Nexus - we don't do the build on TEST... we do the build on our build system which deploys the build to Nexus. The TEST system is then unable to download the 'latest' build due to the buildNumber issue.
There is a Nexus Scheduled Task that runs daily at 4am - the Remote Snapshots from Repository task. In addition to removing old snapshot versions, this task seems to "correct" the buildNumber issue, ensuring that the buildNumber matches the last build in the directory. This allows us to install nightly builds in TEST, but doesn't help with mid-day build problems.
We've seen this problem using Apache Maven 3.0.4, 3.0.5 and 3.3.3, as well as Oracle JDK versions 1.7.0 update 55 and 1.7.0 update 79. Developers are on Windows 7, and the TeamCity build system runs on Linux. Nexus is running on SUSE Linux Enterprise Server 11 SP3 with Java 1.7.0_55.
Have we done something wrong constructing our POMs? Is there an issue with the plugin?
Thanks
Bob
RE: Using build-helper-maven-plugin in bundle projects causing
problems with in -SNAPSHOT builds
Posted by Martin Gainty <mg...@hotmail.com>.
From: Robert.Blackard@pjm.com
To: users@maven.apache.org
Subject: RE: Using build-helper-maven-plugin in bundle projects causing problems with <buildNumber> in -SNAPSHOT builds
Date: Thu, 27 Aug 2015 17:20:13 +0000
It was pointed out to me that the sample projects I uploaded were version 0.0.1 rather than 0.0.1-SNAPSHOT. My apologies about that. I have continued to experiment and I thought I sent the version before I
stripped the -SNAPSHOT tab out.
Attached is a version of the project with version 0.0.1-SNAPSHOT. It also rearranges the parent structure ever so slightly.
MG>Bob
MG>which pom contains <buildNumber>50</buildNumber> ?
MG>I dont see <buildnumber>50</buildnumber in any of the poms
From: Robert.Blackard@pjm.com [mailto:Robert.Blackard@pjm.com]
Sent: Wednesday, August 26, 2015 2:46 PM
To: users@maven.apache.org
Subject: Using build-helper-maven-plugin in bundle projects causing problems with <buildNumber> in -SNAPSHOT builds
All,
NOTE: I’ve cross posted this on the Mojohaus list.
We’re having a problem using build-helper-maven-plugin to deploy features.xml files in projects that also deploy a bundle/.jar. The maven-metadata.xml in Nexus has wrong <buildNumber>.
We have projects that have features.xml files that are deployed to Nexus using the build-helper-maven-plugin along with the bundle/.jar and POM. The maven-metadata.xml will have, for example, <buildNumber> 51, but the <value> tags in the <snapshotVersion>
enties will be -50.
I am attaching build-test.zip which includes a set of projects that will demonstrate the issue, as well as the file maven-deploy-notes.txt which shows some TCP log results, and a set
of maven-metadata.xml files (renamed for differentiation) showing the <buildNumber> and <value> entries we're seeing.
This issue causes a problem when we try to do on-demand builds that need to be installed on the TEST environment, which _must_ go through Nexus - we don't do the build on TEST... we
do the build on our build system which deploys the build to Nexus. The TEST system is then unable to download the 'latest' build due to the buildNumber issue.
There is a Nexus Scheduled Task that runs daily at 4am - the Remote Snapshots from Repository task. In addition to removing old snapshot versions, this task seems to "correct" the
buildNumber issue, ensuring that the buildNumber matches the last build in the directory. This allows us to install nightly builds in TEST, but doesn't help with mid-day build problems.
We've seen this problem using Apache Maven 3.0.4, 3.0.5 and 3.3.3, as well as Oracle JDK versions 1.7.0 update 55 and 1.7.0 update 79. Developers are on Windows 7, and the TeamCity
build system runs on Linux. Nexus is running on SUSE Linux Enterprise Server 11 SP3 with Java 1.7.0_55.
Have we done something wrong constructing our POMs? Is there an issue with the plugin?
Thanks
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Using build-helper-maven-plugin in bundle projects causing
problems with in -SNAPSHOT builds
Posted by Ro...@pjm.com.
All,
This is resolved, though I don't much like the solution.
It seems the problem was using the command "mvn clean deploy" rather than "mvn clean bundle:deploy".
Multiple plugins were matching the deploy goal, and one of those was incrementing the buildNumber an extra time and updating/putting the maven-metadata.xml again.
Using "mvn clean deploy:deploy" resulting in only POM files for projects with <packaging> pom get uploaded. Features files for POM projects are not uploaded, and bundle projects get nothing at all uploaded - no POM, no Features and no Bundle/.jar.
Using "mvn clean bundle:deploy" causes everything to work just peachy. All POM files for all projects/packaging types get uploaded. Those projects that use the build-helper-maven-plugin to upload a Features file get the Features file uploaded. Those projects that are Bundle projects get the Bundle/.jar file uploaded.
I'm still not sure what *:deploy bit was doing the bogus increment, but I have a resolution so I'm not planning on investigating further.
Bob
From: Robert.Blackard@pjm.com [mailto:Robert.Blackard@pjm.com]
Sent: Thursday, August 27, 2015 1:20 PM
To: users@maven.apache.org
Subject: RE: Using build-helper-maven-plugin in bundle projects causing problems with <buildNumber> in -SNAPSHOT builds
It was pointed out to me that the sample projects I uploaded were version 0.0.1 rather than 0.0.1-SNAPSHOT. My apologies about that. I have continued to experiment and I thought I sent the version before I stripped the -SNAPSHOT tab out.
Attached is a version of the project with version 0.0.1-SNAPSHOT. It also rearranges the parent structure ever so slightly.
From: Robert.Blackard@pjm.com<ma...@pjm.com> [mailto:Robert.Blackard@pjm.com]
Sent: Wednesday, August 26, 2015 2:46 PM
To: users@maven.apache.org<ma...@maven.apache.org>
Subject: Using build-helper-maven-plugin in bundle projects causing problems with <buildNumber> in -SNAPSHOT builds
All,
NOTE: I've cross posted this on the Mojohaus list.
We're having a problem using build-helper-maven-plugin to deploy features.xml files in projects that also deploy a bundle/.jar. The maven-metadata.xml in Nexus has wrong <buildNumber>. We have projects that have features.xml files that are deployed to Nexus using the build-helper-maven-plugin along with the bundle/.jar and POM. The maven-metadata.xml will have, for example, <buildNumber> 51, but the <value> tags in the <snapshotVersion> enties will be -50.
I am attaching build-test.zip which includes a set of projects that will demonstrate the issue, as well as the file maven-deploy-notes.txt which shows some TCP log results, and a set of maven-metadata.xml files (renamed for differentiation) showing the <buildNumber> and <value> entries we're seeing.
This issue causes a problem when we try to do on-demand builds that need to be installed on the TEST environment, which _must_ go through Nexus - we don't do the build on TEST... we do the build on our build system which deploys the build to Nexus. The TEST system is then unable to download the 'latest' build due to the buildNumber issue.
There is a Nexus Scheduled Task that runs daily at 4am - the Remote Snapshots from Repository task. In addition to removing old snapshot versions, this task seems to "correct" the buildNumber issue, ensuring that the buildNumber matches the last build in the directory. This allows us to install nightly builds in TEST, but doesn't help with mid-day build problems.
We've seen this problem using Apache Maven 3.0.4, 3.0.5 and 3.3.3, as well as Oracle JDK versions 1.7.0 update 55 and 1.7.0 update 79. Developers are on Windows 7, and the TeamCity build system runs on Linux. Nexus is running on SUSE Linux Enterprise Server 11 SP3 with Java 1.7.0_55.
Have we done something wrong constructing our POMs? Is there an issue with the plugin?
Thanks
Bob
RE: Using build-helper-maven-plugin in bundle projects causing
problems with in -SNAPSHOT builds
Posted by Ro...@pjm.com.
It was pointed out to me that the sample projects I uploaded were version 0.0.1 rather than 0.0.1-SNAPSHOT. My apologies about that. I have continued to experiment and I thought I sent the version before I stripped the -SNAPSHOT tab out.
Attached is a version of the project with version 0.0.1-SNAPSHOT. It also rearranges the parent structure ever so slightly.
From: Robert.Blackard@pjm.com [mailto:Robert.Blackard@pjm.com]
Sent: Wednesday, August 26, 2015 2:46 PM
To: users@maven.apache.org
Subject: Using build-helper-maven-plugin in bundle projects causing problems with <buildNumber> in -SNAPSHOT builds
All,
NOTE: I've cross posted this on the Mojohaus list.
We're having a problem using build-helper-maven-plugin to deploy features.xml files in projects that also deploy a bundle/.jar. The maven-metadata.xml in Nexus has wrong <buildNumber>. We have projects that have features.xml files that are deployed to Nexus using the build-helper-maven-plugin along with the bundle/.jar and POM. The maven-metadata.xml will have, for example, <buildNumber> 51, but the <value> tags in the <snapshotVersion> enties will be -50.
I am attaching build-test.zip which includes a set of projects that will demonstrate the issue, as well as the file maven-deploy-notes.txt which shows some TCP log results, and a set of maven-metadata.xml files (renamed for differentiation) showing the <buildNumber> and <value> entries we're seeing.
This issue causes a problem when we try to do on-demand builds that need to be installed on the TEST environment, which _must_ go through Nexus - we don't do the build on TEST... we do the build on our build system which deploys the build to Nexus. The TEST system is then unable to download the 'latest' build due to the buildNumber issue.
There is a Nexus Scheduled Task that runs daily at 4am - the Remote Snapshots from Repository task. In addition to removing old snapshot versions, this task seems to "correct" the buildNumber issue, ensuring that the buildNumber matches the last build in the directory. This allows us to install nightly builds in TEST, but doesn't help with mid-day build problems.
We've seen this problem using Apache Maven 3.0.4, 3.0.5 and 3.3.3, as well as Oracle JDK versions 1.7.0 update 55 and 1.7.0 update 79. Developers are on Windows 7, and the TeamCity build system runs on Linux. Nexus is running on SUSE Linux Enterprise Server 11 SP3 with Java 1.7.0_55.
Have we done something wrong constructing our POMs? Is there an issue with the plugin?
Thanks
Bob