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.

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.

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
>

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.

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
>