Olaf Otto created JCR-4260:
------------------------------
Summary: jackrabbit-filevault-package-maven-plugin can fail with
"Access denied" or "...taget/classes"
Key: JCR-4260
URL: https://issues.apache.org/jira/browse/JCR-4260
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: maven
Reporter: Olaf Otto
In a multi-module maven setup, when building without installing the artifacts,
e.g. running
mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V
Followed by
mvn test -B
The following exception arises when the module build has an embedded dependency
to another module of the same project:
{code:java}
[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)
{code}
This is caused by the Mojo's assumption that artifact dependencies of type
"jar" are always represented by a jar file, whereas they _may_ be represented
by directories in case of a dependency to another module within a multi-module
setup that has no installed artifact yet, as common during snapshot development.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
