If that code could be easily integrated into a maven-plugin, that would be nice. However, we publish all but the release update sites from the build server. In that case a simple parameterized script added as post build step to hudson would suffice I think (in my case). Is the tool already installed on build.eclipse.org somewhere? I guess some project (WTP?) is already using it, right? Maybe it makes sense to put it on /shared (or whatever conventions exist) and document how to integrate this on a wiki page?
I'd give it try and document it. On 06.03.2012, at 19:10, David M Williams wrote: > > I think your eyes glazed over reading my original note before you got to > the part where I said there is already such a tool. See > > http://wiki.eclipse.org/WTP/Releng/Tools/addRepoProperties > > Feel free to use/copy that as you'd like. > > The advantage of having a "stand-alone app" or tool (not only as "part of a > build") is that is allows you to change the properties after the repo is > created, as is sometimes required, after moving or mirroring the repo > elsewhere. > > Good luck, > > > > > > From: Jesse McConnell <jesse.mcconn...@gmail.com> > To: Cross project issues <cross-project-issues-dev@eclipse.org>, > Date: 03/06/2012 12:38 PM > Subject: Re: [cross-project-issues-dev] p2 repositories ... we can do > better > Sent by: cross-project-issues-dev-boun...@eclipse.org > > > > Not sure for tycho but given some time I could have that in the > signing plugin in an hour or so I would think. > > I'll see if I can scrape some time together to get that support added > in, at least in the interm until tycho could support it > > cheers, > jesse > > -- > jesse mcconnell > jesse.mcconn...@gmail.com > > > > On Tue, Mar 6, 2012 at 11:25, Marcel Bruch <br...@cs.tu-darmstadt.de> > wrote: >> On 06.03.2012, at 13:04, Jesse McConnell wrote: >> >>>> could the eclipse-signing-maven-plugin provide a parameter to >>>> inject the p2.mirrorsURL property into artifact repositories and >>>> parameters to generate the p2.index file ? >>> >>> can you give me a specific example of what that xml (assuming that >>> would be in some of the xml metadata) would look like? >> >> = Support for p2.mirrorsURL = >> >> According to http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL just add: >> >> <property name="p2.mirrorsURL" value=" > http://www.eclipse.org/downloads/download.php?file= > {repository_path}&format=xml"/> >> >> Since webmaster thinks that we have been hit by this issue recently ( > https://bugs.eclipse.org/bugs/show_bug.cgi?id=373352) this makes me think > even more about how to integrate this into our builds. As last means of > resort I'll write a bash script that unzips artifacs.jar, adds the property > to the artifacts.xml, and zips the file again. >> >> But I wonder how much effort it takes to add this in Tycho's > eclipse-repository packaging since tycho generates these files? >> It wouldn't be specify to Eclipse; just a generic support for properties > - I think. >> >> >> = Adding support for p2.index = >> >> The file looks like this: >> >> version = 1 >> metadata.repository.factory.order = compositeContent.xml,\! >> artifact.repository.factory.order = compositeArtifacts.xml,\! >> >> Whether it's "xml" or "jar" should depend on the "compress" property we > already specify in the eclipse-repository. >> >> >> = Enabling download stat in your repository = >> >> And if we are already on defining properties: to enable download stats > it's... >> >> ...for artifacts.xml/repository: >> <property name='p2.statsURI' value='http://your.stats.server/stats'/> >> >> ...for bundles: >> <property name='download.stats' value='test.plugin1.bundle'/> >> >> http://wiki.eclipse.org/Equinox_p2_download_stats >> >> >> >> >> So, in theory it's just adding properties and looks from outside like a > simple thing to do. But how long it takes to implement it - at least the > p2.mirrorsURL feature - I've no idea. But maybe a tycho committer knows > better? >> >> >>> I suspect is >>> possible but I also think it is probably more appropriate to have that >>> support in tycho >>> >>> the signing plugin is really just a hack to support this aspect of the >>> eclipse requirements that is outside of the traditional tycho >>> workflow...having said that we can always put another hack or two into >>> it :) >>> >>> cheers, >>> jesse >>> >>> >>>> -- >>>> Matthias >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> Thanks, >> Marcel >> >> -- >> Eclipse Code Recommenders: >> w www.eclipse.org/recommenders >> tw www.twitter.com/marcelbruch >> g+ www.gplus.to/marcelbruch >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev Thanks, Marcel -- Eclipse Code Recommenders: w www.eclipse.org/recommenders tw www.twitter.com/marcelbruch g+ www.gplus.to/marcelbruch _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
