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
> > >
> >
>
