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

[Nick Boldt]

These "virtual" features are simply wrappers for other features & 
plugins. You wanted a way to install things from Eclipse's Orbit repos 
which aren't contained in features, such as jsch. This is the way to do 
that, without having to worry about writing arcane (and potentially 
non-portable) p2.inf scripts. Anyone can understand a site.xml or a 
feature.xml file. p2.inf is largely undocumented and the examples I've 
found in the wild are way more obscure than feature.xml and site.xml, of 
which we already have dozen of working examples.

I don't see that having these extra features installed contributes 
anything to a user or developer's install base except ease of use. And, 
in fact, the added benefit is that when we move from one TP to another, 
we control what gets installed into developers' workspaces, in the same 
way that a JBDS user ONLY gets what we define in the product file.

Rather than just updating to a new m2e or wtp base, they get EXACTLY 
what the feature allows them to install. We can say that wtp 3.3.x is 
permitted, or that only 3.3.2 is permitted. Features allow this control 
& flexibility (ranges or exact versions). Target files do not.

If you define "deterministic" like this [1], then features are in fact 
deterministic IFF they are properly configured to describe the explicit 
versions of their contained IUs.

[1] http://en.wikipedia.org/wiki/Deterministic_system

I'm only suggesting than an extra level of abstraction between the 
target file and the resulting update site would allow us MORE control, 
flexibility, and end-user / developer ease-of-use.

I don't believe in any way that this new level of abstraction adds or 
removes any of the existing determinism / randomness / control that's 
ALREADY present in the system. The reason for this is that we already 
depend on upstream projects whose features & plugins may or may not be 
properly configured to allow a disparity of versions when producing the 
target platform site or resolving a .target file as a collection of IUs 
on disk (using Eclipse's internal processes rather than an explicit 
p2.mirror script or a Tycho build of a site.xml/pom.xml couplet). We 
can't control their features & plugins, but we can control how we 
collect them into a site.

So, no, "virtual" features are NOT pointless. As I've now said about 3 
times, they allow us to support TPs with ranges of compatible features, 
multiple/combined TPs, and to install featureless plugins such as those 
in Orbit. These are all benefits.

There are no drawbacks that I can see, especially considering that if 
you uncheck the 'group by category' box when installing the TP site into 
your Eclipse via p2, you could cherry-pick which features you wanted 
rather than installing the whole thing via the single top-level 
"virtual" feature. That would still provide you a compatible development 
platform against which to build plugins, without the WHOLE thing being 
installed. Add to that the offline nature of a TP site (vs. the online 
nature of a .target file) and you get another win -- being able to 
install everything into your dev environment while on a train or other 
wifi-less place on the planet.

Have I crushed all your objections yet, or do you have more? :D

On 03/15/2012 12:39 PM, Max Rydahl Andersen 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).
>
> Target files with "virtual" features" means I would get these 'virtual' features installed - no way to avoid that  ? these does not exist for users so should not be in the tests.
>
> And if the target files just list virtual features they are just as non-deterministic as using features and thus rather pointless aren't they :)
>
> /max
>

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