ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Rudyak <irud...@gmail.com>
Subject Re: Ignite Maven project version number
Date Fri, 19 Aug 2016 05:39:01 GMT
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 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" <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=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 <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 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 <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 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 <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 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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message