| Re: [cbi-dev] Procedure to deploy to download.eclipse.org |
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.org > Le 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature