Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » P2 » content.xml vs. artifacts.xml
content.xml vs. artifacts.xml [message #1039717] Fri, 12 April 2013 13:49 Go to next message
Klaus Kopecz is currently offline Klaus KopeczFriend
Messages: 20
Registered: February 2012
Junior Member
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:

(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.

(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?

(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'/>
</artifacts>
This let me hypothesize that it is possible to wrap multiple artifacts by one installable unit?

Best regards,
Re: content.xml vs. artifacts.xml [message #1040577 is a reply to message #1039717] Sat, 13 April 2013 21:00 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2501
Registered: July 2009
Senior Member
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
mind.

> (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'/>
> </artifacts>
> 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?

Regards
- henrik
Re: content.xml vs. artifacts.xml [message #1041586 is a reply to message #1040577] Mon, 15 April 2013 09:25 Go to previous message
Klaus Kopecz is currently offline Klaus KopeczFriend
Messages: 20
Registered: February 2012
Junior Member
Thanks Henrik,
My motivation is that I'm evaluating whether p2 metadata might be used in the context of design time repository harmonization. p2 metadata might be used to describe the content and dependencies of design time objects. Further, we want to separate the "storage container" or "resource" from the detailed content of design time objects contained in a resource. Handling of the first can be standardized very much (storage, protocols, etc), whereas the latter is very context specific (are you doing Java dev or something very different). p2 would come in to describe dependencies between containers but also to describe the content of the containers.
"Installation" from such p2 metadata enriched design time repositories would then, for instance, lead to populating a developer workspace. Pretty similar to how Buckminster works ...
Regards,
Klaus
Previous Topic:p2 resolver hints - forcing wiring (OSGi)
Next Topic:Updating Eclipse E4 project fails through p2
Goto Forum:
  


Current Time: Sat Dec 20 10:29:47 GMT 2014

Powered by FUDForum. Page generated in 0.01817 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software