Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKoNANuvSMhwMK5q=d2-n3SmMQqWyKO1GXR3dF5pjXSuL+PUvw@mail.gmail.com>
References: <CAMpMOYFh2yWPUszRGGhK2AxPxb5ncejknGvoxLc-+Sznc6MrAw@mail.gmail.com>
 <2D2FB566-6663-43D9-8239-46B09D2F9D68@gridgain.com> <CAOKDqC_rpcedjU-jMHZFCXAEZFv_kUSvbhM5ybhZL8Xi8rKa7A@mail.gmail.com>
 <CAMpMOYFaPR0n0as3e2jcNGkkhbrBG9XLQaM=1ZW7Lq1GLmNLug@mail.gmail.com>
 <CAMpMOYHHCKSrfpu1iw3Qn-B+bx996d9djCiTX6a2D2SOcYRXUA@mail.gmail.com>
 <CAMpMOYHJ+Uc24rB-Pa4PBKqSYWNy45MUkzSZHrSdcyr6onyqow@mail.gmail.com>
 <CAKoNANuubK8bmEzOUDJncpnQbaMujLeziityu48uA_M+Uf8HPQ@mail.gmail.com>
 <CAMpMOYGmB+8vinstVrRcuMoVq=AmjX71ZX8+yRHV0F6E7-doSg@mail.gmail.com>
 <CAKoNANs7DadKy78tViMEaBXnJdF4TLuKdo2zDuHowAiwxCmP=g@mail.gmail.com>
 <CAMpMOYG+-OgF-W=-9phK0_sH_hxsdi8rC72iaiMooiHTzdFS1w@mail.gmail.com>
 <CAKoNANtqqziDWOkOFpSU6Ou_NcL6L3_FB0Fc79xfZzvhsWjb5w@mail.gmail.com>
 <CAMpMOYEKHtpE2MXGQewiejd-F6dkrbKHsgx8-DKPJfdrNbK8uA@mail.gmail.com> <CAKoNANuvSMhwMK5q=d2-n3SmMQqWyKO1GXR3dF5pjXSuL+PUvw@mail.gmail.com>
From: Igor Rudyak <irudyak@gmail.com>
Date: Thu, 18 Aug 2016 22:39:01 -0700
Message-ID: <CAMpMOYEGb7xKWduo3drVYL2OkH8MQhUiF5FztCAj+_NKUOxYoA@mail.gmail.com>
Subject: Re: Ignite Maven project version number
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c03fe2ad124cf053a661eb0
archived-at: Fri, 19 Aug 2016 05:39:29 -0000

--94eb2c03fe2ad124cf053a661eb0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <raul@evosent.com> wrote:

> I disagree. It's all about using the tools for the job in the way they we=
re
> intended to.
>
> As I said, your approach does not allow us to (1) release the Ignite Pare=
nt
> 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 t=
he
> versions plugin which performs a recursive batch change.
>
> Additionally, I am inclined to use patterns that are used widely in the O=
SS
> communities. I haven't found this to be the case. An n=3D1 experiment bas=
ed
> 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 t=
he
> 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" <irudyak@gmail.com> 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=3D12893123*
> >
> > 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 artifact=
s
> > 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 versioni=
ng
> > 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 <raul@evosent.com>
> 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 in=
to
> > 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=3D1.8.1-SNAPSHOT done from the top, the entire project t=
ree
> 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=3D12893123 and this wi=
ll
> > > result in a different build.
> > >
> > > I'm not actively contributing to Ignite these days, but some things d=
o
> > > 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=C3=BAl Kripalani
> > > linkedin.com/in/raulkripalani | evosent.com
> > > <http://evosent.com/?utm_source=3Demail&utm_medium=3Demail&
> > > utm_campaign=3Devosent_raul>
> > > | blog: raul.io
> > > <http://raul.io?utm_source=3Demail&utm_medium=3Demail&utm_
> > > campaign=3Devosent_raul> |
> > >
> > > =E2=80=8Bs
> > > kype: raul.fuse
> > >
> > > On Thu, Aug 18, 2016 at 1:25 AM, Igor Rudyak <irudyak@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 t=
o
> > > > copy-paste this number into ALL other POMs.
> > > >
> > > > 4) While using ${app.version} property defined in parent POM, you c=
an
> > > 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 <raul@evosent.com>
> > > wrote:
> > > >
> > > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <irudyak@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 differentl=
y
> to
> > > > most
> > > > > other projects out there? =E2=80=8BHave 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 i=
t.
> > All
> > > > > children modules that inherit the parent will automatically inher=
it
> > the
> > > > > project version. Then we can forgo the ${app.version} property =
=E2=80=93
> > which
> > > > > quite frankly appears to be a code smell.
> > > > >
> > > > > Cheers.
> > > > >
> > > > > ---
> > > > > Ra=C3=BAl Kripalani
> > > > > linkedin.com/in/raulkripalani | evosent.com
> > > > > <http://evosent.com/?utm_source=3Demail&utm_medium=3Demail&
> > > > > utm_campaign=3Devosent_raul>
> > > > > | blog: raul.io
> > > > > <http://raul.io?utm_source=3Demail&utm_medium=3Demail&utm_
> > > > > campaign=3Devosent_raul> |
> > > > > skype: raul.fuse
> > > > >
> > > >
> > >
> >
>

--94eb2c03fe2ad124cf053a661eb0--