Community
Participate
Working Groups
Depending on the execution environment (J2SE-1.5, JavaSE-1.6, etc.), Equinox defines the list of packages exported by the system bundle. Since Java doesn't define package versions, it is unclear in which versions these packages shall be exported. Equinox has chosen a defensive approach and exports the packages in version 0.0.0. However there are also exporters of packages which nowadays are part of the JRE, which export these packages in versions greater than zero (e.g. wrappers in the Springsource EBR). Therefore, OSGi servers may want to define other versions for the system packages as the Equinox default. Tycho should support this use case. It should allow configuring the system package version (e.g. via Equinox .profile files) so that versioned JRE package imports may be wired against the system bundle at class path computation and test execution, and that bundles with versioned JRE package imports can be installed (without unneeded wrapper bundles).
(In reply to bug 385703 comment #8) > * For downstream projects consuming the custom profile, allow switching off > tycho's a.jre.* IU filtering (but keep the default to filterJREIUs=true) > This way we avoid having to introduce a new packaging type for custom profiles > and having to worry about how to distribute/reference it. We tried this out, but this isn't enough [1]. The p2 resolver would be happy, but the Equinox resolver (for build class path computation) would fail because it doesn't know how to wire the versioned javax.annotation import. [1] https://github.com/oberlies/tycho/commit/4fd23296f6d261cd205ea953464e9e5fbd6a5a0b
Do you know what happens at runtime if both java profile and installed bundles export the same packages? Does equinox pick classes from the JRE or from the bundles? Somehow I thought Equinox always used JRE classes in this case, but I am not sure.
(In reply to comment #2) > Do you know what happens at runtime if both java profile and installed bundles > export the same packages? Does equinox pick classes from the JRE or from the > bundles? Somehow I thought Equinox always used JRE classes in this case, but I > am not sure. Equinox may wire to either, but it prefers wiring to the system bundle (although that bundle typically exports a lower version). This behaviour is a deviation from the OSGi standard, and it can be disabled with -Dosgi.resolver.preferSystemPackages=false. (I once spent a day trying to understand the system package mess, and wrote a blog about it [1].) [1] http://toberlies.blogspot.de/2010/09/osgi-equinox-and-missing-package.html
So the consequence from the trials in comment #1 is that we need to tell the Equinox resolver about the system packages (incl. versions) from the custom profile. Assuming that the custom profile has been published into a p2 repository using the product publisher application and the new switch from bug 334519, we might reverse-engineer the system packages from the "a.jre" IU. In this way, we wouldn't need any extension to the existing p2 concepts (as originally proposed in bug 385703 comment #5).
To make sure I understand your proposal, you want to publish both custom profile definition IU and corresponding jar file artifacts to p2 repository. Did I get this right?
The use case doesn't involve any jar files. Here, the assumption was that the profile only includes packages which are contained in the JDK, so that for compilation and test execution, the JDK (physically) provides all the packages that are (logically) defined in the profile. (So the custom profile may only add package versions compared to the standard profiles.) So since we only need a list of packages & versions in order to fully define such a custom profile, the profile could be published into a p2 repository (using the existing JREAction) and distributed in that way to downstream Tycho builds.
Please provide an example project to illustrate this usecase. I am particularly interested to understand the need to version packages provided by JRE.
I pushed an example project to Gerrit (with a couple of workarounds to simulate some of the missing implementation) [1]. The motivation for versioning the JRE is explained in comment #0: There are bundles out there that import packages that are present in the JDK 1.6, but these imports are not matched against the JDK (at build time, respectively the system bundle at run time) because the package imports don't match the version 0.0.0 provided by the default JavaSE-1.6 profile. [1] https://git.eclipse.org/r/#/c/6959/
(In reply to comment #8) > I pushed an example project to Gerrit (with a couple of workarounds to simulate > some of the missing implementation) [1]. I've just uploaded a second change where the expected behaviour of Tycho is completely simulated through other means, and hence the build passes.
If we support that the profile comes through a p2 repository, it seems natural that the "a.jre"/profile IU just needs to target platform. It may get there through any of the supported means. For example if the profile IU is in a p2 repositories, it would be sufficient to add that p2 repository in the POM. This implies that the target definition file resolution (which happens before the target platform is computed) cannot have special handling for the profile. There is special handling today (the configured EE "a.jre" IU is added to the available units), but I doubt that we need this. In fact this may even be confusing, because this makes the target file resolution in Tycho behave differently than in the PDE. So I propose the following change: - Don't have any execution environment specific logic in the target *definition* file resolution - Do all execution environment IU manipulation on the target platform&dependency resolver level (i.e. add the configured JRE IU, remove all others, etc.)
(In reply to comment #10) > So I propose the following change: > - Don't have any execution environment specific logic in the target > *definition* file resolution How do you expect this to work for .target files with includeMode=projector, where .target resolver must know list of packages provided by BREE? For example, consider a project that target one of restrictive environments but Import-Package javax.xml. This project will need javax.xml bundle in the target platform, so .target resolver must know that javax.xml package does not come from BREE. One option is to remove support for includeMode=projector, which is fine by me, but I think we'll need to ask on the mailing lists before we do that.
(In reply to comment #11) > How do you expect this to work for .target files with includeMode=projector, > where .target resolver must know list of packages provided by BREE? For example, > consider a project that target one of restrictive environments but > Import-Package javax.xml. This project will need javax.xml bundle in the target > platform, so .target resolver must know that javax.xml package does not come > from BREE. Agreed, this is a valid use case. I'm a bit unhappy that supporting it means that we'd need to break compatibility with the PDE target resolver. But in this case, we are right and the PDE is wrong. (Note to self: file bug on PDE for this.) ;-) So we need to: * Filter the "a.jre" IUs for wrong EEs (so that an javax.xml import is not always satisfied by the a.jre.javase/1.6.0 IU) * For standard EEs, add the "a.jre" IU for the right EE (because these typically don't exist in p2 repositories for EEs other than JavaSE-1.6) * For custom EEs, require that the corresponding "a.jre" IU exists (to fail early instead of with a hard-to-understand resolver error) and all this for both the target resolution and the dependency resolution.
Bummer! This is going to get even more complicated than I thought: We need to know the execution environment capabilities of the custom profile (see this test [1]). This information is contained in profile files, but not in the 'a.jre' IUs produced by the JREAction. So I'll probably need to fix the JREAction so that it also generates the provided "osgi.ee" capabilities into the 'a.jre' IUs. The only good thing about this: we'd need the same change to fix bug 387701. [1] https://git.eclipse.org/r/#/c/7525/1/tycho-core/src/test/java/org/eclipse/tycho/core/test/DependencyComputerTest.java
(In reply to comment #13) > > So I'll probably need to fix the JREAction so that it also generates the > provided "osgi.ee" capabilities into the 'a.jre' IUs. The only good thing > about this: we'd need the same change to fix bug 387701. > Can you make it possible to associate artifacts with a.jre IUs, while you are at it? For example, I would really like to be able to automatically resolve API jars for CDC-1.0/Foundation-1.0 and other restricted profiles from p2 repositories so I don't have to mess with build machine configuration. I am certain the same mechanism will be handy for custom profiles too.
(In reply to comment #14) > Can you make it possible to associate artifacts with a.jre IUs, while you are at > it? > > For example, I would really like to be able to automatically resolve API jars > for CDC-1.0/Foundation-1.0 and other restricted profiles from p2 repositories so > I don't have to mess with build machine configuration. I am certain the same > mechanism will be handy for custom profiles too. We don't need this for this enhancement, but it may be useful for the next level for custom profile support: custom profiles which also add new packages. But unlike with CDC-1.0, I expect that the custom profile API jars would change more often than the custom profile definition, so I don't expect a 1:1 relationship of profile definition to API jars.
(In reply to comment #12) > (In reply to comment #11) >> This project will need javax.xml bundle in the target > > platform, so .target resolver must know that javax.xml package does not come > > from BREE. > Agreed, this is a valid use case. I'm a bit unhappy that supporting it means > that we'd need to break compatibility with the PDE target resolver. But in this > case, we are right and the PDE is wrong. (Note to self: file bug on PDE for > this.) ;-) The bug already exists -> Bug 284465
(In reply to comment #13) > So I'll probably need to fix the JREAction so that it also generates the > provided "osgi.ee" capabilities into the 'a.jre' IUs. Opened p2 bug 388566 for this.
The implementation is finished. Took us 17 commits, the last one being this one [1]. Documentation is to be done. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=c6716ec620ce9ae411799343a596ebfe1fd182b5
The documentation for custom profile usage (and definition) is here [1]. [1] http://wiki.eclipse.org/Tycho/Execution_Environments
