[MNG-5567] Zip files are not included in classpaths at all

[jira-importer]

Pablo La Greca opened MNG-5567 and commented

when i added a dependency that was zip file
eg

 <dependency>
     <groupId>hsqldb</groupId>
     <artifactId>hsqldb</artifactId>
     <version>1.7.3.0</version>
     <scope>provided</scope>
     <type>zip</type>
</dependency>

this file was not included in the test classpath and so the test would not pass

---

Affects: 3.3.9

Issue Links:

• MNG-1683 type zip for packaging ?

• MNG-6080 New scope for non-functional dependencies

• MNG-2500 Zip files are not included in the test classpath

• MWAR-406 custom artifact types don't get copied to WEB-INF/lib
  ("is depended upon by")

Remote Links:

• Page
  

1 votes, 12 watchers

[jira-importer]

Pablo La Greca commented

As I couldn't reopen MNG-2500 I created this new issue.

Why did you close it as won't fix?. It makes perfect sense to have a dependency as zip and not as jar.

If you take a look at the classpath documentation here: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html you can see that .zip files are valid as part of the classpath and maven should support that. I understand that adding support for that may cause side effects with the current maven behavior but at least you should add a workaround to be able to add the .zip dependency to the classpath and test classpath

[jira-importer]

Michael Osipov commented

Still applies to 3.3.9. The reason is that there is no default artifact handler and the property addedToClasspath is false. Your dependency is ignored in any classpath.

[jira-importer]

Pablo La Greca commented

Are you planning to fix this issue? That would make me really happy :)

[jira-importer]

Michael Osipov commented

Yes, I am and I already have a working version on my machine.

You can apply this patch against master and try yourself:

index 2f26ce2..92ddaec 100644
--- a/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml
+++ b/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml
@@ -190,5 +190,18 @@ Artifact handlers are required by the dependency resolution mechanism.
       </configuration>
     </component>

+    <!--
+     | ZIP
+     |-->
+    <component>
+      <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
+      <role-hint>zip</role-hint>
+      <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
+      <configuration>
+        <type>zip</type>
+        <addedToClasspath>true</addedToClasspath>
+      </configuration>
+    </component>
+
   </components>
 </component-set>
diff --git a/maven-core/src/site/apt/artifact-handlers.apt b/maven-core/src/site/apt/artifact-handlers.apt
index 1a4b344..79572ad 100644
--- a/maven-core/src/site/apt/artifact-handlers.apt
+++ b/maven-core/src/site/apt/artifact-handlers.apt
@@ -53,3 +53,5 @@ Default Artifact Handlers Reference
 *--------------------+------------+------------+---------------+-----------+---------------------+-----------------------+
 | <<<test-jar>>>     | <<<jar>>>  | <<<jar>>>  | <<<tests>>>   | java      | <<<true>>>          |                       |
 *--------------------+------------+------------+---------------+-----------+---------------------+-----------------------+
+| <<<zip>>>          | <= type>   | <= type>   |               | none      | <<<true>>>          |                       |
+*--------------------+------------+------------+---------------+-----------+---------------------+-----------------------+
\ No newline at end of file

[jira-importer]

Joerg Schaible commented

And how can I stop it such a behavior then? We use zip files for all kind of resources and they definitely have nothing to search as part of any classpath.

[jira-importer]

Michael Osipov commented

You can't. How are they supposed to cause harm? Anyway, the classpath definition says:

Class paths to the JAR, zip or class files. Each class path should end with a file name or directory depending on what you are setting the class path to, as follows:

• For a JAR or zip file that contains class files, the class path ends with the name of the zip or JAR file.
• For class files in an unnamed package, the class path ends with the directory that contains the class files.
• For class files in a named package, the class path ends with the directory that contains the root package, which is the first package in the full package name.

So we aren't even compliant. What people currently do is package resources as JAR files because there is no other reasonable way. Moreover, this issue has been open for more than a year, you could have stepped up earlier.

[jira-importer]

Michael Osipov commented

Fixed with c023e58104b71e27def0caa034d39ab0fa0373b6.

[jira-importer]

Stephen Connolly commented

Maven 3.4.0 has been dropped. See this thread for more details.

This issue will need to be re-scheduled for a Maven release in the (hopefully near) future.

[jira-importer]

Joerg Schaible commented

Still I have major concerns to include this at all. Currently ZIPs are often used as attached artifacts to transport some additional resources. With this functionality these artifacts add suddenly all kind of unwanted transitive dependencies. If you look at Central for ZIP artifacts then you'll have trouble to find one that is usable as a JAR.

[jira-importer]

Michael Osipov commented

First of all, how are ZIP files going to have transitive dependencies? We do not have a zip packaging yet. ZIP files aren't JAR files, there is no need to pretend to be usable as a JAR. Both qualify equally on the class path.

[jira-importer]

Grzegorz Slowikowski commented

As Joerg writes, zip files are often used for non-classpath resources. I'd like to describe my case.

My Maven plugin for Play! Framework 1.x requires zip dependency in project (not plugin) dependencies containing the resources which must be extracted and accessed as files later during the build cycle. Check 'com.google.code.maven-play-plugin.org.playframework:play:1.4.3:framework:zip' as an example. It has over 20MB and should not be present on the classpath.
Plugin finds dependency with 'framework' classifier and 'zip' extension, extracts it, and doesn't expect it to be in the classpath.

Since zip files were newer added to classpath, so the scope of such dependency wasn't important. If declared without a scope (using default 'compile' scope) it will be available in runtime (for example, added to war files).
I cannot predict, how it will influence user projects using my plugin.

BTW
The original issue was about hsql zip-type dependency. There is no such dependency, check http://repo1.maven.org/maven2/hsqldb/hsqldb/1.7.3.0/

[jira-importer]

Michael Osipov commented

In your case, you can tell the Maven Dependency Plugin to download your ZIP file and extract it, not from dependency tree, you can also set scope to provided, of course. For you, ZIP files shouldn't be on the classpath, for others they should because it is standard behavior. You can always exclude such a dep, but not the other way unless this is fixed.

What is your proposal to fix this issue, make is compliant with the docs of java(1)? I have abused JARs for bundle CSS/JS files just because ZIP packaging isn't available. This is overdesigned too.

It does not really matter wether the HSQLDB dep exists, the matter was the missing ZIP file on cp.

[jira-importer]

Grzegorz Slowikowski commented

I'm plugin developer, not user. Zip finding and processing logic is in my plugin. I would have to change my plugin and instruct all plugin users to upgrade and remove all zip dependencies from their project files or at least to change scope to provided. All this just because Maven decides to break backward compatibility.

I know that jars can contain sources, javadocs, etc. They were always added to classpaths (and e.g. Maven GWT Plugin even requires jars with sources to be added to dependencies because GWT will need then on the classpath) so all users and developers know about it.

Zip format is very uncommon in Java world and some (including me) used it on purpose to package non-classpath Maven dependencies.

My proposal is to not change current behavior. I don't see any really important reason to do this. Backward compatibility is more important than compliance with Java technical notes (after so many years of not being compliant) IMO.

[jira-importer]

Michael Osipov commented

Which version do you expect this to be in? 3.6? 4.0?

[jira-importer]

Joerg Schaible commented

First of all, how are ZIP files going to have transitive dependencies? We do not have a zip packaging yet.

It is quite common to create attached ZIP files with the assembly plugin. An attached artifact shares the same transitive dependencies than the main artifact. How often I wished that could be stopped for EJB clients ;-)