Resolving in SBT jar dependency created by Maven with custom packaging ("play2")

[Grzegorz Slowikowski]

Hi

I'm developing Maven Plugin for Play2. My plugin defines custom packaging "play2" and produces regular jar file.
Maven knows that for dependency with "play2" type is regular jar file (this is defined in "play2" packaging in the plugin).

The problem is SBT and Ivy look for file with "play2" extension instead.


My simple Maven test module is here https://play2-maven-plugin.googlecode.com/svn/tags/test-projects-1.0.0-alpha6/play22/java/helloworld
(this is one of Play! examples ported to Maven)

"pom.xml" fragment:

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.google.code.play2-maven-plugin.test-projects.play22.java</groupId>
    <artifactId>helloworld</artifactId>
    <version>1.0.0-alpha6</version>
    <packaging>play2</packaging>

You can checkout it from svn and install with Maven by just calling "mvn install".


My SBT build.sbt file (this is Play! 2.2.2 project) looks like:

import play.Project._
...
resolvers += "Local Maven Repository" at "file:///path/to/.m2/repository"
...
libraryDependencies ++= Seq(
...
  "com.google.code.play2-maven-plugin.test-projects.play22.java" % "helloworld" % "1.0.0-alpha6"
  )

playJavaSettings

SBT log fragment:
...
[warn]     [NOT FOUND  ] com.google.code.play2-maven-plugin.test-projects.play22.java#helloworld;1.0.0-alpha6!helloworld.play2 (0ms)
[warn] ==== Maven2 Local: tried
[warn]   file:/D:/home/gs/.m2/repository/com/google/code/play2-maven-plugin/test-projects/play22/java/helloworld/1.0.0-alpha6/helloworld-1.0.0-alpha6.play2
[info] downloading file:/D:/home/gs/.m2/repository/com/typesafe/play/play-java_2.10/2.2.2/play-java_2.10-2.2.2.pom ...
[info]     [SUCCESSFUL ] com.typesafe.play#play-java_2.10;2.2.2!play-java_2.10.pom (63ms)
[info] downloading http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-java_2.10/2.2.2/play-java_2.10-2.2.2-test-sources.jar ...
[info]     [SUCCESSFUL ] com.typesafe.play#play-java_2.10;2.2.2!play-java_2.10.jar(src) (1031ms)
[info] downloading http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-java_2.10/2.2.2/play-java_2.10-2.2.2-sources.jar ...
[info]     [SUCCESSFUL ] com.typesafe.play#play-java_2.10;2.2.2!play-java_2.10.jar(src) (1031ms)
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     ::              FAILED DOWNLOADS            ::
[warn]     :: ^ see resolution messages for details  ^ ::
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     :: com.google.code.play2-maven-plugin.test-projects.play22.java#helloworld;1.0.0-alpha6!helloworld.play2
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
sbt.ResolveException: download failed: com.google.code.play2-maven-plugin.test-projects.play22.java#helloworld;1.0.0-alpha6!helloworld.play2
...

So, is this problem in SBT or in Ivy, and can I fix it?

Regards
Grzegorz Slowikowski

[Josh Suereth]

This is definitely the default behavior for Ivy.  Maven, e.g. can only consume your packaging type if your plugin is available to tell it about the new extension.  Ivy makes assumptions, but I think you can directly work against those, I'm not sure.

If sbt has any code *already* to do such things it'd be in our ivy/src/ directory.   Otherwise you may have to attack the problem within ivy.  It's much faster if you can just put the workaround in sbt.  However, we are running a branch of ivy (here; https://github.com/sbt/ivy) that includes some additional performance tuning we added for sbt 0.13.6, related to consuming maven artifacts.

I think *one* possible alternative is to explicitly declare the artifact you want:

libraryDependencies +=  "com.google.code.play2-maven-plugin.test-projects.play22.java" % "helloworld" % "1.0.0-alpha6" artifact(....)

which may work right now.

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/5f1ba79a-5b0f-4208-aa04-23f0f439caaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Grzegorz Slowikowski]

Hi Josh

Thank you for clarification. I don't know Ivy. I thought about some kind of global mapping play2->jar somewhere in the configuration. I will ask on Ivy list.

The solution I found, which may seem stupid, is not to use custom packaging in such cases at all :)
It requires to change packaging from custom to "jar" and add all mojo executions defined in custom packaging life-cycle to the project.
It makes "pom.xml" file more verbose, but works and does not require any magic configurations.

I cannot find "artifact(...)" function, you wrote about. There is "artifacts(...)" function in ModuleID class. Is that what you meant?

Regards
Grzegorz

Maybe this note will be helpful for somebody in the future.

[Josh Suereth]

On Sat, May 10, 2014 at 5:05 AM, Grzegorz Slowikowski <gslowi...@gmail.com> wrote:

Hi Josh

Thank you for clarification. I don't know Ivy. I thought about some kind of global mapping play2->jar somewhere in the configuration. I will ask on Ivy list.

The solution I found, which may seem stupid, is not to use custom packaging in such cases at all :)
It requires to change packaging from custom to "jar" and add all mojo executions defined in custom packaging life-cycle to the project.
It makes "pom.xml" file more verbose, but works and does not require any magic configurations.

I cannot find "artifact(...)" function, you wrote about. There is "artifacts(...)" function in ModuleID class. Is that what you meant?

Yes.

I also ran into the same issues when thinking about doing "scala" packaging in the past.  The issue with maven's packaging is that the plugin which provides the packaging handlers *HAS* to live in every build that *consumes* those packages.   There's no real way to get Ivy aware of them AFAICT.

So, the alternative workaround is great for us for now.  We'll see if maybe we can force ivy to handle them in the future though.

[Grzegorz Slowikowski]

I've googled around and found this issue: https://github.com/sbt/sbt/issues/499
It works perfectly, so there is no need for a workaround on Maven side!

Grzegorz