Include the scala version in the maven artefacts #432

Closed
Johnlon opened this Issue Dec 3, 2012 · 13 comments

Comments

Projects
None yet
4 participants

Johnlon commented Dec 3, 2012

Please include the scala version in the path as per scalatest ..

<dependency>
    <groupId>org.scalatest</groupId>
    <artifactId>scalatest_2.9.2</artifactId>
    <version>1.8.RC1</version>
<dependency>

Owner

aslakhellesoy commented Dec 3, 2012

Why?

Owner

aslakhellesoy commented Dec 3, 2012

I mean, why add a dependency to this library at all. It's not used anywhere in the Cucumber-JVM codebase.

Owner

aslakhellesoy commented Dec 14, 2012

Closed due to lack of follow-up. Feel free to request this to be reopened.

Johnlon commented Dec 19, 2012

The scala library and compiler deps appear here...
https://github.com/cucumber/cucumber-jvm/blob/master/scala/pom.xml

As you change the versions of these from 2.9.2 to 2.10 and back to 2.9.2 we get builds of Cuke scala DSL that does / doesn't work respectively with a 2.9.2 project.

It would be preferable for client apps (eg me) for the cucumber-scala arterfact to be called cucumber-scala-2.9.2 as per other libs that have a scala binding such as scalatest.
eg http://repo1.maven.org/maven2/org/scalatest/scalatest_2.9.2/1.8/scalatest_2.9.2-1.8.pom
vs http://repo1.maven.org/maven2/org/scalatest/scalatest_2.10.0-M4/1.9-2.10.0-M4-B2/scalatest_2.10.0-M4-1.9-2.10.0-M4-B2.pom

Johnlon commented Dec 19, 2012

PS you may have misinterpreted my first post.
I was not suggesting you include a dep on scalatest itself - I was suggesting you use the same pattern as scalatest for encoding the scala version in the cucumber-scala artefact descriptor.

Scala test builds separate artefacts for its 2.9.2 and 2.10 builds - for cucumber-scala to do the same it should be building eg cucumber-scala-2.9.2 rather than just cucumber-scala.

This approach seems the convention for scala libraries, such as cucumber-scala.

This approach avoids a situation where cucumber switching from 2.9.2 to 2.10 to 2.9.2 keeps breaking my app.

Owner

aslakhellesoy commented Dec 19, 2012

Thanks @Johnlon for the clarification - I understand what you mean now. We can put the scala version in the artifactId, but to keep it simple I think releases should only publish one version, corresponding to the latest final scala release.

Sounds ok? Want to send a pull request?

@aslakhellesoy aslakhellesoy reopened this Dec 19, 2012

Johnlon commented Dec 19, 2012

Might need to wait a bit as I am having a back operation tomorrow.
Thanks

Wasn't sure what you meant ... I think releases should only publish one
version, corresponding to the latest final scala release.

On 19 December 2012 14:29, Aslak Hellesøy notifications@github.com wrote:

Thanks @Johnlon https://github.com/Johnlon for the clarification - I
understand what you mean now. We can put the scala version in the
artifactId, but to keep it simple I think releases should only publish one
version, corresponding to the latest final scala release.

Sounds ok? Want to send a pull request?


Reply to this email directly or view it on GitHubhttps://github.com/cucumber/cucumber-jvm/issues/432#issuecomment-11531706.

Owner

aslakhellesoy commented Dec 19, 2012

