You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Gracia, Adrien" <ad...@baml.com> on 2011/05/09 16:11:25 UTC
metadata.xml
Hi
We have a jar repository that was created a while back during the maven one time. It is not a maven repo.
Now that we are slowly migrating to maven 2/3, we create a wrapper around the repo to be able to send artifact to way maven expects them. This will disappear once all our projects are migrated to maven.
We use nexus as our main repo.
The problem we are having, is that even if there is a new version of a SNAPSHOT, the newer version is not downloaded. We added the updatePolicy to always for all our snapshot repos and it works for Nexus but not "our repo".
We are trying to understand how it works to be able to mimic the behavior.
We saw the request for the metadata.xml come and we thought that it was the solution to our problem, but it seems that we are missing something.
The way we understood the format of this file is as follow
<metadata>
<groupId>the group id</groupId>
<artifactId>the artifact id</artifactId>
<versioning>
<versions>
<version></version>
<version></version>
<version></version>
...
</versions>
<lastUpdated>the formatted timestamp of the most up to date version</lastUpdated>
</versioning>
</metadata>
Now one question would be: Does the order of the version matter?
How does it really works?
I am doing some remote debugging into the maven code to try to understand the process, but I'd like to see if someone could also point me in the right direction.
Thanks a lot
Adrien Gracia
Bank of America
----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
Re: metadata.xml
Posted by Benjamin Bentmann <be...@udo.edu>.
Gracia, Adrien wrote:
> The timestamp and the last updated value is the file modified timestamp
Just be sure to store <lastUpdated> in UTC.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: metadata.xml
Posted by "Gracia, Adrien" <ad...@baml.com>.
So I think we were able to fix it.
We indeed were not creating the right metadata.xml file.
We are not creating something like that:
<metadata>
<groupId>org.apache.maven</groupId>
<artifactId>maven-aether-provider</artifactId>
<version>3.0-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20101004.110147</timestamp>
<buildNumber>1</buildNumber>
</snapshot>
<lastUpdated>20101004110147</lastUpdated>
</versioning>
</metadata>
Now a couple notes:
Since this is not a real repo and we are mimicking Nexus, we have no real information about build numbers and all, we could go fancy but we just wanted to do something dirty because it is throw away code.
The timestamp and the last updated value is the file modified timestamp
The buildnumber is always 1. (hopefully this works, and based on testing it seems to be).
Finally, we had to change the code to return the auto generated pom and the jar with adding to the name the timestamp and build number.
If any of you seem to see something wrong with this approach please let me know.
Thanks Benjamin, and wayne for your help.
Adrien Gracia
Bank of America
GFX Technology
-----Original Message-----
From: Benjamin Bentmann [mailto:benjamin.bentmann@udo.edu]
Sent: Monday, May 09, 2011 10:06 AM
To: users@maven.apache.org
Subject: Re: metadata.xml
Gracia, Adrien wrote:
> The problem we are having, is that even if there is a new version of a SNAPSHOT, the newer version is not downloaded.
> [...]
> The way we understood the format of this file is as follow
>
> <metadata>
> <groupId>the group id</groupId>
> <artifactId>the artifact id</artifactId> <versioning> <versions>
> <version></version> <version></version> <version></version> ...
> </versions>
> <lastUpdated>the formatted timestamp of the most up to date
> version</lastUpdated> </versioning> </metadata>
This file actually exists at different levels of the repository, having a different format/contents at each level.
maven-metadata.xml at the groupId level serves plugin prefix mappings, metadata at the groupId:artifactId level serves version range resolution and metadata at the groupId:artifactId:version level supports SNAPSHOT resolution.
The format you pasted actually describes groupId:artifactId level metadata. To investigate issues with SNAPSHOT resolution, you need to look at the metadata of this format:
<metadata>
<groupId>org.apache.maven</groupId>
<artifactId>maven-aether-provider</artifactId>
<version>3.0-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20101004.110147</timestamp>
<buildNumber>62</buildNumber>
</snapshot>
<lastUpdated>20101004110401</lastUpdated>
</versioning>
</metadata>
During resolution of X-SNAPSHOT, Maven will read the maven-metadata.xml for all configured remote repos, select the one having the biggest/newest <lastUpdated> field, and finally resolve the artifact X-<timestamp>-<buildNumber>.
> Now one question would be: Does the order of the version matter?
No.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: metadata.xml
Posted by Benjamin Bentmann <be...@udo.edu>.
Gracia, Adrien wrote:
> The problem we are having, is that even if there is a new version of a SNAPSHOT, the newer version is not downloaded.
> [...]
> The way we understood the format of this file is as follow
>
> <metadata>
> <groupId>the group id</groupId>
> <artifactId>the artifact id</artifactId>
> <versioning>
> <versions>
> <version></version>
> <version></version>
> <version></version>
> ...
> </versions>
> <lastUpdated>the formatted timestamp of the most up to date version</lastUpdated>
> </versioning>
> </metadata>
This file actually exists at different levels of the repository, having
a different format/contents at each level.
maven-metadata.xml at the groupId level serves plugin prefix mappings,
metadata at the groupId:artifactId level serves version range resolution
and metadata at the groupId:artifactId:version level supports SNAPSHOT
resolution.
The format you pasted actually describes groupId:artifactId level
metadata. To investigate issues with SNAPSHOT resolution, you need to
look at the metadata of this format:
<metadata>
<groupId>org.apache.maven</groupId>
<artifactId>maven-aether-provider</artifactId>
<version>3.0-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20101004.110147</timestamp>
<buildNumber>62</buildNumber>
</snapshot>
<lastUpdated>20101004110401</lastUpdated>
</versioning>
</metadata>
During resolution of X-SNAPSHOT, Maven will read the maven-metadata.xml
for all configured remote repos, select the one having the
biggest/newest <lastUpdated> field, and finally resolve the artifact
X-<timestamp>-<buildNumber>.
> Now one question would be: Does the order of the version matter?
No.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: metadata.xml
Posted by Wayne Fay <wa...@gmail.com>.
> Now one question would be: Does the order of the version matter?
Off the top of my head, I don't know how the code worked in Maven1
days as I did not start using Maven until Maven2. But it would not
surprise me to hear the version ordering was important.
This seems like a very easy thing to test before digging too deep into
code to sort it out by simply faking a few metadata.xml files for some
fake artifacts and seeing which version was picked, then change the
metadata.xml (add a new version at top/middle/bottom and adjust
lastUpdated) and try an update and see what was picked.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org