Community
Participate
Working Groups
Created attachment 286837 [details] sample repository for reproduction I have initially raised this issue against tycho in bug 537320 , but I was barking up the wrong tree. Since that bug has been archived I'm raising a new one instead here. I'm attaching three projects that can be used to reproduce this issue through tycho : unzip then use "mvn clean verify" on the parent pom. This will work if "tycho.test.parent/pom.xml" is set to use <tycho-version>1.0.0</tycho-version> (which internally uses the JDT version 3.12.2.v20161117-1814) but will fail if tycho is set to user version 1.1.0 (internally uses JDT version 3.14.0.v20171206-0802) This regression was introduced by commit https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c798229d351d6daa2232cff6c15750336659223e , specifically at line 979 of the EclipseFileManager ( https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/104858/7/org.eclipse.jdt.compiler.tool/src/org/eclipse/jdt/internal/compiler/tool/EclipseFileManager.java#979 ). "getPaths" will try to parse the classpath entry as a java.nio.Path, which will fail because "external:" is invalid as a path. This issue prevents standalone/maven building of any project making use of "external" entries in the manifest.
Laurent, do you want to provide a patch?
Unfortunately, although I've debugged my issue up to that point to try and fix it, I have no idea where to go from there in order to tackle this issue. The EclipseFileManager now uses java.nio.Path internally in the ModuleLocationHandler , and there is no way afaik to create a "Path" with a ":" in the location. We would need to use plain strings or a specific data structure to hold these? org.eclipse.osgi.internal.loader.classpath.ClasspathManager.addEclipseClassPathEntry(ArrayList<ClasspathEntry>, String, ClasspathManager, Generation) uses the second approach with specific data structures but I do not think this can be used from the jdt compiler.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
