Home » Archived » B3 » Aggregator usage for composite metadata repositories
|
| Re: Aggregator usage for composite metadata repositories [message #544535 is a reply to message #544530] |
Sat, 03 July 2010 12:52  |
 Henrik Lindberg
Messages: 2509
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 |
Henrik Lindberg
Messages: 2509
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
>
|
|
|
Goto Forum:
Current Time: Thu Sep 12 22:27:04 GMT 2024
Powered by FUDForum. Page generated in 0.04344 seconds |
] 
Search
Help
Register
Login
Home
