[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Best practices for setting p2.mirrorsURL? (long)

I could imagine this being implemented in more than one way so that people could make use of it in different ways (depending on their use-case and workflow). (Similar to how the "jar signing service" is implemented in different ways).

The typical way that "enhancement requests" are done is that first the enhancement request is opened and documented in a conceptual way, independent of implementation.

And *then* various implementations discussed (or, just done :) via the bugzilla entry. And, if you are doing the work, you can do it how ever you would like, and what is best for you.
Yes, ideally it could be useful to others, but you will never satisfy everyone, so the best you can do it try and make things out of reusable components, or pieces of code, to the extent possible. So perhaps (for example) some core pieces of Java code could that could be used in Maven and, say, an Eclipse Application.  

And, if you are looking for any advice (i.e. just my opinion) often the "quickest and simplest" approach is best for initial implementation and then later improve it with "lessons learned" from that approach.

= = = = = = = = = = =

FYI: if it helps anyone,  a bash script to recreate the xz files is at
It is sort of complicated, but tries to do a fair amount of error and sanity checking -- there are lots of different "types" of p2 repo sites! -- and it still isn't perfect.
So if nothing else, it might help just to read it, even if eventually implemented in some other way.

= = = = = = = = = = =

Some minor comments on some of your other points (which would be better to have in a bugzilla on the topic :)

"....that is installed on all HIPPs ...."
This is probably not desirable or realistic.  You would either want it accessible from a "shared" location, such as somewhere in /shared/common where most HIPPs you get access to it, or downloadable from a repository.

"1. Make a working copy of the p2 repo"
I am not sure this is necessary. I might be, but best to avoid "extra copies" if possible.
Also may depend if the tool offers a both a "copy" and a "move" action.

Don't forget, besides the p2.mirror value, there are other values that users may wish to change based on "promotion" -- such as the repos name and the "stats" values -- that is, all the things in the WTP Tool :)

Roland suggested to using "XSLT" to make the changes -- and LOTS of people successfully do that and have for many years, But my advice is to use the p2 APIs if possible. I am sort of old school but after all the XML format is not "guaranteed".

= = = = = = = = = = =


From:        Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
To:        cbi-dev@xxxxxxxxxxx,
Date:        07/21/2016 10:52 AM
Subject:        Re: [cbi-dev] Best practices for setting p2.mirrorsURL? (long)
Sent by:        cbi-dev-bounces@xxxxxxxxxxx

Hi David,

> I don't have a tool "magic-copy" (but, it is a good idea :) but agree
> with you that "promotion" it the right time to set the p2.mirrorsURL
> because we too "move them around" without rebuilding.  
> What I do is use the org.eclipse.wtp.releng.tools.addRepoPropertiesto
> modify the value,
> then just recreate the xz version of contents.jar using a small bash
> file and the native xz Linux support.

Yes, that would be the necessary steps:

1. Make a working copy of the p2 repo
2. Add a p2.mirrorsURL
3. Create the XZ compressed files again
4. Copy the p2 repo to its final location

> I can't say I'd have time to work on it any time soon, but a "move
> repository" function seems worth a CBI feature request.

Before I file a feature request I'd like to figure out exactly what tool
exactly would perform the above steps.

I can imagine several implementations, each with their pro's and con's:

1. An executable (implemented in whatever) that is installed on all
HIPPs and that you can execute in your Hudson "Execute Shell" actions

 + Easiest implementation
 - Not useable outside of Eclipse-owned HIPPs

2. A Maven plugin

 + Automagically downloads all its dependencies
 + Configuration managed in POM (and hence in Git)
 - Useless to projects no using Maven

3. A Jenkins/Hudson action plugin

 + Tightest integration into Hudson promotion

What would your preference be?

Personally, I would be able to lend assistance in implementing 2., as
Maven is what I have the most experience with.

Best wishes,


Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
cbi-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit