| Summary: | compiler-plugin does not respect execution environment system packages | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Fedorenko <igor> |
| Component: | Tycho | Assignee: | Igor Fedorenko <igor> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | jan.sievers |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
is this related to bug 362966 ? (In reply to comment #1) > is this related to bug 362966 ? Yes, it is related. On some platforms, like OSX, it is not easily possible to install additional Java versions, so managing bootclasspath access rules is the only way to make sure build does not accidentally use classes that would not be available at runtime. The other aspect of this is the discrepancy between classpath visibility inside IDE and on command line build. In this particular case I believe IDE provided more sensible behaviour and it makes sense to change Tycho to match it. Implemented. Only packages explicitly listed in bundle runtime execution environment profile will be accessible from JDK libraries(s). http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=d5faf8f7be6b98c771a92476554e258beb9573da |
Unlike JDT compiler inside IDE ("JRE System Library" classpath container, to be precise), tycho compiler plugin does not respect org.osgi.framework.system.packages property and assumes all packages from bootclasspath are fully accessible. This results in compilation errors due to classpath collision between project's own classes and classes that happen to be available from bootclasspath. I'll push the fix along with a unit test shortly.