[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Aggregating ArtifactRepositories

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.



Inactive hide details for Thomas Hallgren ---28/11/2008 04:56:51 AM---I have a situation where a server has a knowledge of a loThomas 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


GIF image

GIF image