[jbosstools-dev] Who uses .target file? Alternative suggestion

Nick Boldt nboldt at redhat.com
Thu Mar 15 12:31:49 EDT 2012


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).

"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
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com


More information about the jbosstools-dev mailing list