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:[email protected]]
Sent: Monday, May 09, 2011 10:06 AM
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
----------------------------------------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
