On 03/15/2012 09:31 AM, Nick Boldt wrote:
TODAY:
.target files list all the IUs (feature and plugin) and the "target
platform sites" are generated from that listing via XSLT transform to
p2.mirror script (uses: maven, ant, xslt). Ant script also provides
round-tripping in that the generated site is used to update the .target
files w/ the new versions of IUs.
FUTURE:
.target files list only top-level "virtual" features, which can be
maintained w/ no effort - file never changes unless the URL of the TP
site changes (eg., moving from SR0 to SR1 to SR2) or new "virtual"
features need to be added (eg., new collections of features added when a
new component is added or a new dependency stack is needed, like when we
had to add git).
Would that work if we have target platform for tycho defined with
.target file (with versions) and eclipse-repository project that defines
features (w/o versions) to be collected in category.xml. Even better to
have not just p2repo build, but product build which can be consumed by
QA for testing.
"target platform sites" are generated using feature.xml + nearly empty
site.xml to define the collections of features/plugins for the site.
Maintenance can be done the same way that other component / aggregate
sites are done AND we introduce the notion of "ranges of supported IUs"
AND the idea of being able to combine smaller mini-TPs into larger ones,
rather than just having one big TP for JBT and another for JBDS.
N
On 03/15/2012 12:22 PM, Max Rydahl Andersen wrote:
> Okey, so after reading/hearing about all the concerns I think i might have an
answer.
>
> Nick/Mistria's concern is that they want to build updatesites easily and claim
> building it from .target file is too much overhead, but i'm not sure why that
is.
>
> My guess is the format of the file is problematic or !?
>
> But afaik they want to build from feature+site.xml instead.
>
> And Denis/Rob/Me would like to have a .target file for various reasons
(deterministic,
> reproducibility and ease of use for target platform in PDE).
>
>
> Thus my suggestion is:
>
> 1) feature/site.xml is used for building the TP updatesites AND for creating matching
.target file.
>
> 2) This .target file gets committed and version into what is today called
targetplatform (if multiple target platforms it should be release under different
name/versions)
>
> Now both sides are happy.
>
> Only two concerns I can see right now is:
>
> A) #1 above must not result in additional "virtual" features being present
in the updatesites - whatever features used to define the TP is purely an implementation
detail. Is that doable?
>
> B) the feature.xml/site.xml is just an ease of use - the .target file used in #2 is
still the thing that should be used for limiting the versions so p2/tycho is
deterministic.
>
> Makes sense?
>
> Complaints/other ideas?
>
> /max
>