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 <irud...@gmail.com> 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 <r...@evosent.com> wrote:
>
> > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <irud...@gmail.com> 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
> >
>
