[MDEP-776] copy-dependencies overwrites artifacts of the same artifact id

[jira-importer]

Nikolaos Georgiou opened MDEP-776 and commented

We have a project which has 2 dependencies of different groupId but same artifactId and version, e.g. com.acme:foo:1.2.3 and com.ecorp:foo:1.2.3

We use the copy-dependencies goal of the plugin to copy libraries under target/lib folder.

Actual Result:

• only one foo.jar survives in the target/lib folder. The other one silently gets overwritten. This leads to difficult to diagnose runtime errors, as one JAR is missing.

 

Expected Result:

• it should at least give a warning, if not an error, that it has overwritten an artifact during this process

 

Known workaround:

• we activated useRepositoryLayout, which allows both artifacts to survive under a directory structure, which complicates a bit our classpath building process (from target/lib/* we need to find all the JARs with a bit of bash glue)

 

---

Affects: 3.1.2, 3.2.0

Issue Links:

• MDEP-772 "failOnDuplicates" option for "unpack" goal

Remote Links:

• GitHub Pull Request #463
  

0 votes, 5 watchers

[jira-importer]

Michael Osipov commented

Yes, this is a general problem when artifact ids collide. One issue with a warning is that the JAR could be from a previous run and how do you detect that?!

[jira-importer]

Nikolaos Georgiou commented

Michael Osipov Could maybe the goal collect in-memory the resolved artifact IDs into a HashSet and complain on duplicates?

Alternatively, could there be a flag e.g. -DcomplainOnDuplicates=true that people could use on CI (where there is no previous run) and fail there hard?

Just thinking out loud.

[jira-importer]

Andreas Sewe commented

Seems almost like a duplicate of MDEP-772, although that is about the unpack goal, not copy-dependencies. Either way, emitting a warning would be good.

[jira-importer]

Elliotte Rusty Harold commented

You could use prependGroupId to disambuguate.

I wonder if it would make sense to mangle the names a bit if there are two artifacts with different group IDs but same artifact ID?

[jira-importer]

Andreas Sewe commented

You could use prependGroupId to disambuguate.

Yes, there are workarounds, e.g., useRepositoryLayout as proposed by the OP. However, sometimes you want to use copy-dependencies or unpack-dependencies to create a specific directory structure. In that case, a simple warning that the structure you want is not possible because of name clashes would make debugging much easier.

I wonder if it would make sense to mangle the names a bit if there are two artifacts with different group IDs but same artifact ID?

Please don't introduce any complex name mangling, in particular not if predicated on some condition like there being clashing names. Oftentimes, you want a specific file and directory structure for further processing/repackaging, and anything the structure produced by copy-dependencies less predictable is problematic, IMHO.

[jira-importer]

Elliotte Rusty Harold commented

Yes, I'm still trying to wrap my head around this one. Part of the problem is we don' actually document what the output structure looks like. We need to do that.

I also wonder if this should be a failure rather than a warning.

[jira-importer]

Elliotte Rusty Harold commented

as far as it can be; warning will now be issued, but at the base this is a deep issue with the design of the Maven repository system.