[jira] [Reopened] (MDEP-651) unpack-dependencies should warn when it overrides extracted files on macos (case insensitive FS)

["Maarten Mulders (Jira)" <ji...@apache.org>]

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

Maarten Mulders reopened MDEP-651:
----------------------------------

Unfortunately, this issue isn't solved yet. The dependency upgrade breaks a hand full of tests in M-D-P, and [as I pointed out on GitHub|https://github.com/apache/maven-dependency-plugin/pull/111#issuecomment-707643034] I need to investigate those first.

> 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
>            Assignee: Maarten Mulders
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> *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
(v8.3.4#803005)