Include the scala version in the maven artefacts

[Johnlon]

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>

[aslakhellesoy]

Why?

[aslakhellesoy]

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

[aslakhellesoy]

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

[Johnlon]

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]

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.

[aslakhellesoy]

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?

[Johnlon]

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//issues/432#issuecomment-11531706.

[aslakhellesoy]

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.

[skipoleschris]

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]

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

[dkowis]

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 :(

[skipoleschris]

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]

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

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.