Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] setting mirror URL in the p2 repository

Hi Andreas

Thank you for the feedback!
Based on your suggestions, I followed a slightly different strategy that
allows me to get everything done (see the small example here:

- have tycho generate both artifacts.jar and .xml.xz
- use to add the properties in
- uncompress artifacts.jar into artifacts.xml
- use xz to overwrite artifacts.xml.xz with the new packed artifacts.xml
- remove artifact.xml

This will get you all the compressed stuff (with added properties) and
the p2.index.

Does it make sense?


On 18/11/2016 14:25, Andreas Sewe wrote:
> Hi Lorenzo,
>> as suggested here
>> we set the mirror property in our artifacts.jar when releasing.
>> We do that by using
>> as done in other projects, e.g., 
>>  this has worked up to now, but after we moved to tycho 0.25, which
>> also generates the .xml.xz zipped version, we noted that the mirror
>> property is not set in the artifacts.xml.xz (but only in
>> artifacts.jar).
>> Would mirroring still work?
> No, if you follow our template (I wrote the Code Recommenders pom.xml)
> then mirroring will not work when the client downloads the
> artifacts.xml.xz. This is Code Recommenders' Bug 497546 [1].
> Now, for us fixing this has rather low priority, as not many people
> download Code Recommenders from its update site, now that it is included
> out-of-the-box in many EPP packages. But your mileage may vary, of course.
> For you I see 3 ways out:
> 1. Disable XZ compresison in the tycho-p2-repository-plugin and compress
> in a separate step, after the tycho-eclipserun-plugin with
> has finished. Maybe the
> truezip-maven-plugin [3] or a similar plugin can help here.
> 2. Push for Tycho Bug 341744 [4] being fixed in such a way that it does
> not only support p2.statsURI but also p2.mirrorsURL.
> 3. Do not set the p2.mirrorsURL in the Tycho build at all, but only when
> promoting it to its final resting place. See Bug 498360 [5].
> Option 1 certainly requires the most work, but has the advantage that it
> just might work right *now*. In the long run, however, I think option 3
> is preferable. The build should *not* need to know where the repository
> bits will be offered for download, in particular as this may change over
> time, e.g., if you move things from to
> Hope that helps.
> Andreas
> [1] <>
> [2]
> <>
> [3] <>
> [4] <>
> [5] <>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
Xtext Book:

Back to the top