I disagree. It's all about using the tools for the job in the way they were intended to.
As I said, your approach does not allow us to (1) release the Ignite Parent POM, (2) use the version plugin, (3) use the release plugin. Moreover, your argument about copy-paste does not sustain. Because you would **never** manually change parent versions manually. You would use the versions plugin which performs a recursive batch change. Additionally, I am inclined to use patterns that are used widely in the OSS communities. I haven't found this to be the case. An n=1 experiment based on the experience of a given person doesn't hold enough value for me. Widely used patterns are the way to go. Community over individuals. Anyway, I am not going to pursue this topic any further, as the rest of the community doesn't seem to voice in, and I am not actively involved on a day-to-day basis enough to block a decision. However, I do want to register my refusal to this change just for the annals of the Ignite community. Cheers. On 18 Aug 2016 18:56, "Igor Rudyak" <[email protected]> wrote: > Well, it's all about how to minimize copy-pasting parent version to > constantly growing amount of module POMs while switching to development of > new version. > > Following your example with: > > *mvn clean install -Dapp.version=12893123* > > It looks like if somebody doing such things - he is likely doing it for > some specific purpose and not by mistake. Otherwise *${app.version}* is not > the only property defined in Maven project which we have problem with. > There are tons of properties specifying particular third-party artifacts > versions, which we depends on. For example: > > <karaf.version>4.0.2</karaf.version> > <lucene.bundle.version>3.5.0_1</lucene.bundle.version> > > > Thus overriding these properties the same way using command line args, > could produce unpredictable build or it even can fail to compile. > > Not sure if there are any Apache projects currently using such versioning > schema. Just found it rather useful in my own multi-module projects and > did't have any problems with it. Thus decided to introduce it to community. > > > Igor Rudyak > > > > > > On Thu, Aug 18, 2016 at 5:21 AM, Raul Kripalani <[email protected]> wrote: > > > Hi Igor, > > > > Unfortunately the ${app.version} approach does not play well with the > Maven > > ecosystem. The Maven release and versions plugins don't know to go into > an > > arbitrary property to bump up the version number. > > > > The goal with inlining the parent version numbers is to have a solid, > > traceable and automatable build and release process. With mvn > versions:set > > -DnewVersion=1.8.1-SNAPSHOT done from the top, the entire project tree is > > changed in one go. > > > > Also, you have made the build environment-dependant, which is an > > antipattern. You are introduced a variable that one can override with a > JVM > > property, e.g. mvn clean install -Dapp.version=12893123 and this will > > result in a different build. > > > > I'm not actively contributing to Ignite these days, but some things do > > catch my eyes. Particularly build-related stuff. In fact, I'm so opposed > to > > this change that I quite frankly consider vetoing it! > > > > BTW - can you point a few other projects that use this same build setup? > > > > Cheers. > > > > --- > > Raúl Kripalani > > linkedin.com/in/raulkripalani | evosent.com > > <http://evosent.com/?utm_source=email&utm_medium=email&; > > utm_campaign=evosent_raul> > > | blog: raul.io > > <http://raul.io?utm_source=email&utm_medium=email&utm_ > > campaign=evosent_raul> | > > > > s > > kype: raul.fuse > > > > On Thu, Aug 18, 2016 at 1:25 AM, Igor Rudyak <[email protected]> wrote: > > > > > Not sure about the original reason to fix version of parent POM. > > > > > > However the approach you proposed has one drawback comparing to > > > ${app.version} approach. We again need to copy-paste new parent version > > > number into all module POMs when start working on the next version. > > > > > > Here is more details: > > > > > > 1) Each module POM has such reference to parent: > > > > > > * <parent>* > > > * <groupId>org.apache.ignite</groupId>* > > > * <artifactId>ignite-parent</artifactId>* > > > * <version>1</version>* > > > * <relativePath>../parent</relativePath>* > > > * </parent>* > > > > > > 2) The main problem here is in *<version>* tag, where you need to > specify > > > parent project version > > > > > > 3) Thus if you are going to change parent version number you need to > > > copy-paste this number into ALL other POMs. > > > > > > 4) While using ${app.version} property defined in parent POM, you can > > just > > > reuse such common peace of configuration in all other POMs: > > > > > > *<parent>* > > > * <groupId>org.apache.ignite</groupId>* > > > * <artifactId>ignite-parent</artifactId>* > > > * <version>1</version>* > > > * <relativePath>../parent</relativePath>* > > > * </parent>* > > > > > > * <artifactId>my-module</artifactId>* > > > * <version>${app.version}</version>* > > > 5) Such a way, if you want switch to development of next version - you > > just > > > need to change ${app.version} property in parent POM and it will be > > > automatically "reused" by all other POMs. The benefit here is that we > > need > > > to change version number only in one place. > > > > > > > > > Igor Rudyak > > > > > > > > > On Wed, Aug 17, 2016 at 4:13 PM, Raul Kripalani <[email protected]> > > wrote: > > > > > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[email protected]> > > wrote: > > > > > > > > > It's not the solution in this case, cause parent version is always > > "1" > > > > > > > > > > > > > What's the reason we've chosen to handle the hierarchy differently to > > > most > > > > other projects out there? Have we considered versioning the parent > > POM? > > > > Doesn't a fixed 1 imply that it never evolves? > > > > > > > > Releasing the parent POM would also allow folks to create Ignite > > modules > > > > without forking the entire project, just by referencing a parent POM > > that > > > > is in Maven Central. > > > > > > > > Proposal: Set the project version in the parent POM and release it. > All > > > > children modules that inherit the parent will automatically inherit > the > > > > project version. Then we can forgo the ${app.version} property – > which > > > > quite frankly appears to be a code smell. > > > > > > > > Cheers. > > > > > > > > --- > > > > Raúl Kripalani > > > > linkedin.com/in/raulkripalani | evosent.com > > > > <http://evosent.com/?utm_source=email&utm_medium=email&; > > > > utm_campaign=evosent_raul> > > > > | blog: raul.io > > > > <http://raul.io?utm_source=email&utm_medium=email&utm_ > > > > campaign=evosent_raul> | > > > > skype: raul.fuse > > > > > > > > > >
