On 15/08/2007, at 12:34 PM, Joakim Erdfelt wrote:
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?
I don't think so, but worth checking.
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?
nah... as long as it is valid.
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?
I don't think so, just a problem if it isn't there when it has to be.
But you understand what I'm getting at though?
Kind of - just short on bandwidth right now. We can do the wiki
proposal thing to get through it more completely.
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?
just in time since it involves network behaviour (as we go beyond 1.0
and look at pre-emptive syncing that might change, and I suspect that
ties in to the previous point).
Cheers,
Brett
