Brett Porter wrote:
On 15/08/2007, at 12:19 PM, Joakim Erdfelt wrote:
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?
No - it doesn't make any sense (it's not meant to reside in that
directory). The <release> tag is probably the one to update.
Ok. I'll chalk this up as a maven 2 anomaly, we'll likely need to fill
that element out just to avoid a parsing error on the maven 2 side no?
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.
No idea, but if you look at a recent release, it's not generated:
http://people.apache.org/~oching/stage-repo/org/apache/maven/archiva/archiva-lucene-consumers/1.0-beta-1/
Maybe it depends on your version of Maven/deploy plugin.
Curses. Using an Archiva release against me. ;-)
So noted. Chalked up as not-important.
Should we consider a file like this as "out of place" or "bad" for the
repository problem reports then?
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' ?
Same as the point above - the metadata without snapshots is kind of
useless, so we may not require it in the version directory.
Again. useless metadat.xml files encountered. Do we make a repository
problem report for this too?
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?
Just the same as above. Certainly if it should exist, create it.
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?
would need to think about this some more - all I think right now is
post-1.0 :)
Yep. those 3 ideas are all post-1.0 (Future) concepts.
But you understand what I'm getting at though?
One last thing I thought about.
If we have a set of maven-metadata-${remote_repo_id}.xml files, should
we make sure those files are updated on a schedule (like a database
consumer) or just in time, when the proxy request occurs?
- Joakim
