Alexander ,
So I have downloaded your publish.sh script.
I have made two small modifications to be compliant with our own product (mainly the url ) .
The script of Alexander is really good and do the job perfectly. (at least locally for test)
Script here :
https://git.eclipse.org/r/#/c/59473/ ; pending review
I have still a question regardling Camille post.
If I create a job that will process the script as second task, how can I setup the permissions to be sure the script could write to the downloads area?
Do I need to ask for the creation of a specific user with those rights for a specific directory?
Francois
-----Message d'origine-----
De :
cbi-dev-bounces@xxxxxxxxxxx [
mailto:cbi-dev-bounces@xxxxxxxxxxx] De la part de Mikael Barbero
Envoyé : mardi 27 octobre 2015 15:15
À : Common-build Developers discussion <
cbi-dev@xxxxxxxxxxx>
Objet : Re: [cbi-dev] Procedure to deploy to
download.eclipse.orgLe 27 oct. 2015 à 14:41, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> a écrit :
Mikael Barbero wrote:
I think much of this can be tackled by Maven plugins during the
build already. I can very well imagine
tycho-p2-repository:archive-repository
learning to compress the update site with zx as well.
Of course. We have to weight what has to be done on the client side and on the server side. However, for things that we want to enforce, I think this is much easier to do it on the server side.
Same thing goes for mirror and stats URIs.
Yes, on the server side we can implement some checks and reject repos
that don't meet the criteria instead of doing the actual work.
However, I think that everybody will more than happy if the server
does most of the hurdle and they don't have to change their build to
do it. Moreover, improvements on the server side are much easier to
deploy than to convince everybody to use a new version of a Maven
plugin ;)
Implementing the checks on the server (web-service) side and rejecting
if the quality criteria (no mirror URIs, no index.html, whatever) are
not met sounds reasonable.
I would just prefer if much of the actual metadata would be filled in
on the client/build side, not by the server/publisher. In particular,
this makes it much easier to test things locally; just look at the
artifacts.xml and check whether the stats URI is set, for example.
Also, you would not need to pass so many arguments to the publisher
server (like stats URI, mirror URI, project description). All that
IMHO should be required is the desired location on download.eclipse.org.
I envision this to be a bit like Maven Central. You upload your
JAR+POM, it gets checked, and then published at a certain location of
all quality criteria are met.
In fact, I think Tycho by default already produces the perfect
artifact to upload to a publishing web service: the zipped update site.
What do you think?
Sounds reasonable to me. However, for some items like the index.html, I still see a real added value for the community if the service generate a default one when missing.
Cheers,
Mikael
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev
