Ok, in case of using version & release plugins it's better just to reuse parent project version in all modules, as you previously mentioned.
Thus the main question is - if there are any specific cases for using "1" as a version number in parent POM? Cause such versioning schema also doesn't allow to use version & release plugins. Igor On Thu, Aug 18, 2016 at 4:06 PM, Raul Kripalani <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
