[ 
https://issues.apache.org/jira/browse/MDEP-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hasnae Rehioui updated MDEP-651:
--------------------------------
    Description: 
*Background :*

We are upgrading to a recent version of aspose-imaging and ran into an issue 
with our `unpack-dependencies` configuration when ran locally *on macos*

This is affecting our dev loop mostly, you can reproduce it with 
{code:java}
git clone https://github.com/viqueen/maven-playground
cd maven-playground
mvn test{code}
long story short :

`maven-dependency-plugin` has the `unpack-dependencies` mojo that relies on 
plexus un-archiver which in a file system like mac (not case sensitive) , might 
end up overriding files , leading in some cases to a corrupted class path , 
aspose-imaging library is an example of that : it contains classes and 
interfaces named as follow : com.aspose.internal.imaging.gq/aq (interface) , 
com.aspose.internal.imaging.gq/aQ (class implementing the interface)  , notice 
the case sensitive naming

so on mac , the plugin will override the aq interface with the content of aQ 
type , leading to a NoClassDefFoundError because the file name and its content 
do not match
{code:java}
java.lang.NoClassDefFoundError: com/aspose/imaging/internal/gq/aq (wrong name: 
com/aspose/imaging/internal/gq/aQ)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
{code}
*Workaround :*

turns out our project config no longer requires unpacking dependencies so we 
disabled the thing

*Suggestion :*

not sure this is even fixable , but would be nice to have some debug / warning 
logs that it is happening so developers can diagnose errors more easily; 
basically throw in some love onto 
[https://github.com/viqueen/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractUnArchiver.java#L346]

in our particular use case , we are consuming the plugin through 
[https://bitbucket.org/atlassian/amps/src/903a1ce408da5b8500ed0d7e0e5701eb83d8cde4/amps-maven-plugin/src/main/java/com/atlassian/maven/plugins/amps/MavenGoals.java?at=8.0-stable&fileviewer=file-view-default#MavenGoals.java-458]
 , these internals are not exactly common knowledge and the logs were not 
helping either, devs knew it was FS related though just not clear on what 
triggers the problem

so optionally failing the build if/when it happens could point our devs on the 
right track much faster

 

  was:
*Background :*

We are upgrading to a recent version of aspose-imaging and ran into an issue 
with our `unpack-dependencies` configuration when ran locally *on macos*

This is affecting our dev loop mostly, you can reproduce it with 
{code:java}
git clone https://github.com/viqueen/maven-playground
cd maven-playground
mvn test{code}
long story short :

`maven-dependency-plugin` has the `unpack-dependencies` mojo that relies on 
plexus un-archiver which in a file system like mac (not case sensitive) , might 
end up overriding files , leading in some cases to a corrupted class path , 
aspose-imaging library is an example of that : it contains classes and 
interfaces named as follow : com.aspose.internal.imaging.gq/aq (interface) , 
com.aspose.internal.imaging.gq/aQ (class implementing the interface)  , notice 
the case sensitive naming

so on mac , the plugin will override the aq interface with the content of aQ 
type , leading to a NoClassDefFoundError because the file name and its content 
do not match
{code:java}
java.lang.NoClassDefFoundError: com/aspose/imaging/internal/gq/aq (wrong name: 
com/aspose/imaging/internal/gq/aQ)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
{code}
*Workaround :*

turns out our project config no longer requires unpacking dependencies so we 
disabled the thing

*Suggestion :*

not sure this is even fixable , but would be nice to have some debug / warning 
logs that it is happening so developers can diagnose errors more easily; 
basically throw in some love onto 
[https://github.com/viqueen/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractUnArchiver.java#L346]

in our particular use case , we are consuming the plugin through 
[https://bitbucket.org/atlassian/amps/src/903a1ce408da5b8500ed0d7e0e5701eb83d8cde4/amps-maven-plugin/src/main/java/com/atlassian/maven/plugins/amps/MavenGoals.java?at=8.0-stable&fileviewer=file-view-default#MavenGoals.java-458]
 , these internals are not exactly common knowledge and the logs were not 
helping either, they knew it was FS related though

so optionally failing the build if/when it happens could point our devs on the 
right track much faster

 


> unpack-dependencies should warn when it overrides extracted files on macos 
> (case insensitive FS)
> ------------------------------------------------------------------------------------------------
>
>                 Key: MDEP-651
>                 URL: https://issues.apache.org/jira/browse/MDEP-651
>             Project: Maven Dependency Plugin
>          Issue Type: Wish
>          Components: unpack-dependencies
>    Affects Versions: 3.1.1
>            Reporter: Hasnae Rehioui
>            Priority: Major
>
> *Background :*
> We are upgrading to a recent version of aspose-imaging and ran into an issue 
> with our `unpack-dependencies` configuration when ran locally *on macos*
> This is affecting our dev loop mostly, you can reproduce it with 
> {code:java}
> git clone https://github.com/viqueen/maven-playground
> cd maven-playground
> mvn test{code}
> long story short :
> `maven-dependency-plugin` has the `unpack-dependencies` mojo that relies on 
> plexus un-archiver which in a file system like mac (not case sensitive) , 
> might end up overriding files , leading in some cases to a corrupted class 
> path , aspose-imaging library is an example of that : it contains classes and 
> interfaces named as follow : com.aspose.internal.imaging.gq/aq (interface) , 
> com.aspose.internal.imaging.gq/aQ (class implementing the interface)  , 
> notice the case sensitive naming
> so on mac , the plugin will override the aq interface with the content of aQ 
> type , leading to a NoClassDefFoundError because the file name and its 
> content do not match
> {code:java}
> java.lang.NoClassDefFoundError: com/aspose/imaging/internal/gq/aq (wrong 
> name: com/aspose/imaging/internal/gq/aQ)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> {code}
> *Workaround :*
> turns out our project config no longer requires unpacking dependencies so we 
> disabled the thing
> *Suggestion :*
> not sure this is even fixable , but would be nice to have some debug / 
> warning logs that it is happening so developers can diagnose errors more 
> easily; basically throw in some love onto 
> [https://github.com/viqueen/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractUnArchiver.java#L346]
> in our particular use case , we are consuming the plugin through 
> [https://bitbucket.org/atlassian/amps/src/903a1ce408da5b8500ed0d7e0e5701eb83d8cde4/amps-maven-plugin/src/main/java/com/atlassian/maven/plugins/amps/MavenGoals.java?at=8.0-stable&fileviewer=file-view-default#MavenGoals.java-458]
>  , these internals are not exactly common knowledge and the logs were not 
> helping either, devs knew it was FS related though just not clear on what 
> triggers the problem
> so optionally failing the build if/when it happens could point our devs on 
> the right track much faster
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to