Dealing with non-standard maven packaging/ivy artifact type

[Eric Bowman]

Projects from Eclipse seem like prime offenders ... for example jetty now put <packaging>orbit</packaging> in some poms (http://git.eclipse.org/c/jetty/org.eclipse.jetty.orbit.git/tree/javax.servlet/3.0.0.v201112011016/pom.xml) even though the artifact is actually just a jar.  Similarly for jacoco, it declares its packaging as eclipse-plugin (https://github.com/jacoco/jacoco/blob/master/org.jacoco.core/pom.xml).

The work-around for sbt is to something like:

"org.jacoco" % "org.jacoco.core" % "0.5.9.201207300726" artifacts(Artifact("org.jacoco.core", "jar", "jar")),
"org.jacoco" % "org.jacoco.report" % "0.5.9.201207300726" artifacts(Artifact("org.jacoco.report", "jar", "jar"))

or

"org.eclipse.jetty.orbit" % "javax.servlet" % "3.0.0.v201112011016" artifacts (Artifact("javax.servlet", "jar", "jar")),
"org.eclipse.jetty.orbit" % "javax.mail.glassfish" % "1.4.1.v201005082020" artifacts (Artifact("javax.mail.glassfish", "jar", "jar")),
"org.eclipse.jetty.orbit" % "javax.activation" % "1.1.0.v201105071233" artifacts (Artifact("javax.activation", "jar", "jar")),
"org.eclipse.jetty.orbit" % "javax.transaction" % "1.1.1.v201105210645" artifacts (Artifact("javax.transaction", "jar", "jar")),

This sort of works, but it screws up how transitive dependencies work (in a nutshell, dependencies declared this way do not survive as transitive dependencies).

For example, we have a plugin (sbt 0.12.0) which a bunch of development teams share, that sets up a standard development environment.   Depending on one plugin pulls in sbt-release and other functionality that we want to be standard across teams, and it works really nicely.  But we can't include the jacoco4sbt plugin, for example, without requiring every project which uses our plugin to redeclare the dependency on the jacoco jars.  If we go and modify the synthetic ivy.xml files for the jacoco jars, for example, so that the type is "jar" instead of "eclipse-plugin", then everything works. But that means basically forking jacoco and jacoco4sbt, and creating our own private builds.  Possible, but not exactly ideal.

 

I'm curious to understand what the plan is going forward. Is this something sbt is beholden to ivy over? On the one hand it seems kind of lame of the Eclipse folks to abuse this ... clearly it hurts downstream tooling. But on the other hand, perhaps sbt (or ivy) is not implementing reasonable behavior here ... perhaps it makes sense to treat an unknown packaging as a jar, and let the downstream errors that will happen if that assumption is not true, remedy the situation?

Are there any options in 0.12.0 for making this behave more reasonably?  Having transitive dependencies not work for the jetty orbit stuff and now jacoco is resulting in a big maintenance headache, I'm sure not just for us.

Thoughts?

Thanks,

Eric

[Eric Bowman]

Also tried with 0.12.1-RC2, doesn't work with it either.