Community
Participate
Working Groups
Right now the batch compiler doesn't look for jar files specified in the Class-Path: entry of the MANIFEST.MF file. This support should be added.
I may have run into this. I'm using the org.eclipse.jdt.apt.core plug-in, which contains tools.jar. I'm unable to reference com.sun.mirror.apt.AnnotationProcessorEnvironment, which lives in tools.jar, even though it looks like MANIFEST.MF for the plug-in exports the appropriate package.
javac does use the Class-Path clause of jar files manifests to complete the classpath if needed. The base idea is that the classpath should be completed by such entries, avoiding duplicates and (probably - need to check javac behaviors) appending new jar files at the tail or the classpath. The following points need further consideration: - what about other classpath entries (bootclasspath et al.)? - exact mapping for relative paths (are they relative to the jar file's directory, the compilation directory, etc.)? The behavior of java and the spec of jar files should help make design choices here.
Maxime, Could you please investigate what it would take to support this?
This is the corresponding Sun bug which handled adding this feature to 'javac': http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212732
*** Bug 198572 has been marked as a duplicate of this bug. ***
Created attachment 84932 [details] test cases (wip)
Created attachment 85181 [details] writing tests (wip)
Design issue: do we want to always follow the classpath links of jar files or would we make this optional? Looking at javac: - javac up to 1.4 never follows the links, - javac from 1.5 and higher always follows the links regardless of any option, and especially regardless of the source and target levels. I would then vote against our batch compiler relying on source or target levels to decide whether it should follow links or not. Accordingly, we would have two options left: - either we simply follow links in all cases; - or else we introduce a dedicated option to tell the compiler whether it should follow links or not. I'll go for the first choice, because it is simpler and does not preclude the introduction of a dedicated option later on if needed. (Admittedly, it may break users that rely on the links never being followed. If such cases show up, we'll have to reconsider.)
Created attachment 86096 [details] writing tests (wip) Shifted the test numbers to catch up with HEAD and added a few. Still in simulation mode (aka, need to suppress WORK SIMULATED SO FAR lines to get a feel of what we really do).
Checked that javac did not follow the links for jars passed to the -sourcepath switch. Interestingly enough, found out that starting with version 6 it would fetch source files from jars passed to the -classpath switch (which it did not do formerly). We don't either. Opened separate bug 214481 for this.
The right fix depends on what we decide for bug 214731.
Not so. Found a code that works in both cases (use of absolute or relative paths).
Created attachment 86646 [details] Fix + test cases
Kent would you please tell me what you think?
Do you have a reference for the code in the ManifestAnalyzer ?
I crafted it after http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html and javac's behavior.
Looks ok, but watch some of your indentation + if (pathsAndContents != null) { + compile(pathsAndContents, options, classesPath); + } + for (int i = 0, l = extraPathsAndContents == null ? 0 : extraPathsAndContents.length; i < l; /* inc in loop */) { + File outputFile = new File(classesPath, extraPathsAndContents[i++]); + outputFile.getParentFile().mkdirs(); + Util.writeToFile(extraPathsAndContents[i++], outputFile.getAbsolutePath()); + } When I initially read this I thought the for loop was inside the if {}
I have a few questions regarding this feature... How will this feature be exposed to Java projects in Eclipse? If .classpath contains a jar with manifest entries, will those types be visible? How will this look in Package Explorer? Will the user be able to browse types in jars that are referenced via manifest classpath like they can with jars that are referenced directly?
This bug only addresses the feature in the context of the batch compiler. We are thought about it in the wider context of all uses of JDT when tackling it, but it soon appeared that while the batch story could make it in 3.4, the more general one would take us more time.
That would be rather unfortunate considering how prevalent is the use of manifest classpath. I understand that there are some tricky UI issues to consider, but would it be possible to at least handle this at the core level for 3.4 (types are accessible, but you can't see the jars in the package explorer)? That would be a big help to many eclipse users and adopters.
Jérôme, Philippe, I'll let you elaborate on our plans here.
Patch needs to be ported to HEAD.
Deferring to M7
Created attachment 92916 [details] Fix + test cases Patch ported to HEAD. Only changes comments and indentation. Will release tomorrow if no test tilts and no one protests.
Released for 3.4 M6.
Unfortunately, the verification fails on a quite simple test case: p/X.java: package p; public class X { A a; B b; } lib/lib1.jar: A.class + Class-Path: lib2.jar lib/lib2.jar: B.class I compile it using ecj.jar based on v_847 code with the following cmd line: java -jar ecj.jar -cp lib\lib1.jar p/X.java And I got: ---------- 1. ERROR in p\X.java (at line 4) B b; ^ B cannot be resolved to a type ---------- Compiling the same stuff with javac 1.6.0_05-b12 does not produce any compile error. To have no error with ecj, I need to add explicitely lib2.jar on the classpath: java -jar ecj.jar -cp lib\lib1.jar -cp lib\lib2.jar lip/X.java
The problem came from my set-up. I used an old ecj.jar instead of the new exported ecj-head.jar!!! Sorry, for that... So, verified for 3.4M6 using ecj-head.jar based on v_847...
Realized today that the test cases numbering should have been realigned before the release. Other test cases have been contributed since. Decided to shift the test cases of this bug (since they were the original cause), so as to maintain a continuous numbering. Resulted into the following shifts in BatchCompilerTest: [216-228]->[239-251],[229-251]->[256-278].
I have a very similar problem: If I add 'Server Runtime Enviroment', type: 'Basic -> J2EE Runtime Library' and then I set location to a directory which contains .jar file with manifest defining another .jars in class-path, these jars are not included.
(In reply to comment #29) > I have a very similar problem: > If I add 'Server Runtime Enviroment', type: 'Basic -> J2EE Runtime Library' and > then I set location to a directory which contains .jar file with manifest > defining another .jars in class-path, these jars are not included. This is a different issue. Please open a bug against JDT/Debug and specify the build id.
(In reply to comment #30) > (In reply to comment #29) > > I have a very similar problem: > > If I add 'Server Runtime Enviroment', type: 'Basic -> J2EE Runtime Library' and > > then I set location to a directory which contains .jar file with manifest > > defining another .jars in class-path, these jars are not included. > This is a different issue. Please open a bug against JDT/Debug and specify the > build id. Actually, please open an enhancement request against WTP/ServerTools as that's where "J2EE Runtime Library" feature is from. Every library (aka classpath container) that wants to trace manifest classpath needs to be implemented to do so. See this for more information: http://lt-rider.blogspot.com/2010/05/jdt-manifest-classpath-classpath.html
