Usage of filters in Tycho + PDE

[laeubi]

Tycho supports a very generic filtering mechanism (what is not supported by PDE):

https://www.eclipse.org/tycho/sitedocs/target-platform-configuration/target-platform-configuration-mojo.html#filters

while PDE only supports a White-List in the target (that is currently not supported by Tycho).

I wonder if we should take some actions to unify this:

• Tycho could support the PDE-Target-White-List, this is actually only a negated <filter> of type eclipse-plugin (exclude everything except ...) with more than one plugin in the list.
• PDE could support the filter syntax of Tycho up to the point that it uses the exclusion when deselect (black-listing) a plugin simply keep everything it does not understand as an additional <filters> element in regular target files.

That would prevent people of define duplicate entries and further allow to have less configuration in the pom.

For that I would like to gather some feedback of people actually using that feature

1. Is it used at all, I have only used it in very rare case, on a regular basis or is it really just some last resort to get some strange combination/configurations fixed?
2. What of all that fancy Tycho stuff is actually used? Would this be required on PDE too or are these Tycho specific cases?
3. Is the syntax quite clear and user-friendly or would one need tome user assistance/ui to work with filters beside the select/deselect stuff?
4. ...

[Bananeweizen]

I use Tycho target platform filters a lot, and that's the reasoning:

• I want to reference existing features in my features as far as possible. Referring to bundles only would easily break my product, if a new version of an eclipse.org bundle suddenly has a new dependency, which is included in its new feature version.
• Unfortunately many eclipse.org features have some dependencies, that are very much unwanted in a non Java IDE product, but the developers typically don't notice, because they just use the whole eclipse update site as target platform. To avoid that our developers use those dependencies in our code too, our builds/tests are launched with as many filters as possible.
• Over time it also happens that Eclipse projects which have an IDE lifecycle and a runtime lifecycle (like Xtext) start mixing their dependencies and you get the IDE stuff into the final product.
• Besides that, there are corner cases like conflicting versions of bundles (JNA anyone?), bundles depending on unwanted Java versions (jdt.annotations versions 1.x for Java 7), patched bundles (jdt from ObjectTeams) etc.

So what is excluded in some typical filters that I configure?

• jdt (as far as possible)
• emf.examples and further example bundles
• jgit (comes with Yakindu SCT)
• xtext.xbase (Xtext internally uses Xbase, and exposes that dependency)
• *.sdk bundles (if I cannot exclude their SDK feature from the target)
• old versions of third party dependencies, where newer ones are available (think Apache Commons xyz)

Basically we include too much by creating a feature based product, and try to counter that by filters for the target platform (at least for the compile and test phase).

[buchen]

Just to chime in: my primary use of filters is to reduce the number of warnings when including Babel features in the build. The Babel features are cut very broad and include translations for many plugins that I do not include in the build. Therefore I get miles and miles of warnings messages about unsatisfied dependencies.

(to put it into perspective: I just counted 130 warnings only for one plugin with tycho version 4.0.2 - the reason being 14 languages and a couple of modules + target resolution which each print the warnings)