I've got an interesting challenge in building Spark. For various reasons we do a few different builds of spark, typically with a few different profile options (e.g. against different versions of Hadoop, some with/without Hive etc.). We mirror the spark repo internally and have a buildserver that builds and publishes different Spark versions to an artifactory server. The problem is that the output of each build is published with the version that is in the pom.xml file - a build of Spark @tags/v1.4.1 always comes out with an artefact version of '1.4.1'. However, because we may have three different Spark builds for 1.4.1, it'd be useful to be able to override this version at build time, so that we can publish 1.4.1, 1.4.1-cdh5.3.3 and maybe 1.4.1-cdh5.3.3-hive as separate artifacts.
My understanding of maven is that the /project/version value in the pom.xml isn't overridable. At the moment, I've hacked around this by having a pre-build task that rewrites the various pom files and adjust the version to a string that's correct for that particular build. Would it be useful to instead populate the version from a maven property, which could then be overridable on the CLI? Something like: <project> <version>${spark.version}</version> <properties> <spark.version>1.4.1</version> </properties> </project> Then, if I wanted to do a build against a specific profile, I could also pass in a -Dspark.version=1.4.1-custom-string and have the output artifacts correctly named. The default behaviour should be the same. Child pom files would need to reference ${spark.version} in their parent section I think. Any objections to this? Andrew
smime.p7s
Description: S/MIME cryptographic signature