[armedbear] #436: feature request maven exclude dependency
#436: feature request maven exclude dependency -------------------------+---------------------- Reporter: aruttenberg | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | Parent Tickets: -------------------------+---------------------- 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) -- Ticket URL: <http://abcl.org/trac/ticket/436> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+----------------- Reporter: aruttenberg | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------- Comment (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 -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:1> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+----------------- Reporter: aruttenberg | Owner: Type: enhancement | Status: new Priority: blocker | Milestone: Component: (A)MOP | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+----------------- Changes (by aruttenberg): * priority: major => blocker -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:2> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: (A)MOP | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Changes (by mevenson): * owner: => mevenson * status: new => accepted Comment: 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"))) }}} -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:3> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: java | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Changes (by mevenson): * component: (A)MOP => java -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:4> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: java | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Comment (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. -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:5> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: java | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Comment (by mevenson): Replying to [comment:5 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 reasonsable abstraction the combines Java [678] with Java 9. -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:6> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: java | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Comment (by mevenson): 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 -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:7> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+---------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: Component: java | Version: Resolution: | Keywords: Parent Tickets: | ------------------------------+---------------------- Comment (by mevenson): 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. }}} -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:8> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+-------------------------------------- Reporter: aruttenberg | Owner: mevenson Type: enhancement | Status: accepted Priority: blocker | Milestone: 1.6.0 Component: other | Version: 1.6.0-dev Resolution: | Keywords: aether abcl-asdf contrib Parent Tickets: | ------------------------------+-------------------------------------- Changes (by mevenson): * keywords: => aether abcl-asdf contrib * version: => 1.6.0-dev * component: java => other * milestone: => 1.6.0 Comment: Interim solution: abcl-1.5.0 ships with the ASDF:MVN-MODULE component which allows one to prune the subtree via exclusions exclusions. TODO: "port" asdf-3.3, then push dependency resolution to its layer via suitable abstractions. -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:9> armedbear <http://abcl.org> armedbear
#436: feature request maven exclude dependency ------------------------------+-------------------------------------- Reporter: aruttenberg | Owner: Evenson Not Org Type: enhancement | Status: accepted Priority: major | Milestone: 1.6.0 Component: other | Version: 1.6.0-dev Resolution: | Keywords: aether abcl-asdf contrib Parent Tickets: | ------------------------------+-------------------------------------- Changes (by Evenson Not Org): * priority: blocker => major -- Ticket URL: <http://abcl.org/trac/ticket/436#comment:10> armedbear <http://abcl.org> armedbear
participants (1)
-
armedbear