|Aggregated repository - allow updates of mapped features [message #884672]
||Mon, 11 June 2012 11:34
| Pavel Tarasenko
Registered: June 2012
I have difficulties configuring aggregated repository that should serve as a central Eclipse update mirror for our team. We are trying to mirror ~25 external Eclipse update sites (standard set, findbugs, etc.) and also want to aggregate few our internal update sites where our developers are publishing Eclipse extensions they are working on.
The goal is to avoid mirroring of internal update sites and have a single aggregate repository that will "redirect" clients to internal update sites. Any update (new plug-in version, etc.) on the internal update sites should be instantly and automatically available through the aggregated repository.
So far, it doesn't work. I have to manually open b3 model and re-build aggregated repository to make updates from internal update sites avaialble in the aggregated repo.
Here's details about my current setup:
* All features from internal update sites are mapped to a custom category
* "mirror = false" for "validated repository" entries associated with internal update sites
* Generated final/aggregate/ directory doesn't contain mirrored artifacts from internal sites
* compositeArtifacts.xml contains <child/> entry for each referenced internal update site
* content.xml contains two kinds of information about our custom plug-ins and features
** fixed versions that were available at time of aggregate repository generation
** version ranges for feature declared in custom category
I tried both to specify a "permissive" OSGI version range for features and keep this version range open-ended (default setting) but no luck. Updated version of features are perfectly avaialbe when you chek internal update site directly but not from aggregated repository.
I'd be very grateful if someone could give me a hint what is wrong with my current configuration.
|Re: Aggregated repository - allow updates of mapped features [message #885354 is a reply to message #885185]
||Tue, 12 June 2012 17:25
| Henrik Lindberg
Registered: July 2009
On 2012-12-06 17:13, Pavel Tarasenko wrote:|
> Thank you for the detailed explanation. Using a b3 for each team in our
> organization probably will be a bit an overkill for us.
> I will consider a simple aggregation (as suggested by Dennis) that will
> link together content from "external" Eclipse update sites aggregated
> with b3 and our internal update sites with in-house plug-ins.
> Of course, it would be much more convenient to avoid extra aggregation
> level and have all configuration managed from b3 model.
Not sure it was clear, I meant - do one aggregation with b3 of your
different team's results/repositories in order to produce a "release"
(milestone/build/whatever) - compose the resulting repositories (over
time) into one. Prune depending on type or resulting repo.
Teams does not have to use b3, but you may want to delegate the
responsibility to the teams regarding what they contribute (like at
Eclipse), as opposed to using a centralized model. Works just as fine
Powered by FUDForum
. Page generated in 0.11117 seconds