[WIP][SPARK-4428][BUILD] Use ${scala.binary.version} property for artifactId.

[ueshin]

No description provided.

[SparkQA]

Test build #23424 has started for PR 3285 at commit 8a0b059.

• This patch merges cleanly.

[ueshin]

I'm sorry but I'm not sure if we may use property for artifactId.
What do you think about this, reviewers?

[srowen]

Yes, I thought this was discussed and this doesn't work?

[SparkQA]

Test build #23424 has finished for PR 3285 at commit 8a0b059.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/23424/
Test PASSed.

[markhamstra]

@srowen is correct, this kind of parameterized artifactId has already been considered but is not permissible. Please close this PR.

[ueshin]

I see. I'll close this but can I have the pointer where you discussed about this?

[markhamstra]

That was quite awhile back and would require some searching of the mail archives and repo from when Spark was in the Apache incubator. I did what you did soon after we made the switch to Scala 2.10 (https://www.mail-archive.com/commits@spark.incubator.apache.org/msg01573.html), and this does work okay for local builds. But when it comes time to make a public release, the release tools will start complaining because artifactId's in released POMs must be fixed/stable. In later discussions, @pwendell and I determined that living with the annoyance of hard-coded Scala versions in the artifactId's was the best approach short of more involved POM re-writing tools.

[srowen]

@ueshin Have a look at this discussion, which was related at least: #2318 I can't find the thread where I believe Prashant said he found this doesn't work. (Try changing it locally and see what your installed POM looks like?)

[ueshin]

@markhamstra, @srowen, Thank you for the pointing. Now I'm closing this.