Community
Participate
Working Groups
Target platform files could define a targetJRE to use, but tycho currently ignores this. Instead custom configuration[1] must be performed. [1] https://wiki.eclipse.org/Tycho/Execution_Environments#Execution_environment_configuration
New Gerrit change created: https://git.eclipse.org/r/c/tycho/org.eclipse.tycho/+/165963
Do I get it right that we want the lower targetJRE from all .target files be 2nd highest priority after target-platform-configuration/executionEnvironment ?
That was my intention.
I think each target-file should be resolved against it's targetJRE.
(In reply to Christoph Laeubrich from comment #4) > I think each target-file should be resolved against it's targetJRE. The EE is assigned to the project, not to the target file. We cannot really change that without a major and risky refactoring, for a value that's still unclear. And actually, this would probably be incorrect as at runtime, there is only one executionEnvironment and we resolve only against this one. Resolving the target definition content against different JREs may lead to some cases that are working at build-time, but actually leading to not installable situation at runtime. We want to avoid that, we want such resolution errors to surface in the build tool.
But that's the whole purpose of a "Target" you define the Environment a bundle will later run against so if the target specifies a Java8 and your bundle is specify Java11 then this simply means you bundle can't successfully resolve against that target and that could be cached at build time. As Tycho support multiple targets, there might be one that better fits that needs, but the target itself should not resolved against java11 just because the bundle requires it. Beside that, the run time-correctnes can never be checked by the build, especially as there is no "run time-correctnes" in OSGi, its allowed to install bundles with unmet requirements, the simply won't resolve then until all requirements are meet.
(In reply to Christoph Laeubrich from comment #6) > But that's the whole purpose of a "Target" you define the Environment a > bundle will later run against so if the target specifies a Java8 and your > bundle is specify Java11 then this simply means you bundle can't > successfully resolve against that target and that could be cached at build > time. I don't think that targetJRE in .target file is actually a compatibility constraint. It's more a form of recommendation; but a bundle that requires Java 11 could totally be compiled and work against a target that uses Java 8; and vice-versa. So I wouldn't build much more semantic on this targetJRE than making just a hint of whats the EE to resolve againsr. > As Tycho support multiple targets, there might be one that better fits that > needs, but the target itself should not resolved against java11 just because > the bundle requires it. Agreed, and it's actually what's implemented and I don't plan to change it by the way: the execution environment (coming for <executionEnvironment> or targetJRE) takes control of what to resolve against with higher priority than the BREE or other stuff. > Beside that, the run time-correctnes can never be checked by the build, > especially as there is no "run time-correctnes" in OSGi, its allowed to > install bundles with unmet requirements, the simply won't resolve then until > all requirements are meet. I mean more install-time correctness then, ie see at build-time the error that will show up at install-time. For the case of multiple different targetJRE, there is no equivalent at install-time, as we're running only 1 Java version at once.
Gerrit change https://git.eclipse.org/r/c/tycho/org.eclipse.tycho/+/165963 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=cfa578328eb7ce47be75d8aaa3d3102c8693f77b
A note was added to https://wiki.eclipse.org/Tycho/Release_Notes/2.0#targetJRE_in_referenced_target-definition_file_is_used_to_derive_Execution_Environment
The target jre is not a recommendation, the target defines the environment the bundle later should run/install against, so if the target specify java8 and you simply ignore this, your bundle won't be able to run/install into this target. That Tycho supports more than one target is an extension that can't be resolved consistently, on bundle can only have one (active) target. Anyways it seems I might have to wait for Tycho 3.0 then :-)
I think the current (master) state is totally compatible with your approach in case of singe .target: if using a single .target file with targetJRE set and EE isn't overridden otherwise, this targetJRE will be used as EE. It seems to me the only unclear case is what to do when using mulitple targets. Currently it will just pick the 1st targetJRE available. We can try to decide and implement clear and improved rules for this case, but this doesn't seem like a major issue at the moment (FWIW, the adoption of Java 11 in Platform is what has motivated most of Alex's and my work on Tycho lately; and the multi-target cases isn't really in our scope). What are the specific use-cases you think current approach cannot cover correctly enough? Are they frequent? The only important rule is that we 1st assign the EE to the project, and then resolve dependencies for this project using all targets and against this chosen EE, independtly of their targetJRE. That allows to validate that a mix of target files using targetJRE=JavaSE-1.8 and targetJRE=JavaSE-11 can be provisioned together against the chosen EE and satisfies requirements; if we do resolve them separately, we bring inconsistencies as they may behave differently when resolved separately compared to resolved together. I think what you have in mind with ensure .target consistencies against their own targetJRE is more a topic to improve in the target-platform-validation-mojo when building the eclipse-target-definition project. > Anyways it seems I might have to wait for Tycho 3.0 then :-) All that said, there is no need to wait for Tycho 3.0 to improve things if you see an opportunity.
I don't know the use-cases for multiple targets, so I can't really judge if the still apply, but the inconsistencies I see with this approach are the same that applies to the Update-Sites itself: If you add multiple Updatesites to a target, all of them must share some properties (e.g. the slicer vs planner mode). So for multiple targets support I think the same must apply: All targets mush share the same targetJRE. Anyways its unclear how a build really should behave... in the past a target was simply a collection of URLs to query to resolve dependencies and then there is no problem, but if you take the idea of a target into account (assume I have one target for a karaf-container instance and one for an eclipse-ide) problems arise: - should targets be merged? That would mean the bundle could possibly neither run in one or the other "world" because it would need bundles from both "worlds" - should only the intersection of targets taken into account? hat would mean that both targets must share some common state so a bundle can run in both "worlds", but that might leads to a state where we can't resolve the requirements - should one of many be selected? That means that the bundle could at least run in one of the offered worlds So I do not have hard requirement or use-case to present here, just trying to make tycho use the target as the "source-of-truth" as its handled in PDE, so if one develops in IDE behaves the same as running the tycho build and there is no need to configure things in two places (pom+target).
(In reply to Christoph Laeubrich from comment #12) > make tycho use the target as the "source-of-truth" as its handled in PDE, > so if one develops in IDE behaves the same as running the tycho build and > there is no need to configure things in two places (pom+target). I think Tycho is now consistent with PDE on that topic (ignoring the strange case of mulitple targets). Is there something you think is still missing?
