Opened 7 years ago

Last modified 9 months ago

#436 accepted enhancement

feature request maven exclude dependency

Reported by: aruttenberg Owned by: Mark Evenson
Priority: major Milestone: 1.9.3
Component: other Version: 1.6.0-dev
Keywords: aether abcl-asdf contrib Cc:
Parent Tickets:

Description

Like this: https://maven.apache.org/plugins/maven-dependency-plugin/examples/exclude-dependencies-from-dependency-analysis.html

To prevent dependencies from one maven artifact from stepping on another. Which they are doing. (each loads a different version)

Change History (21)

comment:1 Changed 7 years ago by aruttenberg

Here's a snippet that poc shows how one can do this at the direct dependent level.

    (let* ((node 
	     (#"getRoot" (#"collectDependencies" (ensure-repository-system) (ensure-session) collect-request))))
      (let ((evil (find-if (lambda(e) (equal (#"getArtifactId" (#"getArtifact" e)) "org.protege.editor.owl"))
			   (jss::j2list (#"getChildren" node)))))
	(#"remove" (#"getChildren" node) evil)
	(let ((dependency-request
		(jss:new 'DependencyRequest))

For deeper dependents I think you need to use pass a DependencyFilter in the constructor of the DependencyRequest. See PatternExclusionsDependencyFilter and OrDependencyFilter

For syntax I might suggest using the syntax that PatternExclusionsDependencyFilter uses, so it would be:

(:mvn "net.sourceforge.owlapi/owlapi-distribution/4.2.6" :exclude (":org.protege.editor.owl:" ..)) for my example case of exclusion by artifactID

The patterns apparently support version ranges.

The MVN URL Scheme doesn't seem to provide for exclusions. If you used them then they would be the form for both the dependency and the exclusions - you still need to specify the exclusions separately.

https://ops4j1.jira.com/wiki/display/paxurl/Mvn+Protocol

I vote for the pattern over the URL

comment:2 Changed 7 years ago by aruttenberg

Priority: majorblocker

comment:3 Changed 7 years ago by Mark Evenson

Owner: set to Mark Evenson
Status: newaccepted

Not sure as to which syntax to specify exclusion.

(:mvn "net.sourceforge.owlapi/owlapi-distribution/4.2.6" 
        :exclude (":org.protege.editor.owl:" ..))

What is syntax of the strings being passed to the :exclude clause here? Wouldn't it be simpler if they were regular mvn objects, i.e.

(:mvn "net.sourceforge.owlapi/owlapi-distribution/4.2.6" 
        :exclude ((:mvn "group/artifact/version")))

Of course we would probably prevent artifacts listed in an :exclude clause from having its own :exclude clause…

Last edited 7 years ago by Mark Evenson (previous) (diff)

comment:4 Changed 7 years ago by Mark Evenson

Component: (A)MOPjava

comment:5 Changed 7 years ago by aruttenberg

I think it should be as I wrote, a list of strings. The strings are groupid:artifactid:version as with the ones inside a (:mvn) component, but with any of the three components blank, meaning match anything.

Or, could take a lambda with args (groupid artifactid version why) of the dependency that might be loaded and if it returns nil it means skip it. The variable "why" is the path of dependencies that led to this one. The elements could be (:mvn blah) - that works here.

I just got bit by this again.

comment:6 in reply to:  5 Changed 7 years ago by Mark Evenson

Replying to aruttenberg:

I just got bit by this again.

I'll take a stab at this for abcl-1.5.0 after I rewrite the Aether adapter to have more meaningful failures.

Note that the naive implementation of dependency inclusions will not prevent incompatibilities between and within DEFSYSTEM forms, i.e. for a fragment like

  (:mvn "net.sourceforge.owlapi/owlapi-distribution/4.2.6" 
        :exclude (":log4j:1.2.14" ))
  (:mvn "org.apache/tomcat" 
        :exclude (":log4j:1.2.13" ))

it is undefined which log4j will be picked up.

It might be possible to do something intelligent with specialized class loaders, but given the impacts that Java 9 will have on locating and utilizing JVM artifacts, I'd rather do the simple implementation for exclusion to at least have some ability to get around bugs, and then revisit JVM artifacts when we have a reasonable abstraction which works on Java [678] as well as Java 9.

Last edited 7 years ago by Mark Evenson (previous) (diff)

comment:7 Changed 7 years ago by Mark Evenson

ME: We should probably split into a subticket for the near term work of the current patch by Alan, but we document here the steps to longer term solution that involves re-using ASDF abstractions in a more concise way.

After conversation on asdf-devel, Faré has outlined a plan of attack around :before methods for the planning phase.

We need to code our generalization solution against https://gitlab.common-lisp.net/asdf/asdf/tree/plan

https://gitlab.common-lisp.net/mevenson/asdf/issues/1

comment:8 Changed 7 years ago by Mark Evenson

Text of Faré's proposal https://mailman.common-lisp.net/pipermail/asdf-devel/2017-May/005775.html

0- Aim for a single coherent set of jars within a given build, because
otherwise lies madness.

1- Within a given plan-then-perform phase, collect the set of jars and
their version intervals in a :before method on perform-plan that talks to
maven and uses some heuristic to resolve versions.

2- Across plan-then-perform phases of a same build session, record which
versions were loaded, and issue an error if it's incompatible.

3- Across build sessions, remember what version was previously loaded, and
unload/shadow it if it is incompatible (or throw an error if you can't),
and decide whether to keep or upgrade (if possible) if it's compatible.

As to writing a system that solves issues across phases, in your worst
case, your toplevel system would :defsystem-depends-on a system that loads
all the proper versions of all the jar files (or at least the problematic
ones), and then whichever phase causes some version to be loaded will have
been preempted by that first defsystem-depends-on system.

comment:9 Changed 7 years ago by Mark Evenson

Component: javaother
Keywords: aether abcl-asdf contrib added
Milestone: 1.6.0
Version: 1.6.0-dev

Interim solution: abcl-1.5.0 ships with the ASDF:MVN-MODULE component which allows one to prune the subtree via white and black listing of the transitive dependencies via explicit exclusions and inclusions.

TODO: "port" asdf-3.3, then push dependency resolution to its layer via suitable abstractions.

Last edited 7 years ago by Mark Evenson (previous) (diff)

comment:10 Changed 4 years ago by Mark Evenson

Priority: blockermajor

comment:11 Changed 4 years ago by Mark Evenson

Milestone: 1.6.01.6.1

Ticket retargeted after milestone closed

comment:12 Changed 4 years ago by Mark Evenson

Milestone: 1.6.11.6.2

Ticket retargeted after milestone closed

comment:13 Changed 4 years ago by Mark Evenson

Milestone: 1.6.21.7.0

comment:14 Changed 4 years ago by Mark Evenson

Milestone: 1.7.01.7.1

Ticket retargeted after milestone closed

comment:15 Changed 4 years ago by Mark Evenson

Milestone: 1.7.11.7.2

Ticket retargeted after milestone closed

comment:16 Changed 4 years ago by Mark Evenson

Milestone: 1.7.21.8.0

Milestone renamed

comment:17 Changed 3 years ago by Mark Evenson

Milestone: 1.8.01.8.1

Ticket retargeted after milestone closed

comment:18 Changed 2 years ago by Mark Evenson

Milestone: 1.8.11.9.0

comment:19 Changed 14 months ago by Mark Evenson

Milestone: 1.9.01.9.1

comment:20 Changed 13 months ago by Mark Evenson

Milestone: 1.9.11.9.2

comment:21 Changed 9 months ago by Mark Evenson

Milestone: 1.9.21.9.3
Note: See TracTickets for help on using tickets.