SBT does not honor pom.xml when managedStyle = ManagedStyle.Maven

[Indrajit Raychaudhuri]

Hi,

Just discovered that 'update' does not honor the dependencies declared
in pom.xml when either of the following is true:

1. Setting Maven managed style explicitly:
val managedStyle = ManagedStyle.Maven

2. Configuring source jar to be published along with the binary jars:
override def packageSrcJar = defaultJarPath("-sources.jar")
lazy val sourceArtifact = Artifact.sources(artifactID)
override def packageToPublishActions =
super.packageToPublishActions ++ Seq(packageSrc)

Both of these add explictArtifacts to the particular module thereby
making inlineSettings.module.explicitArtifacts.size > 1. This in turn
influence defaultModuleSettings in vending out sbt.InlineConfiguration
instead of sbt.PomConfiguration [1].

Is there anyway to get around this scenario? For me both #1 and #2 are
necessary (to publish .pom and the -sources.jar along with the .jar).
However, I want 'update' to honor the dependencies declared in pom.xml
too :)

Cheers, Indrajit

[1]
http://github.com/harrah/xsbt/blob/master/sbt/src/main/scala/sbt/BasicProjectTypes.scala#L255

[Mark Harrah]

Hey Indrajit,

I'd be surprised if people are using pom.xml and publishing. I don't think it is possible in sbt. The issue is that you can't mix inline configurations and external configurations. If your pom.xml is sufficiently simple, you could pull the dependencies from it yourself using Scala's XML support and stick them in libraryDependencies.

-Mark

[Indrajit Raychaudhuri]

Hi Mark,

Do you recommend against using pom.xml to resolve dependencies in case
my project needs to be published remotely?

All that I am doing is using Maven's existing pom.xml for dependency
management instead of declaring them inline. I realize that I should not
add explicit dependency inline if I expect SBT to honor the pom.xml. And
this works as expected for <artifact>.jar publishing so long as I chose
not to publish <artifact>-sources.jar and or <artifact>.pom along with
<artifact>.jar. Once I do so, they end up adding to the inline
dependency list.

Processing pom.xml directly to extract out dependencies and composing
libraryDependencies is a difficult option for pom.xml which has complex
dependency/dependencyManagement graph in a multi-hierarchy project.

I assumed that asking SBT to publish additional jar (for example
sources.jar) would not imply that this jar becomes an implicit
dependency too.

Cheers, Indrajit

[Mark Harrah]

Indrajit,

Any module-related inline configuration prevents using the pom.xml. This includes artifacts.

The details of this are that sbt allows one of:
1) external configuration by pom.xml
2) external configuration by ivy.xml
3) inline configuration with Scala and inline Ivy XML

For #1 or #2, sbt tells Ivy to parse the pom.xml or ivy.xml. You can publish using a pom.xml because Ivy assumes a default artifact.

In order to accomplish #3, sbt tells Ivy to parse the inline Ivy XML and then merges the inline Scala configuration into the resulting data structure programmatically. In order to add artifacts to be published for a pom.xml, sbt would have to do something like #3 but parse the pom.xml instead of the inline XML.

This might be possible, but combining inline Scala with inline Ivy XML was pretty rough.

-Mark