|Re: content.xml vs. artifacts.xml [message #1040577 is a reply to message #1039717]
||Sat, 13 April 2013 21:00
| Henrik Lindberg
Registered: July 2009
On 2013-12-04 15:49, Klaus Kopecz wrote:|
> I browsed through a lot of p2 web resources but I failed to find good
> answers to my questions below. Maybe someone can point me to good
> resources or can provide the answer here right away - thanks:
First, note that the xml files and their location is part of specific
implementations of the concepts metadata- and artifact- repository. p2's
API is not document based.
> (1) what was the reason for the design decision to introduce a separate
> artifacts.xml in addition to content.xml. What are the advantaged to the
> alternative to provide all artifact information within content.xml, for
> instance, as part of the <artifacts> element below <unit>? One advantage
> might be that the two files can be authored by different agents, but I'm
> not sure whether this is a real use case.
Metadata does not have to come from a physical repository. It can be
generated as a description of something that simply exists. In general
it is just a separation of concerns; the traits of metadata (much
smaller in size etc.) vs. artifacts (big, often binary) makes it
meaningful to separate the implementations. The mirroring of the two is
also different, you want the master version of the metadata (it may have
changed and you don't know if you are only looking at a stale mirror,
whereas the immutable artifacts are either there or not).
There are probably other reasons as well - this just from the top of my
> (2) as I understood, artifacts.xml can be at a different place than
> content.xml? I guess in the Eclipse context the assumption is that
> artifacts.xml is at the same place than content.xml. Otherwise, it would
> not be sufficient to provide one "update site" URL. Correct?
This is the implementation of one particular type of repository where a
search is made by probing for a variety of different types of p2 related
context in xml format rooted at the "repository URL".
> (3) In content.xml I find things like <artifacts size='1'>
> <artifact classifier='osgi.bundle'
> id='org.eclipse.emf.facet.infra.common.ui' version='0.2.2.201301231232'/>
> This let me hypothesize that it is possible to wrap multiple artifacts
> by one installable unit?
yes, but not sure how well that works in practice - I experimented with
that in the past and it did not work so well; instead I zipped up the
content and made it into one artifact. IIRC the reason it did not work
that well was because of the lack of available actions (again IIRC) they
were designed to work with one artifact per IU.
If you really want to get to know how it works, you have to look at the
p2 code. If you need to do repository manipulation, use the p2 API, or
something like the b3 aggregator's p2 model which allows you to
read/write repositories, slice and dice, and then validate the result.
Hope that helps.
What is it you are trying to do/would like to do?
Powered by FUDForum
. Page generated in 0.01750 seconds