maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Broyer <t.bro...@gmail.com>
Subject How to resolve artifacts while respecting projects' dependency management? (or finding an alternative)
Date Sun, 12 Oct 2014 23:17:58 GMT
Hi all,

I have a situation where a plugin needs to take the project's classpath and
add some elements to it. What I'd like is that the elements be resolved as
if they were declared as dependencies in the project's POM: take into
account dependencyManagement for the artifact's version and (more
importantly) its transitive dependencies.
How to do it? (in a way compatible with all Maven 3.x releases)

Or do you think it'd be a better approach to just ask people add those
dependencies to their projects? They're tools needed for building the
project, but they don't need to be in the javac classpath. I tend to
believe this approach is much cleaner, but would appreciate external
feedback.
The plugin currently resolves the dependencies using maven-compat's
ArtifactResolver but I don't think this respects the projects
dependencyManagement (BTW, the "root" artifact passed comes from the
pluginArtifactMap); it also unconditionally add the JARs to the classpath,
which could cause conflicts I believe in some (edge-case) conditions. The
first question I asked because I'd like to keep backwards compatibility and
try to fix things (or at least make them better), but if the best practice
is to add the dependencies to the project using the plugin, I'd just leave
resolution as it is today but disable it behind a flag (either the plugin
extends the classpath in some "broken" way, or you add the dependencies to
your project and the plugin just uses the project's classpath).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message