Community
Participate
Working Groups
There is a breaking limitation preventing customer ClasspathContainers from including non .jar or .zip files. The breakdown is coming from the call to org.eclipse.jdt.internal.compiler.util.Util.isArchiveFileName(String name) from ClasspathEntry.validateClasspathEntry() on line 1674: } else if (!org.eclipse.jdt.internal.compiler.util.Util.isArchiveFileName(file.getName())) { I think this line should be removed to allow classpath containers more flexibility in deciding what are valid archives. WTP contains a classpath container used for resolving J2EE references within J2EE projects. There are several types of J2EE modules, one of which is called a Connector. Connectors have a spec requirement to be archived into .rar files. Thus, if WTP's J2EE classpath container attempts to resolve a .rar file, it fails because the above code generates an error similar to: Illegal type of archive for required library: 'D:\workspaces\runtime-workspace-WTP_153-binaryprojects\AnEAR\EarContent\C1.rar' in project C2 The J2EE classpath container reads the MANIFEST.MF file for the module and resolves Class-Path: Because there is no limitation on what a user can specify for their classpath it is conceivable someone might add just about anything. Thus, this is why I request the above check removed (as to rather adding an some sort of extension for adding additional types).
Will look at this for 3.4
This issue causes a number of error messages to show up in the problems view when RARs are included in the classpath container. For a large J2EE application including a RAR file is occasionally unavoidable. I understand that it is possible to change the preference setting for the build path to allow the compiler to still build projects but the end result is that false errors show up and cause confusion. While this may not be a big problem in a small application, a large J2EE application that is shipped to a number of customers is a different story. Having to explain why there are errors in their workspace immediately after setup isn't a good thing. It makes the application look bad and when the customer is told to ignore it because it's an Eclipse defect, that also looks bad. Can this defect be looked at for the 3.2 maintenance stream so that RAD v7 can pick up the change in it's own maintenance stream?
This request is a feature request. Normally we wouldn't put a new feature in a maintenance release. So it will depend on the nature of the change implied. Beyond the Util method change, we need to be able to open a RAR file. Is there standard API for reading RAR file contents ? Our approach is to only allow supported scenarii (i.e. JAR and ZIP archives).
This type of RAR file is just a JAR file with a different extension so existing APIs to read JAR files should work.
This isn't always the case that a RAR is a plain JAR (think winrar). Now, we could let clients decide the extensions for Java archives (and not restrict to only JAR and ZIP); i.e. if you want other ones, then you would configure them, and be responsible for ensuring they are properly used. I am thinking of a similar API as the one we added to let users configure the file extension for JAVA source files. @see JavaCore#getJavaLikeExtensions()
Since .RAR could be easily added to the preference for a Java Archive that does sound like it could work in my scenario specifically and also in the more general case.
Hello, Is there any update on the status of this request? Is it still being considered for inclusion in 3.4? Thanks
*** Bug 223414 has been marked as a duplicate of this bug. ***
I'd certainly like to see this fixed as it impacts the product I work on.
I will try to have a look at this for 3.4M7. Note that at this stage of the release, we will only be able to support .rar files that are actually archives (ie. files that can be read using java.util.zip.ZipFile). In 3.5, we can imagine being able to decode .rar files that are not archives by providing an extension point that a client could implement to decode the .rar files.
All we need is support for java.util.zip.ZipFile. I don't think you even need to worry about the extension point. If the Java VM doesn't support other encoding types, eclipse shouldn't support them either. The code wouldn't work at runtime outside eclipse.
(In reply to comment #11) > All we need is support for java.util.zip.ZipFile. I also agree with that. However, please note that those archives can have practically arbitrary file extensions (.rar, .par and .ejb3 can be used by some app servers), but they all still use same ZipFile format.
Created attachment 96606 [details] Proposed fix and regression tests
(In reply to comment #13) To clarify, with this fix any file can now be put on the build path (the batch compiler will still reject .java and .class files that are classpath entries though). If the file is not a ZipFile, it will appear with no children in the Package Explorer and JDT tools will behave as if it was not present. Otherwise, if the file is a ZipFile, it will behave exactly as if it was a .zip or .jar file.
Fix and tests released for 3.4M7
Tested extensions .rar, .dummy, .java and .class with build I20080427-2000. Also tested .dummy directly as an external archive, and through a user library. Question: what is the rationale for having the batch compiler behave differently? (Comparing with javac 1.6, the latter accepts archives which name ends with .class and .java on its classpath.)
I guess this is because I didn't know that javac 6 relaxed its limitations (javac 1.5.0 ignores .java files on the classpath). So it sounds like we should check the compliance. Can you please enter a separate bug report?
In fact, javac 1.5 ignores .dummy, .class and .rar files as well... Which means that our new behavior matches neither javac 1.5 nor javac 1.6 behavior. Opened bug 229236 to track the specifics of the batch compiler.
Verified for 3.4 M7 using build I20080427-2000.
*** Bug 154032 has been marked as a duplicate of this bug. ***
*** Bug 104157 has been marked as a duplicate of this bug. ***
