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

[Max Rydahl Andersen]

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

No - that is not the way to do that. its the way to ensure more incompatible/different installs.

> without having to worry about writing arcane (and potentially non-portable) p2.inf scripts.

non-portable ? How so?

I agree p2.inf are arcane but I don't know of any other option that does not have a sideeffect onto users installations.

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

Yes, site.xml are fine and simple. Feature's changes the way p2 resolves things. Thus making virtual features sounds like a maintanence nightmare to me.

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

It would cause conflicts when EPP feature is in conflict with the virtual feature - sometimes you want that, but that is what a target/p2.inf file would be able to cope with - in features it has sideffects.
 
> 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.

eh? target files aren't supposed to be for "ranged installs".

.target files are for *exact installs*.

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

As long as those features does not end up in my installation then I agree this is fine - but they do don't they ?

For me feature.xml + .target sounds like the best option (assuming virtual feature's can be avoided since we need to work with rest of eclipse eco system). 

Allows ease of install but still explicit control what is actually built.

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

yes - the current system is not using the .target file when it should. That's the problem IMO.

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

not following you - so you are saying moving to this new way has no benefits for our build since the current build is equally nondeterministic ?

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

so when I install this feature I won't see any "can only install one of the following plugins" ? 

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

This is what I would prefer afaik and what .target allows.

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

No idea why you think a .target file needs to be online !?

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

No - you have convinced me even more that virtual features will cause damage since either they do get installed into users installations and will be different what they install into or they get into dev machines and they will be different from what users see.

I honestly think you are not understanding why I ask for the .target file to begin with.

.target != feature.

.target is something you apply to a set of updates which are defined via features/plugins to get the exact set of dependencies you want for your build and your target platform.

Only using a feature + updatesites you don't have that control.

The control you talk about requires devs and users to *not* use multiple updatesites, mirrors or any other change to the updatesites which are all things that does happen, naturally and accidentally.

/max