I'll just clarify my requirements/use case, just so there's
no ambiguity:
1. Install Eclipse (plugin development, JEE, classic, whatever; knowing I need PDE).
2. Set target platform.
3. Check out a JBT project (e.g. m2e)
4. It compiles.
5. I can run and debug.
Yep I get these - I just want that #4 is not just "it compiles" its "it
compiles against a known controlled set of deps"
/max
Currently, step 4 fails because the target does not include JBoss
features/plugins. Setting up a manual target fails because test plugins do not reside in
a repository.
These have all been discussed at length. I just wanted to summarize my wants (obviously,
there is no need since I'm already developing :) ).
Best,
Rob
----- Original Message -----
> 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
>