The target deployment path 'net/virtual-void/sbt-dependency-graph_2.10_0.13/0.7.5/sbt-dependency-graph-0.7.5.pom' does not match the POM's expected path prefix 'net/virtual-void/sbt-dependency-graph/0.7.5'.

[ealphonse]

Hello,

I cannot copy sbt-dependency-graph artifact with Artifactory because the POM file refers to another path prefix.

Artifactory gives this error:

Failed to validate target path of pom: net/virtual-void/sbt-dependency-graph_2.10_0.13/0.7.5/sbt-dependency-graph-0.7.5.pom: The target deployment path 'net/virtual-void/sbt-dependency-graph_2.10_0.13/0.7.5/sbt-dependency-graph-0.7.5.pom' does not match the POM's expected path prefix 'net/virtual-void/sbt-dependency-graph/0.7.5'. Please verify your POM content for correctness and make sure the source path is a valid Maven repository root path.

I guess it would work with different POM files for each cross-build, or using the official ivy sbt plugin repo?

Thank you in advance for any help

[jrudolph]

@ealphonse that's a bummer. I wonder, how this can happen. Is this an invariant of poms that is not enforced by sonatype / maven central or is this an implementation restriction of artifactory? Should sbt be changed to put the right names into the right field of the pom?

[ealphonse]

Thanks @jrudolph for your prompt answer.

I guess this is not enforced by maven. I found that Artifactory may or may not check POM files integrity (check Configure repositories -> Edit -> Suppress POM consistency checks.).

As for sbt, you are right, it does not seem to generate POM files consistent with cross-builds. I check other cross-builds available in maven central and they do have the right artifactId.

For sbt-dependency-graph, Artifactory suggests this POM file:

<dependency>
    <groupId>net.virtual-void</groupId>
    <artifactId>sbt-dependency-graph_2.10_0.13</artifactId>
    <version>0.7.5</version>
</dependency>

Maybe sbt-dependency-graph could serve as a bug report case?

Best

[jrudolph]

I check other cross-builds available in maven central and they do have the right artifactId.

Are these sbt plugins as well? Maybe it's just a problem with publishing plugins to a maven repository. I checked the sbt source code before and it seems pom generation and choosing the publishing path are somewhat disconnected so that may be the reason that the invariant is broken.

[ealphonse]

No. I found this one for example: https://repo1.maven.org/maven2/io/spray/spray-json_2.11/1.3.1/spray-json_2.11-1.3.1.pom

As far as I understand, sbt plugins are published in a ivy repo, like this: https://dl.bintray.com/sbt/sbt-plugin-releases/cc.spray/sbt-revolver/scala_2.9.2/sbt_0.12/0.6.1/

See: http://www.scala-sbt.org/0.13/docs/Community-Plugins.html#Community+Ivy+Repository

sbt should generate the correct POM file but I really do not know sbt internals. Do you think this is doable?

[jrudolph]

Yes, I guess the best practice is to publish sbt plugins to an ivy repository. For me it was less hassle to publish to maven central so far, so that's what I've done for the last few years. It worked so far (apart from the broken metadata you now noticed :)) so realistically I won't change that for now. If you create an issue for sbt I may comment on that.

Maybe I can add a hack that fixes the broken pom after it was generated.

[ealphonse]

We publish to ivy repos, would be tricky.

Maybe I can add a hack that fixes the broken pom after it was generated.

Do not bother! I guess the best pratice, following maven repo's one, is to not check POM integrity...

Thanks for the plugin, Best

[samzilverberg]

hi there @jrudolph , i just had the same problem with artifactory complaining about the pom. however as its a company artifactory I don't have the permissions to suppress consistency checks.

maybe it'd be a good idea to publish this "ivy style" on bintray? after doing a little reading and looking at where other sbt plugins are published it seems like the common way.

examples from community plugins at: https://dl.bintray.com/sbt/sbt-plugin-releases/com.typesafe.sbt/

publishMavenStyle := false should simply create the ivy dir structure (and not generate poms)

some more documentation about publishing to bintray: https://www.scala-sbt.org/1.0/docs/Bintray-For-Plugins.html