Usage question #1

Open
ryan-williams opened this Issue Mar 25, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@ryan-williams

ryan-williams commented Mar 25, 2017

Hey @vanzin, finally got a chance to check this out, and its usage in livy.

I noticed that the livy-core-parent POM does not have any references to the ${scala.binary.version} that the scala-2.1*/pom.xmls overwrite; for example, there are no cross-versioned dependencies.

Would this still work in the case that a dependency needed a cross-version? That is basically where I got stuck attempting this approach (relevant section of blog post draft).

If you want to only declare each dependency once (i.e. in the parent, not in each {2.10,2.11} POM), then the published livy-core-parent POM will have to choose one or the other scala.binary.version value for its declaration of that dep (otherwise you'd be publishing a POM with an un-set property, which iirc errored at some level), and then both 2.1* modules end up having that version in their dep-closures/classpaths, because it is effectively a hard-coded 2.10 or 2.11 dep, so you need to publish 2.1*-specific parent POMs, and you are back where you started…

Let me know if that question is not coherent, and thanks for pointing me to this!

@vanzin

This comment has been minimized.

Show comment
Hide comment
@vanzin

vanzin Mar 27, 2017

Owner

then both 2.1* modules end up having that version in their dep-closures/classpaths

I think it should work (although I haven't tested). If you declare a dependency in the parent pom with a reference to ${scala.binary.version}, and the default is let's say "2.10", and you depend on my-lib_2.11, that specific pom (in my repo that would be my-lib/scala-2.11/pom.xml would override the value of scala.binary.version. The parent pom references the variable, which is overridden in the child pom, so it should work.

A problem may occur if you do shading or otherwise publish "effective poms", which resolve variables at build time. Then yes, you could end up with conflicting versions. But I'm not sure the parent pom would be affected here, since it's not a jar pom and thus would not be affected by shading.

Owner

vanzin commented Mar 27, 2017

then both 2.1* modules end up having that version in their dep-closures/classpaths

I think it should work (although I haven't tested). If you declare a dependency in the parent pom with a reference to ${scala.binary.version}, and the default is let's say "2.10", and you depend on my-lib_2.11, that specific pom (in my repo that would be my-lib/scala-2.11/pom.xml would override the value of scala.binary.version. The parent pom references the variable, which is overridden in the child pom, so it should work.

A problem may occur if you do shading or otherwise publish "effective poms", which resolve variables at build time. Then yes, you could end up with conflicting versions. But I'm not sure the parent pom would be affected here, since it's not a jar pom and thus would not be affected by shading.

@ryan-williams

This comment has been minimized.

Show comment
Hide comment
@ryan-williams

ryan-williams Mar 27, 2017

Hm OK, we might have to hash out an example when one of us has time; I feel like I tried a few versions of this and failed, and don't remember exactly why :-\

Hm OK, we might have to hash out an example when one of us has time; I feel like I tried a few versions of this and failed, and don't remember exactly why :-\

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment