I build an eclipse product that is basically an eclipse sdk but with some homegrown plugins and features and external features.
I manage the updatesites and the distribution via the eclipse director.
I have a small problem that whenever people install things into the product from my P2 updatesite, the feature they install contributes its own updatesite.
When i build the product i use the p2.inf file to add my predefined sites which works as it should, but is there any way i can hinder all these other sites from showing up amongs the updatesites when they get installed?
The problem is that we are not allowed to go outside the firewall with eclipse and it should all be treated internally. Eclipse complains it cannot find or access certain updatesites, becuase they are on the internet, easy fix is to just disable these sites but it causes support questions.
I could remove the updatesites from all the feature.xml but that means i need to patch a lot of features as i am distibuting these internally and i have to do this every time they are updated and we want to update internally.
any ideas on how to prevent the "external" features to contribute their own updatesites?
David <email@example.com> wrote:
> I build an eclipse product that is basically an eclipse sdk but with some
> homegrown plugins and features and external features.
> any ideas on how to prevent the "external" features to contribute their own updatesites?
You can use the eclipse b3 aggregator to compose an update site where you
have cleaned up external references
Is this documented somewhere? looking through the headless options, the wiki page etc, can't find anything that relates to this, or its just day before new years and i am wondering what i am doing here
You will not find docs that spells out how to support you use case. What
you probably want is to create a behind the firewall repo that contains
everything your users need. This repo can be created as a composition of
several repos, and each repo can in turn be a repo created with the
aggregator (or any other mechanism that creates a p2 repo). The aggregator
allows mirroring with filtering and reauthoring of the repo content.
It may be possible to do what you want with a single aggregation. Others
that have similar use cases typically divide the tasks into several
aggregations, as they do not want to perform updates as frequently of the
larger eclipse repos, and the use their mirrored eclipse repos in several
in-house repo compositions (thus requiring fewer copies of content).
Hope that helps.
David <firstname.lastname@example.org> wrote:
> ohh, did not know that!
> Is this documented somewhere? looking through the headless options, the
> wiki page etc, can't find anything that relates to this, or its just day
> before new years and i am wondering what i am doing here :)