You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Olaf Otto (JIRA)" <ji...@apache.org> on 2018/02/16 13:01:00 UTC
[jira] [Updated] (JCRVLT-272)
jackrabbit-filevault-package-maven-plugin analyze-classes mojo can fail
with "Access denied" or "...taget/classes
jackrabbit-filevault-package-maven-plugin analyze-classes mojo can fail
with "Access denied" or "...taget/classes is a directory""
[ https://issues.apache.org/jira/browse/JCRVLT-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olaf Otto updated JCRVLT-272:
-----------------------------
Description:
In a multi-module maven setup, when building without installing the artifacts, e.g. running
{code:java}
mvn clean test -B{code}
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 _can_ be represented by directories in case of a dependency to another module within a multi-module setup is inspected during a maven invocation that does not cause the jar artifacts to be bound to the dependency, e.g. only calling "mvn test".
was:
In a multi-module maven setup, when building without installing the artifacts, e.g. running
{code:java}
mvn clean test -B{code}
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 _can_ be represented by directories in case of a dependency to another module within a multi-module setup.
> jackrabbit-filevault-package-maven-plugin analyze-classes mojo can fail with "Access denied" or "...taget/classes jackrabbit-filevault-package-maven-plugin analyze-classes mojo can fail with "Access denied" or "...taget/classes is a directory""
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-272
> URL: https://issues.apache.org/jira/browse/JCRVLT-272
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Reporter: Olaf Otto
> Priority: Major
>
> In a multi-module maven setup, when building without installing the artifacts, e.g. running
> {code:java}
> mvn clean test -B{code}
> 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 _can_ be represented by directories in case of a dependency to another module within a multi-module setup is inspected during a maven invocation that does not cause the jar artifacts to be bound to the dependency, e.g. only calling "mvn test".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)