On 03/15/2012 09:39 AM, Rob Cernich wrote:
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).
This step needs only SDK installed and target platform provides all
requirements to compile against. But in current state if you also need
sources, it is DIY.
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
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev