[JCR-4260] jackrabbit-filevault-package-maven-plugin analyze-classes mojo can fail with "Access denied" or "...target/classes is a directory"

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Invalid
• Component/s: maven
• Assignee: Unassigned
• Reporter: Olaf Otto
• Created: 16/Feb/18 11:38
• Updated: 16/Feb/18 13:21
• Resolved: 16/Feb/18 12:44

Description

In a multi-module maven setup, when building without installing the artifacts, e.g. running

 mvn clean test -B

The following exception arises when the module build has an embedded dependency to another module of the same project:

[ERROR] Failed to execute goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1:analyze-classes (default-analyze-classes) on ...
imports: <local fs path>\target\classes (Access is denied) -> [Help 1]                                                                 
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.
o.neba.neba-delivery-aem: Error while analysing imports                                                                                 

     --- snipp ---
    
        ... 20 more                                                                                                                     
Caused by: java.io.FileNotFoundException: <local fs path>\target\classes (Access is denied)                                            
        at java.util.zip.ZipFile.open(Native Method)                                                                                    
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)                                                                               
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)                                                                               
        at java.util.jar.JarFile.<init>(JarFile.java:166)                                                                               
        at java.util.jar.JarFile.<init>(JarFile.java:130)                                                                               
        at org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder$BundleInfo.<init>(ImportPackageBuilder.java:477)   
        at org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder$BundleInfo.<init>(ImportPackageBuilder.java:469)   
        at org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder.scanBundles(ImportPackageBuilder.java:348)         
        at org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder.analyze(ImportPackageBuilder.java:192)             
        at org.apache.jackrabbit.filevault.maven.packaging.AnalyzeClassesMojo.execute(AnalyzeClassesMojo.java:97)                      

This is caused by  the Mojo's assumption that artifact dependencies of type "jar" are always represented by a jar file, whereas they can be represented by directories in case of a dependency to another module within a multi-module setup.