On 15/08/2007, at 10:14 AM, Joakim Erdfelt wrote:
This example is actually bad IMO, as the top level version /
metadata/version element isn't the latest version, or the current
version, or even the last uploaded version.
Maven actually ignores it - it's a deployment bug. You can safely
omit it.
Example 2: http://repo1.maven.org/maven2/commons-beanutils/commons-
beanutils/1.6.1/maven-metadata.xml
<metadata>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.6.1</version>
</metadata>
Not very exciting, quite easy actually.
Maven deployment doesn't generate this, so whether we do or not
doesn't really matter
But when we deal with snapshots, it becomes critical.
Correct.
I would ensure that we generate it properly for timestamped
artifacts. I'm not exactly sure how maven deals with non-timestamped
artifacts when the metadata exists (the two other cases you listed
where it was mixed or always not timestamped but had metadata anyway)
- probably needs some investigation as to the best to generate here,
but leaving it out is probably the best option (in the mixed case, we
need to figure out how to decide when to leave it out - I'd say if
the last mod time of the -SNAPSHOT file is > all other timestamps in
the directory, or otherwise just make that a repository warning and
ignore one or the other).
.\ Areas of Concern \.
Alright, I think we have few areas of focus around this.
1) The repository consumer run to ensure that a metadata.xml file
exists.
if it's required.
2) The database consumer run to ensure that the contents of the
metadata.xml
are sane based on the list of available versions in the database.
if it exists
3) When proxying content from a remote repository for a released
artifact,
the type 1 groupId:artifactId needs to be updated to reflect the new
artifactId:version that was just downloaded.
I don't understand this?
4) When proxying content from a remote repository for a snapshot
artifact,
the proxy mechanism needs to pull the remote metadata.xml to
determine
what actual artifactId:version to pull.
right
Is it timestamped or not?
not sure if you are asking a question here or if it's a piece of
logic you are describing.
5) When proxying content from a remote repository for a snapshot
artifact,
the managed repository needs to have the current metadata.xml for
remote repository?
yes.
6) When presenting to the user browsing the repository, do we show
what is
in the managed repository, or the full list of potential versions
from all
downstream remote repositories too?
in 1.0, what is in the repository. Beyond, would be nice to have what
is remote (though it should be marked up). That gets more complicated
though, for cases where you haven't retrieved any artifacts yet - you
basically need a whole repository index update from remote.
.\ Ideas \.
I think it would be a good idea to adopt what happens in the local
repository
now, and have maven-metadata-${remote_repo_id}.xml files in the
managed
repository that the proxy mechanism keeps up to date, and the
seperate merge
mechanism utilizes to keep the managed repository metadata.xml as
accurate
as possible with all potential versions available.
+1
WDYT?
Sounds fine.
Cheers,
Brett
