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.
Some minor comments on some of your
other points (which would be better to have in a bugzilla on the topic
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".
= = = = = = = = = = =
Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> To:
07/21/2016 10:52 AM Subject:
Best practices for setting p2.mirrorsURL? (long) Sent by:
> 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"
+ 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.
Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 _______________________________________________ cbi-dev mailing list cbi-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/cbi-dev