Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cucumber scala tweaks #868

Merged
merged 5 commits into from
May 29, 2015
Merged

Cucumber scala tweaks #868

merged 5 commits into from
May 29, 2015

Conversation

dkowis
Copy link
Member

@dkowis dkowis commented May 25, 2015

Made some changes as to how the cucumber-scala artifacts are created.

Specifically, now it's a hierarchy of maven poms, with a second aggregator used to build the individual projects, and the shared sources moved into a sources directory.

Additionally I'm using pluginManagement to avoid copy/pasta for the plugins that generate the I18n sources and the actual building of scala itself. The only dependencies listed in the scala_ projects are the scala versions themselves. This is far more scalable than "current" and "previous" we had before, and it makes it easier to know obviously which version of scala we're building against.

I also fixed one compile time flag, since it was talking about using scala 2.9 and we're only building for 2.10 and above.

Finally, I added the milestone of scala 2.12 in there, because I wanted to see it build us an artifact for it :D

This uses a second level for aggregation of shared items, sources,
dependencies, and build plugins.

Then the individual projects actually produce the artifacts, using the
properties defined in the parent level. (Could probably pull those up
entirely, since the project names describe what scala version we're
using.)

This is a bit more descriptive than before, since we're almost into
scala 2.12.
I think it makes more sense to set them in the individual projects.
@dkowis
Copy link
Member Author

dkowis commented May 25, 2015

Hm, I just realized that the example project is using the parameter for the "scala current version"

Opinions on just using a 2.11.6 fixed value for it instead? Otherwise, I should have three example projects one for each scala version and I think that's silly.

@paoloambrosio
Copy link
Member

+1 Very neat!

Regarding the example, I had the same thought. Either the scala binary version (2.11) should be computed from scala.latest.version (and in Maven it's just overkill) or it should be independent. I would hardcode 2.11.6 as you suggested. At least if we forget to update the example pom it will be correct and in sync.

dkowis added a commit that referenced this pull request May 29, 2015
@dkowis dkowis merged commit 68fcd5e into cucumber:master May 29, 2015
@dkowis dkowis deleted the cucumber-scala-tweaks branch May 29, 2015 01:38
@lock
Copy link

lock bot commented Oct 25, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants