Apache Ignite Developers - Legacy Mail Archive

Ignite Maven project version number

Classic

List

Threaded

22 messages Options

irudyak

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

Denis Magda

Re: Ignite Maven project version number

Anton, would you mind providing your thoughts on this.

—
Denis

> On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]> 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

Anton Vinogradov

Re: Ignite Maven project version number

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 <[hidden email]> wrote:

> Anton, would you mind providing your thoughts on this.
>
> —
> Denis
>
> > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]> 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
>
>

irudyak

Re: Ignite Maven project version number

Ok, I'll create a ticket and implement it.

Igor

On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <[hidden email]
> 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 <[hidden email]> wrote:
>
> > Anton, would you mind providing your thoughts on this.
> >
> > —
> > Denis
> >
> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]> 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
> >
> >
>

irudyak

Re: Ignite Maven project version number

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 <[hidden email]> wrote:

> Ok, I'll create a ticket and implement it.
>
> Igor
>
> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> [hidden email]> 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 <[hidden email]> wrote:
>>
>> > Anton, would you mind providing your thoughts on this.
>> >
>> > —
>> > Denis
>> >
>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]> 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
>> >
>> >
>>
>
>

irudyak

Re: Ignite Maven project version number

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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> Ok, I'll create a ticket and implement it.
>>
>> Igor
>>
>> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
>> [hidden email]> 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 <[hidden email]>
>>> wrote:
>>>
>>> > Anton, would you mind providing your thoughts on this.
>>> >
>>> > —
>>> > Denis
>>> >
>>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]> 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
>>> >
>>> >
>>>
>>
>>
>

Anton Vinogradov

Re: Ignite Maven project version number

Igor,
Pease check it at TeamCity, use Run All task.

On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> >> Ok, I'll create a ticket and implement it.
> >>
> >> Igor
> >>
> >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> >> [hidden email]> 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 <[hidden email]>
> >>> wrote:
> >>>
> >>> > Anton, would you mind providing your thoughts on this.
> >>> >
> >>> > —
> >>> > Denis
> >>> >
> >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]>
> 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
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>

irudyak

Re: Ignite Maven project version number

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 <[hidden email]>
wrote:

> Igor,
> Pease check it at TeamCity, use Run All task.
>
> On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> [hidden email]> 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 <[hidden email]>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]>
> > 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
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Raul Kripalani-2

Re: Ignite Maven project version number

In reply to this post by irudyak

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 <[hidden email]> wrote:

Denis Magda

Re: Ignite Maven project version number

In reply to this post by irudyak

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> Igor,
> Pease check it at TeamCity, use Run All task.
>
> On Wed, Aug 17, 2016 at 4:30 AM, Igor Rudyak <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> [hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email] <mailto:[hidden email]>>
> > 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
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

irudyak

Re: Ignite Maven project version number

In reply to this post by Raul Kripalani-2

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> > >
> > >> Ok, I'll create a ticket and implement it.
> > >>
> > >> Igor
> > >>
> > >> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> > >> [hidden email]> 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 <[hidden email]>
> > >>> wrote:
> > >>>
> > >>> > Anton, would you mind providing your thoughts on this.
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak <[hidden email]>
> > 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
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Raul Kripalani-2

Re: Ignite Maven project version number

On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]> 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

irudyak

Re: Ignite Maven project version number

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 <[hidden email]> wrote:

> On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]> 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
>

Anton Vinogradov

Re: Ignite Maven project version number

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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]> 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
> >
>

Raul Kripalani-2

Re: Ignite Maven project version number

In reply to this post by irudyak

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 <[hidden email]> wrote:

irudyak

Re: Ignite Maven project version number

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]>
> 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
> > >
> >
>

irudyak

Re: Ignite Maven project version number

In reply to this post by Anton Vinogradov

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 <[hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]>
> 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
> > >
> >
>

Raul Kripalani-2

Re: Ignite Maven project version number

In reply to this post by irudyak

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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> > >
> > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]>
> > 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
> > > >
> > >
> >
>

irudyak

Re: Ignite Maven project version number

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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> > > wrote:
> > > >
> > > > > On Wed, Aug 17, 2016 at 11:14 PM, Igor Rudyak <[hidden email]>
> > > 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
> > > > >
> > > >
> > >
> >
>

Alexey Kuznetsov-2

Re: Ignite Maven project version number

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