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