Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Tycho/Release Notes/2.1"
| Line 3: | Line 3: | ||
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; } | #versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; } | ||
</css> | </css> | ||
| − | <div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/2.0|< Previous Version]] | [[Tycho/Release Notes/2. | + | <div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/2.0|< Previous Version]] | [[Tycho/Release Notes/2.2|Next Version >]]</div> |
<!-- | <!-- | ||
Revision as of 19:16, 29 October 2020
New and Noteworthy
Complete list of bug fixes and enhancements in 2.1.0-SNAPSHOT
Automatic determination of --release compiler argument based on BREE
bug 561363 tycho-compiler-plugin now determines the maven.compiler.release property (--release compiler argument) automatically based on the BREE.
This ensures ABI compatibility when targeting older Java versions by setting a correct bootclasspath (JEP 247).
Note: This automatism might not be desired in some situations. For example when referencing internal JDK packages (e.g. using an OSGI framework extension bundle) --release can not be used, because the bootclasspath set by it does not include those internal packages. For these scenarios, an new configuration option <deriveReleaseCompilerArgumentFromTargetLevel>false</deriveReleaseCompilerArgumentFromTargetLevel> was introduced to disable this automatic determination.
Automatic generation of OSGi metadata for maven dependencies
As described here tycho can use maven dependencies for requirement-resolution. Until now it was only possible to use those that where already OSGi-Bundles. With bug 567098 a new option automated was added that allows to use even non-osgi artifacts with the following rules
- if the artifact is already an OSGi bundle it is used as is
- if the artifact is not an OSGi bundle but a regular jar it gets automatic meta-data generated using BND
- to prevent confusion with official artifacts, the BSN is derived by first using the groupId of the module, append the groupId of the artifact and the artifactId. The version is used as-is with adjustments to form a proper OSGi manifest version.
- all required packages are imported as optional dependencies, so it is the responsibility of the user to add all necessary ones to the running target in advance.
- all packages of the jar are exported with the version of the bundle.
This feature might be enhanced in the future, feedback is welcome, but not meant to replace p2 or proper crafted OSGi-Artifacts. It can help of integration with 3rd-party libraries that are not (yet) bundles and/or available as official p2 update-site, especially in rapid-prototyping scenarios.
That's why it uses a very generic, open approach and we hope to help people adopting tycho/OSGi more easy with it.