Maven 2 & 3

Build numbers are incremented when they shouldn't

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0-beta-1
  • Fix Version/s: 2.0 (RC)
  • Component/s: None
  • Labels:
    None
  • Environment:
    Fedora 4, JDK 1.5.0_04, Maven 2 beta 1
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

I have a project built using m2. I want the project to install/deploy
a source-code JAR along with the binaries JAR (on both the install and
deploy phases). I've added the following section in the pom.xml file:

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

It works very nice, except for one problem: the sources JAR always
gets a new build number. For instance, assuming I clean my local repo,
and then run "m2 install", the local repo will contain:
myproject-20050925.155953-1.jar
myproject-20050925.155953-2-sources.jar

Shouldn't they have the same build number?

This causes a problem because the maven-metadata.xml file specifies
that the current build number is 2, and so, projects depending on that
project can't find the file (since there's no binary JAR for build
number 2, only for build 1).

Issue Links

This issue relates to:
MDEPLOY-43 Deploy plugin does not consider artifact type when deploying snapshots Critical Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

need to figure out how this feature regressed, and add a test to keep it from happening again.

Show
John Casey added a comment - need to figure out how this feature regressed, and add a test to keep it from happening again.
Hide
Permalink
Arik Kfir added a comment -

IŽll give it a try today and see if it sorted out on the latest sources (donŽt close yet!)

Show
Arik Kfir added a comment - IŽll give it a try today and see if it sorted out on the latest sources (donŽt close yet!)
Hide
Permalink
Arik Kfir added a comment -

Tried again using m2 trunk - and still happens. I've attached the exact POM so you can take a look (perhaps I'm doing something wrong?)

I've also tried cleaning my .m2 repo (completely removed it), but to no avail.

Show
Arik Kfir added a comment - Tried again using m2 trunk - and still happens. I've attached the exact POM so you can take a look (perhaps I'm doing something wrong?) I've also tried cleaning my .m2 repo (completely removed it), but to no avail.
Hide
Permalink
John Casey added a comment -

Attached artifacts are now formally handled by AttachedArtifact instances, which take the main artifact as a constructor parameter, and use it for things like groupId and version info. Once the main artifact's version is resolved (like for deployment), the attached instance automatically gets the same version information. Once that happens, the attached artifact doesn't look like a snapshot any more (for example) and will not have a new snapshot transformation performed on it. This should hold up for future meta-versions as well.

See it0079 for the test, based on the attached pom.

Show
John Casey added a comment - Attached artifacts are now formally handled by AttachedArtifact instances, which take the main artifact as a constructor parameter, and use it for things like groupId and version info. Once the main artifact's version is resolved (like for deployment), the attached instance automatically gets the same version information. Once that happens, the attached artifact doesn't look like a snapshot any more (for example) and will not have a new snapshot transformation performed on it. This should hold up for future meta-versions as well. See it0079 for the test, based on the attached pom.
Hide
Permalink
Arik Kfir added a comment -

Hi,

I tried again from the trunk (using the same POM I attached previously), and while there is some progress, it still does not work.

Now the binary and source-code JARs have the same build numbers, but the 'maven-metadata.xml' file (under the version directory) still contains a wrong build number.

In the repo are the following files:
[arik@bzq-179-147-142 0.1-SNAPSHOT]$ ll
total 112
rw-rw-r- 1 arik arik 309 Oct 5 04:14 maven-metadata.xml
rw-rw-r- 1 arik arik 32 Oct 5 04:14 maven-metadata.xml.md5
rw-rw-r- 1 arik arik 40 Oct 5 04:14 maven-metadata.xml.sha1
rw-rw-r- 1 arik arik 12832 Oct 5 04:14 msg-0.1-20051005.011402-1.jar
rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1.jar.md5
rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1.jar.sha1
rw-rw-r- 1 arik arik 3016 Oct 5 04:14 msg-0.1-20051005.011402-1.pom
rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1.pom.md5
rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1.pom.sha1
rw-rw-r- 1 arik arik 6924 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar
rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar.md5
rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar.sha1

