You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by stephenc <gi...@git.apache.org> on 2015/07/22 10:53:03 UTC

[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

GitHub user stephenc opened a pull request:

    https://github.com/apache/maven/pull/60

    [MNG-5840] Parent version is a range hack

    - I don't like this, but it does let all the integration tests pass:
    
    ```
    Running org.apache.maven.it.MavenITmng2199ParentVersionRangeTest
    mng2199ParentVersionRange(ValidParentVersionRangeWithInclusiveUpperBound)OK (3.7 s)
    mng2199ParentVersionRange(ValidParentVersionRangeWithExclusiveUpperBound)OK (1.7 s)
    mng2199ParentVersionRange(InvalidParentVersionRange)........OK (0.7 s)
    mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionExpression)OK (0.5 s)
    mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionInheritance)OK (0.4 s)
    mng2199ParentVersionRange(ValidLocalParentVersionRange).....OK (0.4 s)
    Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.509 sec - in org.apache.maven.it.MavenITmng2199ParentVersionRangeTest
    Running org.apache.maven.it.MavenITmng5840ParentVersionRanges
    mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK (0.4 s)
    mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK (0.4 s)
    Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.784 sec - in org.apache.maven.it.MavenITmng5840ParentVersionRanges
    Running org.apache.maven.it.MavenITmng5840RelativePathReactorMatching
    mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)OK (0.4 s)
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec - in org.apache.maven.it.MavenITmng5840RelativePathReactorMatching
    ```
    
    I have created this as a pull request because I do not like the dependency change it requires.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/stephenc/maven mng-5840-version-range-hack

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/maven/pull/60.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #60
    
----
commit fc4e341322d708225724363c757012b405cff99e
Author: Stephen Connolly <st...@gmail.com>
Date:   2015-07-22T08:52:01Z

    [MNG-5840] Parent version is a range hack
    
    - I don't like this, but it does let all the integration tests pass:
    
    Running org.apache.maven.it.MavenITmng2199ParentVersionRangeTest
    mng2199ParentVersionRange(ValidParentVersionRangeWithInclusiveUpperBound)OK (3.7 s)
    mng2199ParentVersionRange(ValidParentVersionRangeWithExclusiveUpperBound)OK (1.7 s)
    mng2199ParentVersionRange(InvalidParentVersionRange)........OK (0.7 s)
    mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionExpression)OK (0.5 s)
    mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionInheritance)OK (0.4 s)
    mng2199ParentVersionRange(ValidLocalParentVersionRange).....OK (0.4 s)
    Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.509 sec - in org.apache.maven.it.MavenITmng2199ParentVersionRangeTest
    Running org.apache.maven.it.MavenITmng5840ParentVersionRanges
    mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK (0.4 s)
    mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK (0.4 s)
    Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.784 sec - in org.apache.maven.it.MavenITmng5840ParentVersionRanges
    Running org.apache.maven.it.MavenITmng5840RelativePathReactorMatching
    mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)OK (0.4 s)
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec - in org.apache.maven.it.MavenITmng5840RelativePathReactorMatching

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by bastiao <gi...@git.apache.org>.
Github user bastiao commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-167913767
  
     https://github.com/kilokahn/maven-testers/tree/master/foo-parent 
    
    this code does not work in 3.3.9 :( 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by stephenc <gi...@git.apache.org>.
Github user stephenc commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-123696060
  
    @ifedorenko I've simplified this per your comments... still feel that adding the dependency on maven-artifact is not the correct thing... but it is a semi-reasonable fix


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by bastiao <gi...@git.apache.org>.
Github user bastiao commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-167973833
  
    Yes, you are right.
    
    But In childs I would like to use:
    
        <parent>
            <artifactId>foo-parent</artifactId>
                    <version>${global.version}</version>
            <groupId>com.kilo</groupId>
        </parent>
    
    ${global.version} is defined in parent pom.xml.
    
    It compiles in 3.3.3 but not in 3.3.9 :-(


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by ifedorenko <gi...@git.apache.org>.
Github user ifedorenko commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-123711202
  
    What other options do we have? I guess we can create new `maven-versioning` module, move `org.apache.maven.artifact.versioning` implementation there and change maven-artifact to delegate to the new code. This is the only "clean" solution I can think of, but I do not have time to do this now and not sure new module with only a handful of classes is justifiable.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by khmarbaise <gi...@git.apache.org>.
Github user khmarbaise commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-167975254
  
    So we are talking about something completely different. I have cloned the given repository `https://github.com/kilokahn/maven-testers/` and i can't find a definition for `global.version` ? If you like to use something like above you have to use predefined placeholders ([revision, changelist, sha1](http://maven.apache.org/docs/3.2.1/release-notes.html#Continuous_delivery_friendly_versions_MNG-5576)) so you can call maven like this:
    
        mvn -Drevision=1.0-SNAPSHOT clean package 
    
    which is already available since Maven 3.2.1...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Stephen Connolly <st...@gmail.com>.
On 29 July 2015 at 13:10, Stephen Connolly <st...@gmail.com>
wrote:

> So I hit the original MNG-5840 with non-version range parents doing
> something like the following.
>
> git clone {parent,client,server}
>
> Note that client and server both have
> <relativePath>../parent/pom.xml</relativePath>
>
> Working away on server I spot a critical bug that needs fixing.
>
> cd server
> git stash # so that I can switch branches easily
> git checkout stable
> git stash pop # recover my WIP
> git add -p # add only the fix from the large set of unrelated changes
> git commit -m "critical fix"
> git stash # so that I can take the remaining WIP back to master
> git checkout master
> git merge stable # we always merge from stable up to master
> git checkout stable
> mvn release:prepare release:perform
> git checkout master
> git merge -s ours stable # mark the pom changes for release as merged
> git push origin stable master
> git stash pop # recover the WIP and clear the stash list
> cd ..
>
> and continue working
>
> I expect that the `mvn release:prepare release:perform` will be ok... but
> the release:prepare blew up because parent's stable branch doesn't have the
> same findbugs sensitivity and as a result when using the newer release of
> parent the build fails due to the findbugs complaining about potential null
> pointers that are not actual null pointers.
>

In case somebody asks, the reason I cannot just do

cd ../parent && git checkout stable && cd ..

is that in my case there are about 30 modules inter-related like this and
they all have different degrees of WIP which would need to be stashed
before switching branches... and in any case I would actually have to check
out the corresponding release version tags and not the stable branch as
that will have -SNAPSHOT versions and may have unreleased changes


>
> Now I'd be ok if we got as far as release:perform as that would be in
> stable/target/checkout and thus that would be forced to resolve the
> referenced pom... but that is just luck.
>
> There are all sorts of changes that I might have made in the master branch
> of parent... I may have changed the dependency management... and thus I
> could be using methods that are not available in the stable branch so that
> release:prepare will work but release:perform will fail to compile.
>
> It is not reasonable to expect me to have to set up a separate clone of
> the project just for maintenance porting.
>
> Now we could make the change for MNG-5840 just check if the parent version
> contains one of the following characters [ ( or , since if any of those
> three characters are missing it must be a single version. That would avoid
> needing maven-artifact's version range parser... BUT now I cannot use
> parent version ranges with my workflow above... and having been burned
> multiple times by this issue I would not be happy to ship a release that
> let any MNG-5840 style failures fall through.
>
> On 29 July 2015 at 01:11, Jason van Zyl <ja...@takari.io> wrote:
>
>> At first blush this change seems like a bad idea to me. I consider the
>> reactor/multi-module project an atomic unit and this change runs counter to
>> that. Why do you want a parent installed instead of everything working
>> cohesively within the reactor?
>>
>> Are you trying to build part of the tree for some reason and cannot build
>> it all together? Or are you stepping into a module and trying to build it
>> by itself? I understand that there are limitations and there needs to be a
>> way to build within the context of a reactor regardless of where you are
>> but I’m not sure I want us to have to support this feature forever.
>>
>> Can you provide a little more background please.
>>
>> > On Jul 23, 2015, at 2:06 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>> >
>> > It's not completely ugly, but it does entangle dependencies further
>> which I
>> > view as ugly.
>> >
>> > There is an existing todo above this code to move the validation to a
>> > different module, so I believe this will all get removed at that time
>> >
>> > On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com>
>> wrote:
>> >
>> >> If this change is so ugly, why are there no  comments explaining the
>> ugly?
>> >> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org
>> <javascript:;>>
>> >> wrote:
>> >>
>> >>> Github user jvanzyl commented on the pull request:
>> >>>
>> >>>    https://github.com/apache/maven/pull/60#issuecomment-124129817
>> >>>
>> >>>    I'm out in the middle of nowhere, but i'll cancel the vote, test
>> and
>> >>> re-roll once I'm back to civilization.
>> >>>
>> >>>
>> >>> ---
>> >>> If your project is set up for it, you can reply to this email and have
>> >> your
>> >>> reply appear on GitHub as well. If your project does not have this
>> >> feature
>> >>> enabled and wishes so, or if the feature is enabled but not working,
>> >> please
>> >>> contact infrastructure at infrastructure@apache.org <javascript:;> or
>> >> file a JIRA ticket
>> >>> with INFRA.
>> >>> ---
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> <javascript:;>
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> <javascript:;>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > Sent from my phone
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> happiness is like a butterfly: the more you chase it, the more it will
>> elude you, but if you turn your attention to other things, it will come
>> and sit softly on your shoulder ...
>>
>> -- Thoreau
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Stephen Connolly <st...@gmail.com>.
So I hit the original MNG-5840 with non-version range parents doing
something like the following.

git clone {parent,client,server}

Note that client and server both have
<relativePath>../parent/pom.xml</relativePath>

Working away on server I spot a critical bug that needs fixing.

cd server
git stash # so that I can switch branches easily
git checkout stable
git stash pop # recover my WIP
git add -p # add only the fix from the large set of unrelated changes
git commit -m "critical fix"
git stash # so that I can take the remaining WIP back to master
git checkout master
git merge stable # we always merge from stable up to master
git checkout stable
mvn release:prepare release:perform
git checkout master
git merge -s ours stable # mark the pom changes for release as merged
git push origin stable master
git stash pop # recover the WIP and clear the stash list
cd ..

and continue working

I expect that the `mvn release:prepare release:perform` will be ok... but
the release:prepare blew up because parent's stable branch doesn't have the
same findbugs sensitivity and as a result when using the newer release of
parent the build fails due to the findbugs complaining about potential null
pointers that are not actual null pointers.

Now I'd be ok if we got as far as release:perform as that would be in
stable/target/checkout and thus that would be forced to resolve the
referenced pom... but that is just luck.

There are all sorts of changes that I might have made in the master branch
of parent... I may have changed the dependency management... and thus I
could be using methods that are not available in the stable branch so that
release:prepare will work but release:perform will fail to compile.

It is not reasonable to expect me to have to set up a separate clone of the
project just for maintenance porting.

Now we could make the change for MNG-5840 just check if the parent version
contains one of the following characters [ ( or , since if any of those
three characters are missing it must be a single version. That would avoid
needing maven-artifact's version range parser... BUT now I cannot use
parent version ranges with my workflow above... and having been burned
multiple times by this issue I would not be happy to ship a release that
let any MNG-5840 style failures fall through.

On 29 July 2015 at 01:11, Jason van Zyl <ja...@takari.io> wrote:

> At first blush this change seems like a bad idea to me. I consider the
> reactor/multi-module project an atomic unit and this change runs counter to
> that. Why do you want a parent installed instead of everything working
> cohesively within the reactor?
>
> Are you trying to build part of the tree for some reason and cannot build
> it all together? Or are you stepping into a module and trying to build it
> by itself? I understand that there are limitations and there needs to be a
> way to build within the context of a reactor regardless of where you are
> but I’m not sure I want us to have to support this feature forever.
>
> Can you provide a little more background please.
>
> > On Jul 23, 2015, at 2:06 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> >
> > It's not completely ugly, but it does entangle dependencies further
> which I
> > view as ugly.
> >
> > There is an existing todo above this code to move the validation to a
> > different module, so I believe this will all get removed at that time
> >
> > On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com>
> wrote:
> >
> >> If this change is so ugly, why are there no  comments explaining the
> ugly?
> >> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org <javascript:;>>
> >> wrote:
> >>
> >>> Github user jvanzyl commented on the pull request:
> >>>
> >>>    https://github.com/apache/maven/pull/60#issuecomment-124129817
> >>>
> >>>    I'm out in the middle of nowhere, but i'll cancel the vote, test and
> >>> re-roll once I'm back to civilization.
> >>>
> >>>
> >>> ---
> >>> If your project is set up for it, you can reply to this email and have
> >> your
> >>> reply appear on GitHub as well. If your project does not have this
> >> feature
> >>> enabled and wishes so, or if the feature is enabled but not working,
> >> please
> >>> contact infrastructure at infrastructure@apache.org <javascript:;> or
> >> file a JIRA ticket
> >>> with INFRA.
> >>> ---
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> <javascript:;>
> >>>
> >>>
> >>
> >
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Jason van Zyl <ja...@takari.io>.
I look local to mean “local repository” which is bad. Dealing with things only in terms of the reactor/MMP is the only thing that makes sense.

> On Jul 28, 2015, at 9:34 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> 
> I am not sure I understand your concerns. Consider the following simple
> source tree with a parent and single child project
> 
>    some:parent:1.2.3
>      some:module parent=some:parent:[1.0,2.0)
> 
> Before this change Maven simply ignored local some:parent:1.2.3 when
> building the module and always attempted to resolve
> some:parent:[1.0,2.0) from repositories. With this change Maven resolves
> some:parent:[1.0,2.0) from the source tree as expected.
> 
> Or did I misunderstand the problem?
> 
> -- 
> Regards,
> Igor
> 
> On Tue, Jul 28, 2015, at 08:11 PM, Jason van Zyl wrote:
>> At first blush this change seems like a bad idea to me. I consider the
>> reactor/multi-module project an atomic unit and this change runs counter
>> to that. Why do you want a parent installed instead of everything working
>> cohesively within the reactor? 
>> 
>> Are you trying to build part of the tree for some reason and cannot build
>> it all together? Or are you stepping into a module and trying to build it
>> by itself? I understand that there are limitations and there needs to be
>> a way to build within the context of a reactor regardless of where you
>> are but I’m not sure I want us to have to support this feature forever.
>> 
>> Can you provide a little more background please.
>> 
>>> On Jul 23, 2015, at 2:06 PM, Stephen Connolly <st...@gmail.com> wrote:
>>> 
>>> It's not completely ugly, but it does entangle dependencies further which I
>>> view as ugly.
>>> 
>>> There is an existing todo above this code to move the validation to a
>>> different module, so I believe this will all get removed at that time
>>> 
>>> On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com> wrote:
>>> 
>>>> If this change is so ugly, why are there no  comments explaining the ugly?
>>>> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org <javascript:;>>
>>>> wrote:
>>>> 
>>>>> Github user jvanzyl commented on the pull request:
>>>>> 
>>>>>   https://github.com/apache/maven/pull/60#issuecomment-124129817
>>>>> 
>>>>>   I'm out in the middle of nowhere, but i'll cancel the vote, test and
>>>>> re-roll once I'm back to civilization.
>>>>> 
>>>>> 
>>>>> ---
>>>>> If your project is set up for it, you can reply to this email and have
>>>> your
>>>>> reply appear on GitHub as well. If your project does not have this
>>>> feature
>>>>> enabled and wishes so, or if the feature is enabled but not working,
>>>> please
>>>>> contact infrastructure at infrastructure@apache.org <javascript:;> or
>>>> file a JIRA ticket
>>>>> with INFRA.
>>>>> ---
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:;>
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Sent from my phone
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> happiness is like a butterfly: the more you chase it, the more it will
>> elude you, but if you turn your attention to other things, it will come
>> and sit softly on your shoulder ...
>> 
>> -- Thoreau 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

A language that doesn’t affect the way you think about programming is not worth knowing. 
 
 -- Alan Perlis













---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I am not sure I understand your concerns. Consider the following simple
source tree with a parent and single child project

    some:parent:1.2.3
      some:module parent=some:parent:[1.0,2.0)

Before this change Maven simply ignored local some:parent:1.2.3 when
building the module and always attempted to resolve
some:parent:[1.0,2.0) from repositories. With this change Maven resolves
some:parent:[1.0,2.0) from the source tree as expected.

Or did I misunderstand the problem?

-- 
Regards,
Igor

On Tue, Jul 28, 2015, at 08:11 PM, Jason van Zyl wrote:
> At first blush this change seems like a bad idea to me. I consider the
> reactor/multi-module project an atomic unit and this change runs counter
> to that. Why do you want a parent installed instead of everything working
> cohesively within the reactor? 
> 
> Are you trying to build part of the tree for some reason and cannot build
> it all together? Or are you stepping into a module and trying to build it
> by itself? I understand that there are limitations and there needs to be
> a way to build within the context of a reactor regardless of where you
> are but I’m not sure I want us to have to support this feature forever.
> 
> Can you provide a little more background please.
> 
> > On Jul 23, 2015, at 2:06 PM, Stephen Connolly <st...@gmail.com> wrote:
> > 
> > It's not completely ugly, but it does entangle dependencies further which I
> > view as ugly.
> > 
> > There is an existing todo above this code to move the validation to a
> > different module, so I believe this will all get removed at that time
> > 
> > On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com> wrote:
> > 
> >> If this change is so ugly, why are there no  comments explaining the ugly?
> >> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org <javascript:;>>
> >> wrote:
> >> 
> >>> Github user jvanzyl commented on the pull request:
> >>> 
> >>>    https://github.com/apache/maven/pull/60#issuecomment-124129817
> >>> 
> >>>    I'm out in the middle of nowhere, but i'll cancel the vote, test and
> >>> re-roll once I'm back to civilization.
> >>> 
> >>> 
> >>> ---
> >>> If your project is set up for it, you can reply to this email and have
> >> your
> >>> reply appear on GitHub as well. If your project does not have this
> >> feature
> >>> enabled and wishes so, or if the feature is enabled but not working,
> >> please
> >>> contact infrastructure at infrastructure@apache.org <javascript:;> or
> >> file a JIRA ticket
> >>> with INFRA.
> >>> ---
> >>> 
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> <javascript:;>
> >>> 
> >>> 
> >> 
> > 
> > 
> > -- 
> > Sent from my phone
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
> 
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
> 
> -- Thoreau 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Jason van Zyl <ja...@takari.io>.
At first blush this change seems like a bad idea to me. I consider the reactor/multi-module project an atomic unit and this change runs counter to that. Why do you want a parent installed instead of everything working cohesively within the reactor? 

Are you trying to build part of the tree for some reason and cannot build it all together? Or are you stepping into a module and trying to build it by itself? I understand that there are limitations and there needs to be a way to build within the context of a reactor regardless of where you are but I’m not sure I want us to have to support this feature forever.

Can you provide a little more background please.

> On Jul 23, 2015, at 2:06 PM, Stephen Connolly <st...@gmail.com> wrote:
> 
> It's not completely ugly, but it does entangle dependencies further which I
> view as ugly.
> 
> There is an existing todo above this code to move the validation to a
> different module, so I believe this will all get removed at that time
> 
> On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com> wrote:
> 
>> If this change is so ugly, why are there no  comments explaining the ugly?
>> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org <javascript:;>>
>> wrote:
>> 
>>> Github user jvanzyl commented on the pull request:
>>> 
>>>    https://github.com/apache/maven/pull/60#issuecomment-124129817
>>> 
>>>    I'm out in the middle of nowhere, but i'll cancel the vote, test and
>>> re-roll once I'm back to civilization.
>>> 
>>> 
>>> ---
>>> If your project is set up for it, you can reply to this email and have
>> your
>>> reply appear on GitHub as well. If your project does not have this
>> feature
>>> enabled and wishes so, or if the feature is enabled but not working,
>> please
>>> contact infrastructure at infrastructure@apache.org <javascript:;> or
>> file a JIRA ticket
>>> with INFRA.
>>> ---
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>>> 
>>> 
>> 
> 
> 
> -- 
> Sent from my phone

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 













---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Stephen Connolly <st...@gmail.com>.
It's not completely ugly, but it does entangle dependencies further which I
view as ugly.

There is an existing todo above this code to move the validation to a
different module, so I believe this will all get removed at that time

On Thursday, July 23, 2015, Benson Margulies <bi...@gmail.com> wrote:

> If this change is so ugly, why are there no  comments explaining the ugly?
> On Jul 23, 2015 10:48 AM, "jvanzyl" <git@git.apache.org <javascript:;>>
> wrote:
>
> > Github user jvanzyl commented on the pull request:
> >
> >     https://github.com/apache/maven/pull/60#issuecomment-124129817
> >
> >     I'm out in the middle of nowhere, but i'll cancel the vote, test and
> > re-roll once I'm back to civilization.
> >
> >
> > ---
> > If your project is set up for it, you can reply to this email and have
> your
> > reply appear on GitHub as well. If your project does not have this
> feature
> > enabled and wishes so, or if the feature is enabled but not working,
> please
> > contact infrastructure at infrastructure@apache.org <javascript:;> or
> file a JIRA ticket
> > with INFRA.
> > ---
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>


-- 
Sent from my phone

Re: [GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by Benson Margulies <bi...@gmail.com>.
If this change is so ugly, why are there no  comments explaining the ugly?
On Jul 23, 2015 10:48 AM, "jvanzyl" <gi...@git.apache.org> wrote:

> Github user jvanzyl commented on the pull request:
>
>     https://github.com/apache/maven/pull/60#issuecomment-124129817
>
>     I'm out in the middle of nowhere, but i'll cancel the vote, test and
> re-roll once I'm back to civilization.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by jvanzyl <gi...@git.apache.org>.
Github user jvanzyl commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-124129817
  
    I'm out in the middle of nowhere, but i'll cancel the vote, test and re-roll once I'm back to civilization.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:

    https://github.com/apache/maven/pull/60


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by stephenc <gi...@git.apache.org>.
Github user stephenc commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-124128970
  
    After no comments against merging this and with @ifedorenko saying go for it I decided to merge... if people object they can revert it out. I am not in love with this fix but it will be fine IMHO for 3.3.6


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[GitHub] maven pull request: [MNG-5840] Parent version is a range hack

Posted by khmarbaise <gi...@git.apache.org>.
Github user khmarbaise commented on the pull request:

    https://github.com/apache/maven/pull/60#issuecomment-167972348
  
    The problem is simply related to using the version `0.0.2-SNAPSHOT` in foo-business instead of `0.0.3-SNASPHOT` as parent version which will never work...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org