You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Igor Rudyak <ir...@gmail.com> on 2016/08/13 01:02:13 UTC
Ignite Maven project version number
Guys,
Found that each time after publishing new Ignite release and switching to
development of next version, version numbers are copy-pasted in all module
POMs. Isn't it better just to define project version variable in one
place(and change it in one place) to reuse it in module POMs?
For example, variable like ${app.version} could be defined in parent POM
and all module POMs can just reuse it like this:
* <artifactId>my-module</artifactId>*
* <version>${app.version}</version>*
Igor
Re: Ignite Maven project version number
Posted by Sergi Vladykin <se...@gmail.com>.
I'm not a Maven expert and do not see all the consequences, but so far
everything worked well. Why change it? Especially if we do not have a
consensus in our community. I think we can't accept this change until
everyone agrees.
Sergi
2016-08-19 10:28 GMT+03:00 Anton Vinogradov <av...@gridgain.com>:
> Igor,
>
>
> > 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.
>
> Don't worry about it, currently we use bash script to do that, it based
> on release:update-versions, and it will be relocated to Apache Ignite
> Teamcity in the nearest future.
>
> I executed tests for my pull request and here are the results:
> > http://149.202.210.143:8111/viewLog.html?buildId=301277&
> > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
>
> I see a lot of new failures with ClassNotFoundException.
>
> Thus the main question is - if there are any specific cases for using "1".
> > as a version number in parent POM?
>
> I set it to 1, because we never release it to maven and parent pom located
> at same project that other poms. At this moment no reason to change it from
> release to release.
>
>
>
>
> On Fri, Aug 19, 2016 at 9:20 AM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > Igor, Raul and Anton.
> >
> > As far as I remember we decided to have version in each module pom
> because
> > of some problem with maven release.
> >
> > So, we ALSO NEED CHECK RELEASE PROCEDURE and see will new approach work
> or
> > not.
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
Re: Ignite Maven project version number
Posted by Anton Vinogradov <av...@gridgain.com>.
Igor,
> 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.
Don't worry about it, currently we use bash script to do that, it based
on release:update-versions, and it will be relocated to Apache Ignite
Teamcity in the nearest future.
I executed tests for my pull request and here are the results:
> http://149.202.210.143:8111/viewLog.html?buildId=301277&
> tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
I see a lot of new failures with ClassNotFoundException.
Thus the main question is - if there are any specific cases for using "1".
> as a version number in parent POM?
I set it to 1, because we never release it to maven and parent pom located
at same project that other poms. At this moment no reason to change it from
release to release.
On Fri, Aug 19, 2016 at 9:20 AM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:
> Igor, Raul and Anton.
>
> As far as I remember we decided to have version in each module pom because
> of some problem with maven release.
>
> So, we ALSO NEED CHECK RELEASE PROCEDURE and see will new approach work or
> not.
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
Re: Ignite Maven project version number
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Igor, Raul and Anton.
As far as I remember we decided to have version in each module pom because
of some problem with maven release.
So, we ALSO NEED CHECK RELEASE PROCEDURE and see will new approach work or
not.
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
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 <ra...@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" <ir...@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 <ra...@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 <ir...@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 <ra...@evosent.com>
> > > wrote:
> > > >
> > > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> > > > >
> > > >
> > >
> >
>
Re: Ignite Maven project version number
Posted by Raul Kripalani <ra...@evosent.com>.
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" <ir...@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 <ra...@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 <ir...@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 <ra...@evosent.com>
> > wrote:
> > >
> > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> > > >
> > >
> >
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
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 <ra...@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 <ir...@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 <ra...@evosent.com>
> wrote:
> >
> > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> > >
> >
>
Re: Ignite Maven project version number
Posted by Raul Kripalani <ra...@evosent.com>.
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 <ir...@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 <ra...@evosent.com> wrote:
>
> > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> >
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Anton,
I executed tests for my pull request and here are the results:
http://149.202.210.143:8111/viewLog.html?buildId=301277&tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
It looks like there are some problems with *Snapshot dependecy*, but it's
not only specific to my pull request, but to default branch as well:
http://149.202.210.143:8111/viewLog.html?buildId=301183&tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
Igor
On Thu, Aug 18, 2016 at 12:27 AM, Anton Vinogradov <avinogradov@gridgain.com
> wrote:
> Hi all,
>
> 1) To run your pull request click "..." to the right of "Run" and chose
> Changes -> Default Branch -> pull/961/head
>
> 2) Parent pom version is 1 because it was stable solution while project
> grew extremely fast.
> I see no restrictions to change it, but we have to theck it works, twice.
> We need to check all tests works, then we'll need to make Test Release to
> check nothing broken at deployment.
>
>
> On Thu, Aug 18, 2016 at 3:25 AM, Igor Rudyak <ir...@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 <ra...@evosent.com>
> wrote:
> >
> > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> > >
> >
>
Re: Ignite Maven project version number
Posted by Anton Vinogradov <av...@gridgain.com>.
Hi all,
1) To run your pull request click "..." to the right of "Run" and chose
Changes -> Default Branch -> pull/961/head
2) Parent pom version is 1 because it was stable solution while project
grew extremely fast.
I see no restrictions to change it, but we have to theck it works, twice.
We need to check all tests works, then we'll need to make Test Release to
check nothing broken at deployment.
On Thu, Aug 18, 2016 at 3:25 AM, Igor Rudyak <ir...@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 <ra...@evosent.com> wrote:
>
> > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
> >
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
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 <ra...@evosent.com> wrote:
> On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
>
Re: Ignite Maven project version number
Posted by Raul Kripalani <ra...@evosent.com>.
On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <ir...@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
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Raul,
It's not the solution in this case, cause parent version is always "1"
Igor
On Wed, Aug 17, 2016 at 3:04 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Igor,
>
> To my knowledge, you can just remove the version tag altogether, and the
> module will inherit the version from the parent.
>
> 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
>
> On Wed, Aug 17, 2016 at 2:30 AM, Igor Rudyak <ir...@gmail.com> wrote:
>
> > Ok, created a pull request for this:
> > https://github.com/apache/ignite/pull/961
> >
> > Igor
> >
> > On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <ir...@gmail.com> wrote:
> >
> > > Ok, I created a ticket: https://issues.apache.org/
> > jira/browse/IGNITE-3701
> > >
> > > Igor
> > >
> > > On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com>
> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> avinogradov@gridgain.com> wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> We used this approach 1.5 years before, but had some problems with
> > >>> assemblying and deploying.
> > >>> I can't remember what type of problem it was, possible they are
> already
> > >>> solved.
> > >>>
> > >>> I think we should refactor master branch as Igor described and check
> it
> > >>> works.
> > >>>
> > >>> Igor,
> > >>> could you please implement it, check assemblying works (Ignite Fabric
> > >>> Maven
> > >>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
> > >>>
> > >>>
> > >>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com>
> > wrote:
> > >>> > >
> > >>> > > Guys,
> > >>> > >
> > >>> > > Found that each time after publishing new Ignite release and
> > >>> switching to
> > >>> > > development of next version, version numbers are copy-pasted in
> all
> > >>> > module
> > >>> > > POMs. Isn't it better just to define project version variable in
> > one
> > >>> > > place(and change it in one place) to reuse it in module POMs?
> > >>> > >
> > >>> > > For example, variable like ${app.version} could be defined in
> > parent
> > >>> POM
> > >>> > > and all module POMs can just reuse it like this:
> > >>> > >
> > >>> > > * <artifactId>my-module</artifactId>*
> > >>> > > * <version>${app.version}</version>*
> > >>> > >
> > >>> > > Igor
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Ignite Maven project version number
Posted by Raul Kripalani <ra...@evosent.com>.
Igor,
To my knowledge, you can just remove the version tag altogether, and the
module will inherit the version from the parent.
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
On Wed, Aug 17, 2016 at 2:30 AM, Igor Rudyak <ir...@gmail.com> wrote:
> Ok, created a pull request for this:
> https://github.com/apache/ignite/pull/961
>
> Igor
>
> On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <ir...@gmail.com> wrote:
>
> > Ok, I created a ticket: https://issues.apache.org/
> jira/browse/IGNITE-3701
> >
> > Igor
> >
> > On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com> wrote:
> >
> >> Ok, I'll create a ticket and implement it.
> >>
> >> Igor
> >>
> >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> >> avinogradov@gridgain.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> We used this approach 1.5 years before, but had some problems with
> >>> assemblying and deploying.
> >>> I can't remember what type of problem it was, possible they are already
> >>> solved.
> >>>
> >>> I think we should refactor master branch as Igor described and check it
> >>> works.
> >>>
> >>> Igor,
> >>> could you please implement it, check assemblying works (Ignite Fabric
> >>> Maven
> >>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
> >>>
> >>>
> >>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com>
> >>> wrote:
> >>>
> >>> > Anton, would you mind providing your thoughts on this.
> >>> >
> >>> > —
> >>> > Denis
> >>> >
> >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com>
> wrote:
> >>> > >
> >>> > > Guys,
> >>> > >
> >>> > > Found that each time after publishing new Ignite release and
> >>> switching to
> >>> > > development of next version, version numbers are copy-pasted in all
> >>> > module
> >>> > > POMs. Isn't it better just to define project version variable in
> one
> >>> > > place(and change it in one place) to reuse it in module POMs?
> >>> > >
> >>> > > For example, variable like ${app.version} could be defined in
> parent
> >>> POM
> >>> > > and all module POMs can just reuse it like this:
> >>> > >
> >>> > > * <artifactId>my-module</artifactId>*
> >>> > > * <version>${app.version}</version>*
> >>> > >
> >>> > > Igor
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Ignite Maven project version number
Posted by Denis Magda <dm...@gridgain.com>.
Igor,
You need to make a pull-request and choose the pull-request’s number as a branch name from TeamCity’s drop down list. Refer to this [1] section for more guidance.
[1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request
—
Denis
> On Aug 17, 2016, at 2:58 PM, Igor Rudyak <ir...@gmail.com> wrote:
>
> Anton,
>
> If I'll hit "Run" button in TeamCity on the right from "Run All" task, what git branch it will actually use? How can I specify "ignite-3701" branch from my GitHub repository to be used when running this build configuration in TeamCity?
>
> Igor
>
>
>
> On Wed, Aug 17, 2016 at 3:05 AM, Anton Vinogradov <avinogradov@gridgain.com <ma...@gridgain.com>> wrote:
> Igor,
> Pease check it at TeamCity, use Run All task.
>
> On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <irudyak@gmail.com <ma...@gmail.com>> wrote:
>
> > Ok, created a pull request for this:
> > https://github.com/apache/ignite/pull/961 <https://github.com/apache/ignite/pull/961>
> >
> > Igor
> >
> > On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <irudyak@gmail.com <ma...@gmail.com>> wrote:
> >
> > > Ok, I created a ticket: https://issues.apache.org/ <https://issues.apache.org/>
> > jira/browse/IGNITE-3701
> > >
> > > Igor
> > >
> > > On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <irudyak@gmail.com <ma...@gmail.com>> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> avinogradov@gridgain.com <ma...@gridgain.com>> wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> We used this approach 1.5 years before, but had some problems with
> > >>> assemblying and deploying.
> > >>> I can't remember what type of problem it was, possible they are already
> > >>> solved.
> > >>>
> > >>> I think we should refactor master branch as Igor described and check it
> > >>> works.
> > >>>
> > >>> Igor,
> > >>> could you please implement it, check assemblying works (Ignite Fabric
> > >>> Maven
> > >>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
> > >>>
> > >>>
> > >>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dmagda@gridgain.com <ma...@gridgain.com>>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <irudyak@gmail.com <ma...@gmail.com>>
> > wrote:
> > >>> > >
> > >>> > > Guys,
> > >>> > >
> > >>> > > Found that each time after publishing new Ignite release and
> > >>> switching to
> > >>> > > development of next version, version numbers are copy-pasted in all
> > >>> > module
> > >>> > > POMs. Isn't it better just to define project version variable in
> > one
> > >>> > > place(and change it in one place) to reuse it in module POMs?
> > >>> > >
> > >>> > > For example, variable like ${app.version} could be defined in
> > parent
> > >>> POM
> > >>> > > and all module POMs can just reuse it like this:
> > >>> > >
> > >>> > > * <artifactId>my-module</artifactId>*
> > >>> > > * <version>${app.version}</version>*
> > >>> > >
> > >>> > > Igor
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Anton,
If I'll hit "Run" button in TeamCity on the right from "Run All" task, what
git branch it will actually use? How can I specify "ignite-3701" branch
from my GitHub repository to be used when running this build configuration
in TeamCity?
Igor
On Wed, Aug 17, 2016 at 3:05 AM, Anton Vinogradov <av...@gridgain.com>
wrote:
> Igor,
> Pease check it at TeamCity, use Run All task.
>
> On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <ir...@gmail.com> wrote:
>
> > Ok, created a pull request for this:
> > https://github.com/apache/ignite/pull/961
> >
> > Igor
> >
> > On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <ir...@gmail.com> wrote:
> >
> > > Ok, I created a ticket: https://issues.apache.org/
> > jira/browse/IGNITE-3701
> > >
> > > Igor
> > >
> > > On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com>
> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> avinogradov@gridgain.com> wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> We used this approach 1.5 years before, but had some problems with
> > >>> assemblying and deploying.
> > >>> I can't remember what type of problem it was, possible they are
> already
> > >>> solved.
> > >>>
> > >>> I think we should refactor master branch as Igor described and check
> it
> > >>> works.
> > >>>
> > >>> Igor,
> > >>> could you please implement it, check assemblying works (Ignite Fabric
> > >>> Maven
> > >>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
> > >>>
> > >>>
> > >>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com>
> > wrote:
> > >>> > >
> > >>> > > Guys,
> > >>> > >
> > >>> > > Found that each time after publishing new Ignite release and
> > >>> switching to
> > >>> > > development of next version, version numbers are copy-pasted in
> all
> > >>> > module
> > >>> > > POMs. Isn't it better just to define project version variable in
> > one
> > >>> > > place(and change it in one place) to reuse it in module POMs?
> > >>> > >
> > >>> > > For example, variable like ${app.version} could be defined in
> > parent
> > >>> POM
> > >>> > > and all module POMs can just reuse it like this:
> > >>> > >
> > >>> > > * <artifactId>my-module</artifactId>*
> > >>> > > * <version>${app.version}</version>*
> > >>> > >
> > >>> > > Igor
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Ignite Maven project version number
Posted by Anton Vinogradov <av...@gridgain.com>.
Igor,
Pease check it at TeamCity, use Run All task.
On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <ir...@gmail.com> wrote:
> Ok, created a pull request for this:
> https://github.com/apache/ignite/pull/961
>
> Igor
>
> On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <ir...@gmail.com> wrote:
>
> > Ok, I created a ticket: https://issues.apache.org/
> jira/browse/IGNITE-3701
> >
> > Igor
> >
> > On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com> wrote:
> >
> >> Ok, I'll create a ticket and implement it.
> >>
> >> Igor
> >>
> >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> >> avinogradov@gridgain.com> wrote:
> >>
> >>> Hi All,
> >>>
> >>> We used this approach 1.5 years before, but had some problems with
> >>> assemblying and deploying.
> >>> I can't remember what type of problem it was, possible they are already
> >>> solved.
> >>>
> >>> I think we should refactor master branch as Igor described and check it
> >>> works.
> >>>
> >>> Igor,
> >>> could you please implement it, check assemblying works (Ignite Fabric
> >>> Maven
> >>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
> >>>
> >>>
> >>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com>
> >>> wrote:
> >>>
> >>> > Anton, would you mind providing your thoughts on this.
> >>> >
> >>> > —
> >>> > Denis
> >>> >
> >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com>
> wrote:
> >>> > >
> >>> > > Guys,
> >>> > >
> >>> > > Found that each time after publishing new Ignite release and
> >>> switching to
> >>> > > development of next version, version numbers are copy-pasted in all
> >>> > module
> >>> > > POMs. Isn't it better just to define project version variable in
> one
> >>> > > place(and change it in one place) to reuse it in module POMs?
> >>> > >
> >>> > > For example, variable like ${app.version} could be defined in
> parent
> >>> POM
> >>> > > and all module POMs can just reuse it like this:
> >>> > >
> >>> > > * <artifactId>my-module</artifactId>*
> >>> > > * <version>${app.version}</version>*
> >>> > >
> >>> > > Igor
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Ok, created a pull request for this:
https://github.com/apache/ignite/pull/961
Igor
On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak <ir...@gmail.com> wrote:
> Ok, I created a ticket: https://issues.apache.org/jira/browse/IGNITE-3701
>
> Igor
>
> On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com> wrote:
>
>> Ok, I'll create a ticket and implement it.
>>
>> Igor
>>
>> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
>> avinogradov@gridgain.com> wrote:
>>
>>> Hi All,
>>>
>>> We used this approach 1.5 years before, but had some problems with
>>> assemblying and deploying.
>>> I can't remember what type of problem it was, possible they are already
>>> solved.
>>>
>>> I think we should refactor master branch as Igor described and check it
>>> works.
>>>
>>> Igor,
>>> could you please implement it, check assemblying works (Ignite Fabric
>>> Maven
>>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>>>
>>>
>>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com>
>>> wrote:
>>>
>>> > Anton, would you mind providing your thoughts on this.
>>> >
>>> > —
>>> > Denis
>>> >
>>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com> wrote:
>>> > >
>>> > > Guys,
>>> > >
>>> > > Found that each time after publishing new Ignite release and
>>> switching to
>>> > > development of next version, version numbers are copy-pasted in all
>>> > module
>>> > > POMs. Isn't it better just to define project version variable in one
>>> > > place(and change it in one place) to reuse it in module POMs?
>>> > >
>>> > > For example, variable like ${app.version} could be defined in parent
>>> POM
>>> > > and all module POMs can just reuse it like this:
>>> > >
>>> > > * <artifactId>my-module</artifactId>*
>>> > > * <version>${app.version}</version>*
>>> > >
>>> > > Igor
>>> >
>>> >
>>>
>>
>>
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Ok, I created a ticket: https://issues.apache.org/jira/browse/IGNITE-3701
Igor
On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak <ir...@gmail.com> wrote:
> Ok, I'll create a ticket and implement it.
>
> Igor
>
> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> avinogradov@gridgain.com> wrote:
>
>> Hi All,
>>
>> We used this approach 1.5 years before, but had some problems with
>> assemblying and deploying.
>> I can't remember what type of problem it was, possible they are already
>> solved.
>>
>> I think we should refactor master branch as Igor described and check it
>> works.
>>
>> Igor,
>> could you please implement it, check assemblying works (Ignite Fabric
>> Maven
>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>>
>>
>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com> wrote:
>>
>> > Anton, would you mind providing your thoughts on this.
>> >
>> > —
>> > Denis
>> >
>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com> wrote:
>> > >
>> > > Guys,
>> > >
>> > > Found that each time after publishing new Ignite release and
>> switching to
>> > > development of next version, version numbers are copy-pasted in all
>> > module
>> > > POMs. Isn't it better just to define project version variable in one
>> > > place(and change it in one place) to reuse it in module POMs?
>> > >
>> > > For example, variable like ${app.version} could be defined in parent
>> POM
>> > > and all module POMs can just reuse it like this:
>> > >
>> > > * <artifactId>my-module</artifactId>*
>> > > * <version>${app.version}</version>*
>> > >
>> > > Igor
>> >
>> >
>>
>
>
Re: Ignite Maven project version number
Posted by Igor Rudyak <ir...@gmail.com>.
Ok, I'll create a ticket and implement it.
Igor
On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <avinogradov@gridgain.com
> wrote:
> Hi All,
>
> We used this approach 1.5 years before, but had some problems with
> assemblying and deploying.
> I can't remember what type of problem it was, possible they are already
> solved.
>
> I think we should refactor master branch as Igor described and check it
> works.
>
> Igor,
> could you please implement it, check assemblying works (Ignite Fabric Maven
> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>
>
> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > Anton, would you mind providing your thoughts on this.
> >
> > —
> > Denis
> >
> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com> wrote:
> > >
> > > Guys,
> > >
> > > Found that each time after publishing new Ignite release and switching
> to
> > > development of next version, version numbers are copy-pasted in all
> > module
> > > POMs. Isn't it better just to define project version variable in one
> > > place(and change it in one place) to reuse it in module POMs?
> > >
> > > For example, variable like ${app.version} could be defined in parent
> POM
> > > and all module POMs can just reuse it like this:
> > >
> > > * <artifactId>my-module</artifactId>*
> > > * <version>${app.version}</version>*
> > >
> > > Igor
> >
> >
>
Re: Ignite Maven project version number
Posted by Anton Vinogradov <av...@gridgain.com>.
Hi All,
We used this approach 1.5 years before, but had some problems with
assemblying and deploying.
I can't remember what type of problem it was, possible they are already
solved.
I think we should refactor master branch as Igor described and check it
works.
Igor,
could you please implement it, check assemblying works (Ignite Fabric Maven
Build Instructions section at DEVNOTES.txt) and create pullrequest?
On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda <dm...@gridgain.com> wrote:
> Anton, would you mind providing your thoughts on this.
>
> —
> Denis
>
> > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com> wrote:
> >
> > Guys,
> >
> > Found that each time after publishing new Ignite release and switching to
> > development of next version, version numbers are copy-pasted in all
> module
> > POMs. Isn't it better just to define project version variable in one
> > place(and change it in one place) to reuse it in module POMs?
> >
> > For example, variable like ${app.version} could be defined in parent POM
> > and all module POMs can just reuse it like this:
> >
> > * <artifactId>my-module</artifactId>*
> > * <version>${app.version}</version>*
> >
> > Igor
>
>
Re: Ignite Maven project version number
Posted by Denis Magda <dm...@gridgain.com>.
Anton, would you mind providing your thoughts on this.
—
Denis
> On Aug 12, 2016, at 6:02 PM, Igor Rudyak <ir...@gmail.com> wrote:
>
> Guys,
>
> Found that each time after publishing new Ignite release and switching to
> development of next version, version numbers are copy-pasted in all module
> POMs. Isn't it better just to define project version variable in one
> place(and change it in one place) to reuse it in module POMs?
>
> For example, variable like ${app.version} could be defined in parent POM
> and all module POMs can just reuse it like this:
>
> * <artifactId>my-module</artifactId>*
> * <version>${app.version}</version>*
>
> Igor