Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » Aggregator usage for composite metadata repositories
Aggregator usage for composite metadata repositories [message #544530] Sat, 03 July 2010 11:52 Go to next message
Axel Guckelsberger is currently offline Axel Guckelsberger
Messages: 223
Registered: July 2009
Senior Member
Hi all,

I read through the b3 aggregator manual, but I have one question about it.
Probably I don't understand something essential.

I want to build a composite metadata repository (containing all metadata at
a central place, but redirecting to the Helios site for Eclipse artifacts
and other sites for some additional artifacts). Thus I looked at the 2nd
example with "mirror artifacts" set to false.

My basic problem is that I do not know how to include my own bundles. If I
would provide a normal update site for them, wouldn't this one then include
all the dependencies again (as my features do include required features like
the RCP platform)?

I am pretty sure I am missing something which should be obvious :-) Thanks
for any pointer.

Kindly regards,
Axel
Re: Aggregator usage for composite metadata repositories [message #544535 is a reply to message #544530] Sat, 03 July 2010 12:52 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
Some terminology first ...

A "composite" repository is a repository that points to other
repositories, it does not "contain" them physically.
R [->R2, ->R3, ... ]

An "aggregated" repository is a repository where other repositories have
been merged into one.
R = [R2 + R3 + ...]

An update site consists of a Metadata Repository (Rm) and an Artifact
Repository (Ra).
U = [Ra, Rm]

The Ra and/or Rm can be "composite" (an "aggregate" is not different
from a regular once it has been created).

So, you have full flexibility in composing a "graph" of repositories
under your "U".

1. Aggregate and mirror everything needed to one site. This is good if
you want your users to download from only your location - one stop
shopping. (Downside, not benefiting from mirror networks etc)

2. Aggregate and mirror everything produced by everyone except what is
available from eclipse where artifacts are served from eclipse.

3. Aggregate only meta data, serve artifacts from original locations.

An additional reason for using a composite repository is that it makes
it easy to swap one repository for another, add an additional repository
etc. This can be used to support test and release cases without having
to copy stuff around.

To get your stuff into the aggregation, you have to produce a p2
repository containing the material you want.

If a repository contains unwanted things, you can filter them out.
If you are in control of the process that produces the repository it is
probably more convenient to change the publishing so it contains only
what you want. I.e. rather that including runtime things when
publishing, create the final product zip from your repo + runtime repos.
This way the zipped ready to run contains everything needed, but your
repository only contains your things.

(In pseudo syntax)
If your product is 'x' published to repository Rx as IUx, Ax:
Rx (IUx, Ax)

You could create a composite Rmy:
Rmy = [->Rx, ->Rhelios]

And feed it to the director:
director Rmy install IUx
zip what was produced and copy to download area

or list the ones you need:
director Rx Rhelios install IUx
zip what was produced and copy to download area

The Rmy would be what you use as your U.

I hope that answers your questions.

- henrik

On 7/3/10 1:52 PM, Axel Guckelsberger wrote:
> Hi all,
>
> I read through the b3 aggregator manual, but I have one question about it.
> Probably I don't understand something essential.
>
> I want to build a composite metadata repository (containing all metadata at
> a central place, but redirecting to the Helios site for Eclipse artifacts
> and other sites for some additional artifacts). Thus I looked at the 2nd
> example with "mirror artifacts" set to false.
>
> My basic problem is that I do not know how to include my own bundles. If I
> would provide a normal update site for them, wouldn't this one then include
> all the dependencies again (as my features do include required features like
> the RCP platform)?
>
> I am pretty sure I am missing something which should be obvious :-) Thanks
> for any pointer.
>
> Kindly regards,
> Axel
>
Re: Aggregator usage for composite metadata repositories [message #611569 is a reply to message #544530] Sat, 03 July 2010 12:52 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
Hi,
Some terminology first ...

A "composite" repository is a repository that points to other
repositories, it does not "contain" them physically.
R [->R2, ->R3, ... ]

An "aggregated" repository is a repository where other repositories have
been merged into one.
R = [R2 + R3 + ...]

An update site consists of a Metadata Repository (Rm) and an Artifact
Repository (Ra).
U = [Ra, Rm]

The Ra and/or Rm can be "composite" (an "aggregate" is not different
from a regular once it has been created).

So, you have full flexibility in composing a "graph" of repositories
under your "U".

1. Aggregate and mirror everything needed to one site. This is good if
you want your users to download from only your location - one stop
shopping. (Downside, not benefiting from mirror networks etc)

2. Aggregate and mirror everything produced by everyone except what is
available from eclipse where artifacts are served from eclipse.

3. Aggregate only meta data, serve artifacts from original locations.

An additional reason for using a composite repository is that it makes
it easy to swap one repository for another, add an additional repository
etc. This can be used to support test and release cases without having
to copy stuff around.

To get your stuff into the aggregation, you have to produce a p2
repository containing the material you want.

If a repository contains unwanted things, you can filter them out.
If you are in control of the process that produces the repository it is
probably more convenient to change the publishing so it contains only
what you want. I.e. rather that including runtime things when
publishing, create the final product zip from your repo + runtime repos.
This way the zipped ready to run contains everything needed, but your
repository only contains your things.

(In pseudo syntax)
If your product is 'x' published to repository Rx as IUx, Ax:
Rx (IUx, Ax)

You could create a composite Rmy:
Rmy = [->Rx, ->Rhelios]

And feed it to the director:
director Rmy install IUx
zip what was produced and copy to download area

or list the ones you need:
director Rx Rhelios install IUx
zip what was produced and copy to download area

The Rmy would be what you use as your U.

I hope that answers your questions.

- henrik

On 7/3/10 1:52 PM, Axel Guckelsberger wrote:
> Hi all,
>
> I read through the b3 aggregator manual, but I have one question about it.
> Probably I don't understand something essential.
>
> I want to build a composite metadata repository (containing all metadata at
> a central place, but redirecting to the Helios site for Eclipse artifacts
> and other sites for some additional artifacts). Thus I looked at the 2nd
> example with "mirror artifacts" set to false.
>
> My basic problem is that I do not know how to include my own bundles. If I
> would provide a normal update site for them, wouldn't this one then include
> all the dependencies again (as my features do include required features like
> the RCP platform)?
>
> I am pretty sure I am missing something which should be obvious :-) Thanks
> for any pointer.
>
> Kindly regards,
> Axel
>
Previous Topic:Aggregator usage for composite metadata repositories
Next Topic:Unable to build Helios release with b3
Goto Forum:
  


Current Time: Thu Sep 18 21:47:34 GMT 2014

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

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