Community
Participate
Working Groups
In JDT there exits the concept of "classpath-container" these can have the for example the following forms: JRE_CONTAINER: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11"> JUNIT_CONTAINER: <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/5"/> USER_LIBRARY: <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/userlib"/> Tycho should have support for these, if .classpath is present. JRE_CONTAINER could map to toolchains and be a source for the decision what to use at compile-time (as an alternative to the BREE / default EE) JUNIT_CONTAINER would need to resolve to the target the required junit libs USER_LIBRARY should map to a pom configured list of IUs with version ranges (similar to require-bundle) or absolute path to a plain jar.
For JUnit org.eclipse.jdt.internal.junit.buildpath.JUnitContainerInitializer.getNewContainer(IPath) contains the logic how JDT JUnitContainer behaves for different JUnit levels.
Actually the current tycho dependency resolver maps to the <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> classpath container...
Classpath containers are an extensible concept that does require to run Eclipse headless for proper resolution. In Plugin development, those containers are not really substitute for alternative dpendency management (MANIFEST.MF, additionBundles...). What's the use-case you have in mind for such feature?
While class-path container are extensible per se, target-locations are also. We still provide alternative implementations for those that mimics the original extension. The same would be good for a (limited) set of classpath container. The main use-case for me is having compile-dependecies defined properly, e.g. for test-only dependencies (JUnit) or custom libs (e.g aspectj, osgi-test, ...). For example currently when i write tests I have to: - add org.junit as require bundle -> instead I'd like to add JUNIT_CONTAINER/5 to the classpath - tycho-surefire tries to "guess" what junit framework is use -> instead it should look at the classpath container first if I have explicitly used that. The bigger use-case is a more smooth integration with whats possible in the IDE without additional duplicated configuration in pom.xml files.
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