Which is better than before - but the contents of the maven-metadata.xml file is:
[arik@bzq-179-147-142 0.1-SNAPSHOT]$ cat maven-metadata.xml
<metadata>
<groupId>org.messages</groupId>
<artifactId>msg</artifactId>
<version>0.1-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20051005.011402</timestamp>
<buildNumber>2</buildNumber>
</snapshot>
<lastUpdated>20051005011402</lastUpdated>
</versioning>
</metadata>

Note that the <buildNumber> is 2 - and not 1 as it should be (I cleaned the repo before building).

Let me know if you need more info.

Show
Arik Kfir added a comment - Hi, I tried again from the trunk (using the same POM I attached previously), and while there is some progress, it still does not work. Now the binary and source-code JARs have the same build numbers, but the 'maven-metadata.xml' file (under the version directory) still contains a wrong build number. In the repo are the following files: [arik@bzq-179-147-142 0.1-SNAPSHOT]$ ll total 112 rw-rw-r- 1 arik arik 309 Oct 5 04:14 maven-metadata.xml rw-rw-r- 1 arik arik 32 Oct 5 04:14 maven-metadata.xml.md5 rw-rw-r- 1 arik arik 40 Oct 5 04:14 maven-metadata.xml.sha1 rw-rw-r- 1 arik arik 12832 Oct 5 04:14 msg-0.1-20051005.011402-1.jar rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1.jar.md5 rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1.jar.sha1 rw-rw-r- 1 arik arik 3016 Oct 5 04:14 msg-0.1-20051005.011402-1.pom rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1.pom.md5 rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1.pom.sha1 rw-rw-r- 1 arik arik 6924 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar rw-rw-r- 1 arik arik 32 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar.md5 rw-rw-r- 1 arik arik 40 Oct 5 04:14 msg-0.1-20051005.011402-1-sources.jar.sha1 Which is better than before - but the contents of the maven-metadata.xml file is: [arik@bzq-179-147-142 0.1-SNAPSHOT]$ cat maven-metadata.xml <metadata> <groupId>org.messages</groupId> <artifactId>msg</artifactId> <version>0.1-SNAPSHOT</version> <versioning> <snapshot> <timestamp>20051005.011402</timestamp> <buildNumber>2</buildNumber> </snapshot> <lastUpdated>20051005011402</lastUpdated> </versioning> </metadata> Note that the <buildNumber> is 2 - and not 1 as it should be (I cleaned the repo before building). Let me know if you need more info.
Hide
Permalink
Arik Kfir added a comment -

One other thing - not sure it affects anything, but just in case - the POM I used in the last try has the <version> of "0.1-SNAPSHOT", and not "SNAPSHOT" as in the original POM I attached.

Show
Arik Kfir added a comment - One other thing - not sure it affects anything, but just in case - the POM I used in the last try has the <version> of "0.1-SNAPSHOT", and not "SNAPSHOT" as in the original POM I attached.
Hide
Permalink
John Casey added a comment -

Ah HA! Found it.

This is caused by attached artifacts having their own metadata, which is written when the artifact is deployed - over the top of the main artifact. Since these are attachments, they shouldn't change the metadata of the parent artifact. I'll geld the metadata handling on AttachedArtifact, and this should fix the problem.

Just waiting for SVN to come back up before I can commit.

Show
John Casey added a comment - Ah HA! Found it. This is caused by attached artifacts having their own metadata, which is written when the artifact is deployed - over the top of the main artifact. Since these are attachments, they shouldn't change the metadata of the parent artifact. I'll geld the metadata handling on AttachedArtifact, and this should fix the problem. Just waiting for SVN to come back up before I can commit.
Hide
Permalink
Arik Kfir added a comment -

cool! Let me know as soon as you commit, I'll give it a try.

Thanks!

Show
Arik Kfir added a comment - cool! Let me know as soon as you commit, I'll give it a try. Thanks!

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
3h
Original Estimate - 3 hours Original Estimate - 3 hours
Remaining:
0m
Remaining Estimate - 0 minutes
Logged:
4h
Time Spent - 4 hours
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.