[ 
https://issues.apache.org/jira/browse/MSHADE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273260#comment-17273260
 ] 

Alexander Kriegisch edited comment on MSHADE-366 at 1/28/21, 6:22 PM:
----------------------------------------------------------------------

Okay, I quickly looked into the source code and saw that it happens in 
{{MinijarFilter.removeServices(MavenProject, Clazzpath)}}, specifically in this 
code section:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    try ( final JarFile jar = new JarFile( fileName ) )
                    {
                        // (...)
                    }
                    catch ( final IOException e )
                    {
                        log.warn( e.getMessage() );
                    }
{code}

I modified this locally by adding a log message and printing the full exception:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    log.info( "Runtime classpath element: " + fileName );
                    try ( final JarFile jar = new JarFile( fileName ) )
                    {
                        // (...)
                    }
                    catch ( final IOException e )
                    {
                        log.warn( e );
                    }
{code}

When running my build, I then see this:

{code:none}
[INFO] Minimizing jar dev.sarek:sarek-unfinal:jar:1.0-SNAPSHOT
[INFO] Runtime classpath element: 
C:\Users\alexa\Documents\java-src\Sarek\sarek-unfinal\target\classes
[WARNING] 
java.io.FileNotFoundException: 
C:\Users\alexa\Documents\java-src\Sarek\sarek-unfinal\target\classes (Zugriff 
verweigert)
    at java.io.RandomAccessFile.open0 (Native Method)
    at java.io.RandomAccessFile.open (RandomAccessFile.java:347)
    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:261)
    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:216)
    at java.util.zip.ZipFile$Source.<init> (ZipFile.java:1218)
    at java.util.zip.ZipFile$Source.get (ZipFile.java:1184)
    at java.util.zip.ZipFile$CleanableResource.<init> (ZipFile.java:718)
    at java.util.zip.ZipFile.<init> (ZipFile.java:238)
    at java.util.zip.ZipFile.<init> (ZipFile.java:168)
    at java.util.jar.JarFile.<init> (JarFile.java:347)
    at java.util.jar.JarFile.<init> (JarFile.java:318)
    at java.util.jar.JarFile.<init> (JarFile.java:257)
    at org.apache.maven.plugins.shade.filter.MinijarFilter.removeServices 
(MinijarFilter.java:135)
    at org.apache.maven.plugins.shade.filter.MinijarFilter.<init> 
(MinijarFilter.java:118)
    at org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters 
(ShadeMojo.java:953)
    (...)
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\net\bytebuddy\byte-buddy\1.10.13\byte-buddy-1.10.13.jar
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\dev\sarek\sarek-agent-common\1.0-SNAPSHOT\sarek-agent-common-1.0-SNAPSHOT.jar
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\net\bytebuddy\byte-buddy-agent\1.10.13\byte-buddy-agent-1.10.13.jar
[INFO] Minimized 2532 -> 118 (4%)
[INFO] Minimized 2898 -> 475 (16%)
[INFO] Replacing original artifact with shaded artifact.
{code}

So first of all the logging is suboptimal there because the user has no option 
to see the full stack trace, not even when running with {{-e}} command line 
option. 

The root cause of the warning is simply that Shade does not check runtime class 
path elements for whether they can possibly be JAR files, e.g. by excluding 
directories like {{target/classes}} or handling them separately, depending on 
which is the right approach here.

[~michael-o], I hope this will help you fix the problem. This quick & dirty 
workaround fixes it for me locally, but please come up with an adequate 
solution by yourself. I am just hinting into a direction:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    File classpathFile = new File( fileName );
                    if ( !classpathFile.exists() || classpathFile.isDirectory() 
)
                    {
                        continue;
                    }
                    try ( final JarFile jar = new JarFile( fileName ) )
{code}

Please also note that this change does not address the information (stack 
trace) hiding problem in the {{catch}} blocks.


was (Author: kriegaex):
Okay, I quickly looked into the source code and saw that it happens in 
{{MinijarFilter.removeServices(MavenProject, Clazzpath)}}, specifically in this 
code section:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    try ( final JarFile jar = new JarFile( fileName ) )
                    {
                        // (...)
                    }
                    catch ( final IOException e )
                    {
                        log.warn( e.getMessage() );
                    }
{code}

I modified this locally by adding a log message and printing the full exception:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    log.info( "Runtime classpath element: " + fileName );
                    try ( final JarFile jar = new JarFile( fileName ) )
                    {
                        // (...)
                    }
                    catch ( final IOException e )
                    {
                        log.warn( e );
                    }
{code}

When running my build, I then see this:

