Brett Porter wrote:
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.
Would it be wise to be a good repository citizen and keep that field
updated?
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
Interesting. Who generates this then? As it's in every versioned
artifact I look at.
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.
Can you expand on what you mean by '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
You mean, if the maven-metadata.xml exists, then update it. But if it
doesn't exist, don't update it?
I would think you would always want a maven-metadata.xml file. Am I
wrong in that assumption?
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?
This is the Type 1, Example 1 reference.
If we download due a proxy request version 2.1 of commons-lang, but our
managed repository local maven-metadata.xml file doesn't have it listed,
then add that version to the maven-metadata.xml file.
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.
More logic then question.
As the proxy request to the remote repository needs to know what
artifact / pom to actually pull, based on the contents of the remote
maven-metadata.xml file.
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.
I thought about the whole repository index question, I don't think
that's necessary. Lemme explain ...
I think that if you have a project that utilizes a specific
groupId:artifactId, then you have shown an interest in that specific
groupId:artifactId, and knowing about new releases, etc.. would be a
good idea. Could prove to be a useful avenue for a future RSS feed, or
maven-am-i-up-to-date-plugin, or even some IDE integration angle. no?
.\ 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
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
