Additional "runtime" scoped dependencies support?

[laeubi]

Now that we correctly filter dependencies scopes it shows that it might cause confusion for runtime scoped dependencies.

The runtime scope is a bit special as maven defines it as:

runtime
This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope in the runtime and test classpaths, but not the compile classpath.

That mean that if we want it currently one has to select test scope.

I see the following options:

1. We allow to select runtime scope and handle it as something between compile and test (include everything compile would include and include runtime dependencies but not test scoped ones.
2. We add a boolean attribute includeRuntime that additionally include runtime scoped dependencies
3. We do nothing an require people to explicitly include those if the only want compile scope

@akurtakov @mickaelistria @HannesWell any preferences?

[akurtakov]

Option 1 sounds best to me as it's clear mapping to Maven concepts thus will match expectations better than extra attribute or manually add dependencies.

[HannesWell]

Thats not really much work beside a loop and a split... so I think we can afford this for some extra convenience :-)

Sounds reasonable :)

although this is not always easy due to the different concepts/approaches of OSGi and Maven.

Its actually PDE/JDT to blame here to not understand the scopes of bundles in a more fine grained manner.

I've skimmed the PDE bug you mentioned earlier. And what I'm definitely planning to propose for PDE to not add test fragments in launched Eclipse/Equinox applications when automatic addition of dependencies is requested. The descension if a fragment is a test fragment probably requires some heuristics (based on the name or if the classpath elements are marked as tests). If a fragment could be marked as tests explicitly it would definitely help in this regard.
However I'm not sure if scopes like in Maven would be more helpful in general, but I'm also not sure if it were not helpful. My impression for PDE target-platforms is that you throw in all the stuff you (could) need and each plug-in picks what it really wants. And if the approach to place tests in dedicated test-fragments is used, unlike a Maven-Project, an Eclipse plugin does not need scoped dependencies to not pollute the 'main' bundle with tests and test-dependencies. But this is actually not the scope of this discussion.

[laeubi]

And what I'm definitely planning to propose for PDE to not add test fragments in launched Eclipse/Equinox applications when automatic addition of dependencies is requested. The descension if a fragment is a test fragment probably requires some heuristics (based on the name or if the classpath elements are marked as tests).

Please don't do that, there is no such thing as "test-fragment"s this is just a workaround that is claimed to be "best-practice" due to PDE limitations and any heuristics might sooner or later fail.
Sadly PDE is not open to make things more usable see Bug 572627, Bug 572520 and Bug 572743.

If you are still eager to do that, the only valid measure I think is a plugin (either fragment or bundle) that has only test marked source folders.

My impression for PDE target-platforms is that you throw in all the stuff you (could) need and each plug-in picks what it really wants

Sure but good decisions can only be taken by good meta-data. The target platform actually has the concept of bundle versus source (but actually do not use this information later on consequently), so this could be at least enhanced to test scoped as well (and at the maven level we have this information!) or even generic "scopes" (don't need to match the maven scope but could be compile, test, source for example).

In the end I think we do not need a 1:1 match but something that is understandable to the user.

[HannesWell]

Please don't do that, there is no such thing as "test-fragment"s this is just a workaround that is claimed to be "best-practice" due to PDE limitations

Not automatically including "test-fragments" into Eclipse/Equinox Applications and even Plug-in tests is IMHO important, because such fragments can pollute the launched Runtime for example with extensions or other resources that are not present in a regular Maven/Tycho build application. It could even cause interference of "test-fragments" (if all were added automatically).

and any heuristics might sooner or later fail. Sadly PDE is not open to make things more usable see Bug 572627, Bug 572520 and Bug 572743.

If you are still eager to do that, the only valid measure I think is a plugin (either fragment or bundle) that has only test marked source folders.

I have the same concerns as you have regarding a heuristic only based on the fragment-name and came up with exactly that criteria (as I tried to state in my previous comment).
"Test-bundles" are not a problem in the scenario of filtering automatically added bundles, because they are not required by the "main" application bundles. The problem are only test-fragements because a.t.m. PDE adds all fragments when you add required plug-ins for a launch.
But I will open a dedicated PDE bug for this and will notify you so you can join in if you want. :)

In the end I think we do not need a 1:1 match but something that is understandable to the user.

That's right. Understandably is IMHO very important.

[laeubi]

because such fragments can pollute the launched Runtime for example with extensions or other resources that are not present in a regular Maven/Tycho build application.

They already "pollute" your ecosystem as they are actually not necessary in many, many cases ;-)

The problem are only test-fragements because a.t.m. PDE adds all fragments when you add required plug-ins for a launch

This is not only problematic for so called "test-fragments" I think fragments should never be added unless explicitly enabled.

I will open a dedicated PDE bug for this and will notify you so you can join in if you want

I probably will leave a comment, but contributing to PDE itself has been very frustrating in the past so don't expect too much from my side here.

[HannesWell]

The problem are only test-fragements because a.t.m. PDE adds all fragments when you add required plug-ins for a launch

This is not only problematic for so called "test-fragments" I think fragments should never be added unless explicitly enabled.
Some fragments are unfortunately necessary for example the org.eclipse.osgi.compatibility.state (even tough this could change in the future) or some for ssh/https support IIRC, so it is actually bad to include all but also to include none.

I will open a dedicated PDE bug for this and will notify you so you can join in if you want

I probably will leave a comment, but contributing to PDE itself has been very frustrating in the past so don't expect too much from my side here.

That's fine for me, I just wanted to let you know :)

[laeubi]

If no more suggestion I would then go ahead and add runtime as a new value that includes everything from compile + runtime but not provided.
Additional I would extend the attribute to support a comma separated list so that more than one scope could be included, I think this is the most flexible and also backward compatible.