{code:none}
[INFO] Minimizing jar dev.sarek:sarek-unfinal:jar:1.0-SNAPSHOT
[INFO] Runtime classpath element: 
C:\Users\alexa\Documents\java-src\Sarek\sarek-unfinal\target\classes
[WARNING] 
java.io.FileNotFoundException: 
C:\Users\alexa\Documents\java-src\Sarek\sarek-unfinal\target\classes (Zugriff 
verweigert)
    at java.io.RandomAccessFile.open0 (Native Method)
    at java.io.RandomAccessFile.open (RandomAccessFile.java:347)
    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:261)
    at java.io.RandomAccessFile.<init> (RandomAccessFile.java:216)
    at java.util.zip.ZipFile$Source.<init> (ZipFile.java:1218)
    at java.util.zip.ZipFile$Source.get (ZipFile.java:1184)
    at java.util.zip.ZipFile$CleanableResource.<init> (ZipFile.java:718)
    at java.util.zip.ZipFile.<init> (ZipFile.java:238)
    at java.util.zip.ZipFile.<init> (ZipFile.java:168)
    at java.util.jar.JarFile.<init> (JarFile.java:347)
    at java.util.jar.JarFile.<init> (JarFile.java:318)
    at java.util.jar.JarFile.<init> (JarFile.java:257)
    at org.apache.maven.plugins.shade.filter.MinijarFilter.removeServices 
(MinijarFilter.java:135)
    at org.apache.maven.plugins.shade.filter.MinijarFilter.<init> 
(MinijarFilter.java:118)
    at org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters 
(ShadeMojo.java:953)
    (...)
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\net\bytebuddy\byte-buddy\1.10.13\byte-buddy-1.10.13.jar
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\dev\sarek\sarek-agent-common\1.0-SNAPSHOT\sarek-agent-common-1.0-SNAPSHOT.jar
[INFO] Runtime classpath element: 
C:\Users\alexa\.m2\repository\net\bytebuddy\byte-buddy-agent\1.10.13\byte-buddy-agent-1.10.13.jar
[INFO] Minimized 2532 -> 118 (4%)
[INFO] Minimized 2898 -> 475 (16%)
[INFO] Replacing original artifact with shaded artifact.
{code}

So first of all the logging is suboptimal there because the user has no option 
to see the full stack trace, not even when running with {{-e}} command line 
option. 

The root cause of the warning is simply that Shade does not check runtime class 
path elements for whether they can possible be JAR files, e.g. by excluding 
directories like {{target/classes}} or handling them separately, depending on 
which is the right approach here.

[~michael-o], I hope this will help you fix the problem. This quick & dirty 
workaround fixes it for me locally, but please come up with an adequate 
solution by yourself. I am just hinting into a direction:

{code:java}
                for ( final String fileName : 
project.getRuntimeClasspathElements() )
                {
                    File classpathFile = new File( fileName );
                    if ( !classpathFile.exists() || classpathFile.isDirectory() 
)
                    {
                        continue;
                    }
                    try ( final JarFile jar = new JarFile( fileName ) )
{code}

Please also note that this change does not address the information (stack 
trace) hiding problem in the {{catch}} blocks.

> "Access denied" during 'minimizeJar'
> ------------------------------------
>
>                 Key: MSHADE-366
>                 URL: https://issues.apache.org/jira/browse/MSHADE-366
>             Project: Maven Shade Plugin
>          Issue Type: Bug
>    Affects Versions: 3.2.3
>         Environment: Windows 10 Professional, Java 8, Maven 3.6.3 (bundled in 
> IntelliJ IDEA Ultimate 2020.1)
>            Reporter: Alexander Kriegisch
>            Priority: Major
>         Attachments: full-build.log, module-build.log
>
>
> Whenever I use Maven Shade with {{minimizeJar}} on my Windows 10 box, I see 
> this warning during the build:
> {code:none}
> [INFO] Including net.bytebuddy:byte-buddy:jar:1.10.10 in the shaded jar.
> [INFO] Minimizing jar de.scrum-master:remove-final-agent:jar:1.0-SNAPSHOT
> [WARNING] 
> C:\Users\alexa\Documents\java-src\ByteBuddyAspect\remove-final-parent\remove-final-agent\target\classes
>  (Zugriff verweigert)
> {code}
> "Zugriff verweigert" is German for "access denied".
> One sample plugin configuration is:
> {code:xml}
>       <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-shade-plugin</artifactId>
>         <version>3.2.3</version>
>         <executions>
>           <execution>
>             <phase>package</phase>
>             <goals>
>               <goal>shade</goal>
>             </goals>
>             <configuration>
>               <minimizeJar>true</minimizeJar>
>               <createDependencyReducedPom>false</createDependencyReducedPom>
>               <shadedArtifactAttached>false</shadedArtifactAttached>
>             </configuration>
>           </execution>
>         </executions>
>       </plugin>
> {code}
> I removed my filters because even without them the same warning occurs. As 
> soon as I deactivate {{minimizeJar}}, the warning is gone.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to