feature request maven exclude dependency

[aruttenberg]

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)

[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

[Mark Evenson]

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…

[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.

[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.

[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

[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.

[Mark Evenson]

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.

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Milestone renamed

[Mark Evenson]

Ticket retargeted after milestone closed