Opened 4 months ago

Last modified 4 weeks ago

#436 accepted enhancement

feature request maven exclude dependency

Reported by: aruttenberg Owned by: mevenson
Priority: blocker Milestone:
Component: java Version:
Keywords: 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)

Subtickets (add)

Change History (6)

comment:1 Changed 4 months 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 4 months ago by aruttenberg

  • Priority changed from major to blocker

comment:3 Changed 3 months ago by mevenson

  • Owner set to mevenson
  • Status changed from new to accepted

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 3 months ago by mevenson (previous) (diff)

comment:4 Changed 5 weeks ago by mevenson

  • Component changed from (A)MOP to java

comment:5 follow-up: Changed 4 weeks 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 4 weeks ago by mevenson

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 4 weeks ago by mevenson (previous) (diff)
Note: See TracTickets for help on using tickets.