What I meant was that the next release would publish a cucumber-scala-2.9.2 artefact only (there won't be a cucumber-scala-2.10 or cucumber-scala-2.10.0-RC5 one).

-Unless of course the current final scala version at that point in time is 2.10.0. In that case we'd release (only) cucumber-scala-2.10.0.

Makes sense? Good luck with your operation mate.

Contributor

skipoleschris commented Dec 19, 2012

Hi. Hot sure it's quite as simple as that. I've been looking into it a bit with regard to my sbt plugin.

The current release schedule for Scala is that 2.10.0 should be final before the end of the year. However, I think 2.9.2 and 2.10.x will run side-by-side for some time (my company's projects certainly won't be migrating from 2.9.2 in the near future). I've done a few tests and cucumber-scala built against either version is not binary compatible with the other.

For the sbt plugin I'm currently supporting 2 cucumber versions: 1.0.9 for Scala 2.9.2 and 1.1.x for Scala 2.10. While this works, it does mean that Scala 2.9.2 users can't have the latest cucumber-jvm features and bug fixes.

The best solution would be to cross-build two versions of cucumber-scala, one for 2.9.2 and one for 2.10.0. Not sure how this is achieved in a Maven project but I'm happy to take a look over the Christmas break if that would help.

Johnlon commented Dec 21, 2012

The best solution would be to cross-build two versions of cucumber-scala, one for 2.9.2 and one for 2.10.0. Not sure how this is achieved in a Maven project but I'm happy to take a look over the Christmas break if that would help.

Unless, or until, you start using a feature only available in 2.10 then the best solution is just to build two separate artefacts, one for each scala revision .. with as discussed the artefact-id containing the relevant scala version ...

  • cucumber-scala-2.9.2
  • cucumber-scala-2.10

I believe scala 2.9.3 is coming out sometime soon but I am not sure whether 2.9.2/2.9.3 are binary compatible.
If they are then possibly you could get away with dropping the minor digit ...

  • cucumber-scala-2.9

One problem I think is that I'm not sure if you can override the artefact-id to include a variable for the scala version.


Thoughts ..

How about renaming the source dir to cucumber-scala-2.9.2/ and change that pom to build cucumber-scala-2.9.2.

Then have a parallel tree eg called cucumber-scala-2.10/ but this dir would contain nothing but a pom that is customised for 2.10 - AND - that pom's config for the scala/java compiler fetches its source code via a relative path
../cucumber-scala-2.9.2/src/scala

If this worked then you still only have a single body of code to maintain in the cucumber-scala-2.9.2/ tree.
If this pattern worked then you could break the source code out into an unversioned dir cucumber-scala/ but its a bit unconventional to have a source tree without a pom at the top. Would probably make life difficult for IDE's too.

This scales easily as if you need scala-2.9.3 then you just add another sibling skeleton directory for it.

Change the aggregator pom to build cucumber-scala-2.9.2/ and cucumber-scala-2.10/ instead of cucumber-scala/

I note ...
http://www.scala-sbt.org/release/docs/Detailed-Topics/Cross-Build.html
Also ..
http://stackoverflow.com/questions/13872226/how-to-support-multiple-scala-versions-in-a-library

Member

dkowis commented Feb 12, 2013

So I did a bit of investigation on this, we could simply include an additional pom file, scala-2.9.2.pom setting the appropriate scala version in it, and call it with mvn -f scala-2.9.2.pom however, the scala code base does not compile against 2.9.2. It appears that the current sources are using 2.10 specific code. Of course, this doesn't completely integrate, I'd have to find some way to call the second pom, as part of the normal build process.

Of course, disregarding that part, it doesn't even build:

java.lang.NoClassDefFoundError: scala/reflect/ClassManifest

java.lang.NoSuchMethodError: scala.collection.JavaConverters$.seqAsJavaListConverter(Lscala/collection/Seq;)Lscala/collection/JavaConverters$AsJava;

I think even if we could use a second pom to support 2.9.2, the source code itself doesn't. It would require two separate code bases, or using code that can work in both somehow. I'm not sure how to do that, too much of a noob at scala :(

Contributor

skipoleschris commented Feb 12, 2013

I think I've almost got a cross-build working that compiles from single source set using both Scala 2.10.0 and 2.9.2 and creates separate properly version numbered artifacts (e.g. cucumber-scala_2.10.0 and cucumber-scala_2.9.2). I'm just testing it out against my sbt cucumber plugin to make sure everything works and if it looks fine then I'll create a pull request in the next couple of days.

What I've managed to do is have the cucumber-jvm/scala directory with the src directory underneath. Then I've created separate scala_2.9.2 and scala_2.10.0 directories under cucumber-jvm/scala and these each contain a copy of the pom customised for the specific Scala version, but working off of the shared source. The two separate Scala modules are then referenced as separate modules from the main pom, built tested and packaged independently.

As an aside, the current Scala code seems to compile fine under both Scala 2.10.0 and 2.9.2 provided you get all the Scala library dependencies correct.

The only downside I have with my solution is that the Scala dependencies and versions are no longer in the root pom.xml file, which means they have to be defined in both scala pom.xml files and also the scala pom.xml in the examples directory. I'm trying to work out if there's a way around this.

skipoleschris added a commit to skipoleschris/cucumber-jvm that referenced this issue Feb 14, 2013

Proposed solution for issue #432
The main scala build has been modified to generate an artifact named cucumber-scala_2.10
A new sub-directory of the scala build has been created. This uses the same source files as its parent but builds a cucumber-scala_2.9.2 artifact using the Scala 2.9.2 compiler and library
To get this to work correctly the README.java and package.html files were moved into the scala source tree
The scala-calculator example was modified to use the cucumber-scala_2.10 artifact
The root pom.xml file no longer directly references Scala library dependencies as there are now different versions between the 2.10 and 2.9.2 build. (Is the a solution to this?)
Contributor

skipoleschris commented Feb 14, 2013

I added a pull request for this (#462). Welcome comments/suggestions as it's a long long time since I last used maven.

skipoleschris added a commit to skipoleschris/cucumber-jvm that referenced this issue Mar 11, 2013

Proposed solution for issue #432
The main scala build has been modified to generate an artifact named cucumber-scala_2.10
A new sub-directory of the scala build has been created. This uses the same source files as its parent but builds a cucumber-scala_2.9.2 artifact using the Scala 2.9.2 compiler and library
To get this to work correctly the README.java and package.html files were moved into the scala source tree
The scala-calculator example was modified to use the cucumber-scala_2.10 artifact
The root pom.xml file no longer directly references Scala library dependencies as there are now different versions between the 2.10 and 2.9.2 build. (Is the a solution to this?)

skipoleschris added a commit to skipoleschris/cucumber-jvm that referenced this issue Mar 11, 2013

Proposed solution for issue #432
The main scala build has been modified to generate an artifact named cucumber-scala_2.10
A new sub-directory of the scala build has been created. This uses the same source files as its parent but builds a cucumber-scala_2.9.2 artifact using the Scala 2.9.2 compiler and library
To get this to work correctly the README.java and package.html files were moved into the scala source tree
The scala-calculator example was modified to use the cucumber-scala_2.10 artifact
The root pom.xml file no longer directly references Scala library dependencies as there are now different versions between the 2.10 and 2.9.2 build. (Is the a solution to this?)

skipoleschris added a commit to skipoleschris/cucumber-jvm that referenced this issue Mar 11, 2013

Proposed solution for issue #432
The main scala build has been modified to generate an artifact named cucumber-scala_2.10
A new sub-directory of the scala build has been created. This uses the same source files as its parent but builds a cucumber-scala_2.9.2 artifact using the Scala 2.9.2 compiler and library
To get this to work correctly the README.java and package.html files were moved into the scala source tree
The scala-calculator example was modified to use the cucumber-scala_2.10 artifact
The root pom.xml file no longer directly references Scala library dependencies as there are now different versions between the 2.10 and 2.9.2 build. (Is the a solution to this?)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment