Re: [p2-dev] Aggregating ArtifactRepositories

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

We recently (in the course of M4) have released support for composite repositories. This will allow you to aggregate several artifact repositories.
Then the MDR can refer to this repo.
Also, note that only the UI "forces" this colocation of artifact and metadata repo just so the user does not have to add two locations. However we have had the ability to have a repo refer to another one so I think this limitation could probably be removed too.



Thomas Hallgren ---28/11/2008 04:56:51 AM---I have a situation where a server has a knowledge of a lot of MetadataRepositories and ArtifactRepo

From:	Thomas Hallgren <thomas@xxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	28/11/2008 04:56 AM
Subject:	[p2-dev] Aggregating ArtifactRepositories

---

I have a situation where a server has a knowledge of a lot of 
MetadataRepositories and ArtifactRepositories but it does not mirror the 
actual artifacts. The objective for the server is to keep track of 
things, not to store things.

A common use-case will be to create a subset of what I have in the 
database and present that as an installable site (i.e. an MDR and an 
AR). The subset is limited by a set of root IU's. This is how I 
currently do this:

1. Query the database for the transitive closure of all IU's that 
fulfill at least one required capability from another IU using the root 
IU's as the starting point.
2. Create an MDR from the generated closure.
3. Generate an AR based on all ArtifactKey's of all IU's in the MDR.

Step one and two are trivial. Step three is more complicated because 
each AR has it's own way of computing the actual location of the 
artifact. The solution I've come up with right now is not ideal and I 
would like to discuss how to improve it:

1. I store the result of the SimpleArtifactRepository.getLocation(desc) 
in the repository together with the descriptor.
2. When generating the final AR, I include the location as a 
'repositoryProperty' named 'artifact.reference'.

This works, since the SimpleArtifactRepository will use this reference 
and bypass all calculations that are based on the repository location 
but it has one rather serious drawback. The mirror selection does not 
come into play at all.

I could add an extra step that would calculate a mirror location when 
the AR is generated. It would be slightly better since it would spread 
the load but the information would still be static. From that point on, 
any given artifact will always be fetched from the same mirror. Not 
ideal either.

A better solution for me would be if the artifact descriptor could be 
extended to include (and hence, possibly override) the properties 
declared in the repository. That way I could provide a "mirror base" to 
each descriptor and trust P2 to compute the correct mirror on demand.

Another solution would be to avoid the AR generation completely and 
instead provide the URL's of the original AR's. This doesn't seem to be 
possible at present since the P2 update manager assumes that a 'site' 
consists of exactly one MDR and one AR and that they reside in the same 
location.

Any input on this is greatly appreciated.

Regards,
Thomas Hallgren

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev