archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: MRM-463 - metadata handling / merging
Date Wed, 15 Aug 2007 02:00:25 GMT

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


Mime
View raw message