Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Fred Cooke]

Got it! Thanks. The dependency without [] needs to exist, but may not end
up being used due to conflicts. Fair enough. :-)

On Sat, Aug 6, 2016 at 3:24 PM, Christian Schulte  wrote:

> Am 08/06/16 um 05:15 schrieb Christian Schulte:
> > It just takes the highest version the version range resolver returns and
> uses that or fails if nothing like that is available.
>
> If using version range syntax.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Christian Schulte]

Am 08/06/16 um 05:15 schrieb Christian Schulte:
> It just takes the highest version the version range resolver returns and uses 
> that or fails if nothing like that is available.

If using version range syntax.


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

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Christian Schulte]

Am 08/06/16 um 02:04 schrieb Fred Cooke:
> A parent, I thought, used to be equivalent to [], ie, hard requirement. A
> dependency without [] is NOT a hard requirement, simply advisory. So yeah,
> they're different, or were. I wonder what semantics the ranged parents
> behaviour has for a simple backward compatible (or not) plain version?

There shouldn't be a difference. There is no conflict resolution or
anything like that when it comes to parents. It just takes the highest
version the version range resolver returns and uses that or fails if
nothing like that is available.

Regards,
-- 
Christian


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

Re: opinions on MJAVADOC-451

[Chas Honton]

+1

Chas

> On Aug 5, 2016, at 7:37 AM, Christopher  wrote:
> 
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.
> 
>> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>> 
>> Anyone want to give this a quick read/opinion? :-)
>> 
>> -Richard
>> 
>> -- Original Message --
>> 
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>> 
>>> Hi all,
>>> 
>>> I'd like to ask for opinions on
>>> https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>>> I have been discussing this off list and essentially disagree on it.
>>> 
>>> The request is very simple - to add a "skip" parameter to the
>>> javadoc:fix goal. In my projects we are using the fix goal unattended,
>>> i.e. with the parameter "force=true", as part of the regular build
>>> lifecycle.
>>> 
>>> Most goals (including javadoc) that run in the regular lifecycle have a
>>> skip option. Robert's position (and forgive me if I misrepresent this
>>> at all Robert and please weigh in) is that javadoc:fix should not be
>>> used in the lifecycle and that the goal should in fact have
>>> requireDirectInvocation=true. He also pointed out to me that I can
>>> create a profile to enable/disable the goal as an alternative.
>>> 
>>> My opinion is that, since the goal does not require direct invocation,
>>> then running within the lifecycle has to be considered acceptable use
>>> of the goal. And having a skip parameter adds 5 lines of code, is a
>>> common and normal pattern used by many other plugins/goals, and allows
>>> the goal to be used in this fashion without introducing even more
>>> profiles.
>>> 
>>> I've submitted patches for this issue and also several other issues in
>>> the javadoc plugin as I continue to work through getting the goal to
>>> work well automated. Just pointing out that I'm not just asking for the
>>> larger community to do stuff to make my life easier - I'm trying to
>>> contribute as best I can and provide patches for what I uncover.
>>> 
>>> Best regards,
>>> 
>>> Richard
>>> 
>>> 

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

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Fred Cooke]

A parent, I thought, used to be equivalent to [], ie, hard requirement. A
dependency without [] is NOT a hard requirement, simply advisory. So yeah,
they're different, or were. I wonder what semantics the ranged parents
behaviour has for a simple backward compatible (or not) plain version?
Implicitly converted to []? In any case, you solved your issue with
something that makes sense, good.

On Sat, Aug 6, 2016 at 10:02 AM, Thiebaud, Christophe <
christophe.thieb...@sap.com> wrote:

> Sorry, I strongly disagree, dependency is not optional.
>
> If there were not a valid, higher resolution path, the build would fail as
> well.
>
> Regards,
> Christophe
>
> -Original Message-
> From: Christian Schulte [mailto:c...@schulte.it]
> Sent: Freitag, 5. August 2016 16:33
> To: Maven Developers List 
> Subject: Re: project having a dependency with a version range fails
> building when parent pom of dependency is evicted from remote repo
>
> Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe:
> > ... oh ... I was 200% sure that parent did not allow a version range ...
>
> Introduced in Maven 3.2.2. Broken since a few releases. Fixed in
> 3.4.0-SNAPSHOT.
>
> >
> > I tried, -> BUILD SUCCESS.
> >
> > Hourah, and thanks.
> >
> > Let see now if this option is ok with our developers.
> >
> > In any case, don't you think there is some valid reason to fill a jira
> entry ?
>
> Issue is the repository being in an inconsistent state. It would not
> have been possible to deploy lib-1.0-SNAPSHOT without its parent being
> available in the repository.
>
> > I mean, iterating over a set of possible resolutions should not fail if
> one of the set fails, but if no acceptable resolution is found at the end,
> no ?
> >
> > In fact, this is what happen when the (failing) parent relationship is
> replaced with a (failing as well) dependency relationship.
>
> What exactly do you mean with "failing as well"? There is a difference
> between not finding a dependency and not finding a parent. The first is
> comparable to an "optional file not found" whereas the parent is nothing
> optional.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: opinions on MJAVADOC-451

[Gary Gregory]

On Fri, Aug 5, 2016 at 3:51 PM, Christopher  wrote:

> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory 
> wrote:
>
> > On Aug 5, 2016 7:41 AM, "Benson Margulies" 
> wrote:
> > >
> > > On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
> > wrote:
> > > > I'm always in favor of adding skip properties. They are very useful
> for
> > > > manipulating builds for debugging, running on CI servers, controlling
> > > > executions in child poms, etc. Even if it's not recommended to run
> > > > unattended, it's still possible, so a skip option is useful.
> > >
> > > Me too.  I don't see the point about arguing that some goal 'doesn't
> > > belong in a lifecycle'. We can't predict what people will find useful.
> >
> > Why not add the ability to skip various (named) activities to maven
> itself?
> >
>
> That exists. It's called profiles... but it's very verbose in the POM. It's
> much more pleasant to work with if the behavior of the individual plugin is
> flexible through configuration.
>

Editing a POM is way too heavy-handed IMO when I want to skip this and that
while I am experimenting with a build or debugging a build.

2c,
Gary

A feature could be added to Maven to skip specific named executions of

> plugins, I suppose... but that sounds like a feature that would require
> some discussion and debate before showing up in some future version of
> Maven. The proposal is something which could be done today, which would
> work, regardless of the version of Maven you're using, and which is
> consistent with similar configurable behavior in countless existing
> plugins.
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: opinions on MJAVADOC-451

[Richard Sand]

What about putting the skip option into an abstract base plugin class? Just 
thinking out loud

Sent from my iPhone

> On Aug 5, 2016, at 6:51 PM, Christopher  wrote:
> 
>> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory  wrote:
>> 
>>> On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
>>> 
>>> On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
>> wrote:
 I'm always in favor of adding skip properties. They are very useful for
 manipulating builds for debugging, running on CI servers, controlling
 executions in child poms, etc. Even if it's not recommended to run
 unattended, it's still possible, so a skip option is useful.
>>> 
>>> Me too.  I don't see the point about arguing that some goal 'doesn't
>>> belong in a lifecycle'. We can't predict what people will find useful.
>> 
>> Why not add the ability to skip various (named) activities to maven itself?
> 
> That exists. It's called profiles... but it's very verbose in the POM. It's
> much more pleasant to work with if the behavior of the individual plugin is
> flexible through configuration.
> 
> A feature could be added to Maven to skip specific named executions of
> plugins, I suppose... but that sounds like a feature that would require
> some discussion and debate before showing up in some future version of
> Maven. The proposal is something which could be done today, which would
> work, regardless of the version of Maven you're using, and which is
> consistent with similar configurable behavior in countless existing plugins.

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

Re: opinions on MJAVADOC-451

[Christopher]

On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory  wrote:

> On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
> >
> > On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
> wrote:
> > > I'm always in favor of adding skip properties. They are very useful for
> > > manipulating builds for debugging, running on CI servers, controlling
> > > executions in child poms, etc. Even if it's not recommended to run
> > > unattended, it's still possible, so a skip option is useful.
> >
> > Me too.  I don't see the point about arguing that some goal 'doesn't
> > belong in a lifecycle'. We can't predict what people will find useful.
>
> Why not add the ability to skip various (named) activities to maven itself?
>

That exists. It's called profiles... but it's very verbose in the POM. It's
much more pleasant to work with if the behavior of the individual plugin is
flexible through configuration.

A feature could be added to Maven to skip specific named executions of
plugins, I suppose... but that sounds like a feature that would require
some discussion and debate before showing up in some future version of
Maven. The proposal is something which could be done today, which would
work, regardless of the version of Maven you're using, and which is
consistent with similar configurable behavior in countless existing plugins.

RE: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Thiebaud, Christophe]

Sorry, I strongly disagree, dependency is not optional. 

If there were not a valid, higher resolution path, the build would fail as well.

Regards,
Christophe

-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Freitag, 5. August 2016 16:33
To: Maven Developers List 
Subject: Re: project having a dependency with a version range fails building 
when parent pom of dependency is evicted from remote repo

Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe:
> ... oh ... I was 200% sure that parent did not allow a version range ...

Introduced in Maven 3.2.2. Broken since a few releases. Fixed in
3.4.0-SNAPSHOT.

> 
> I tried, -> BUILD SUCCESS.
> 
> Hourah, and thanks.
> 
> Let see now if this option is ok with our developers.
> 
> In any case, don't you think there is some valid reason to fill a jira entry ?

Issue is the repository being in an inconsistent state. It would not
have been possible to deploy lib-1.0-SNAPSHOT without its parent being
available in the repository.

> I mean, iterating over a set of possible resolutions should not fail if one 
> of the set fails, but if no acceptable resolution is found at the end, no ?
> 
> In fact, this is what happen when the (failing) parent relationship is 
> replaced with a (failing as well) dependency relationship.

What exactly do you mean with "failing as well"? There is a difference
between not finding a dependency and not finding a parent. The first is
comparable to an "optional file not found" whereas the parent is nothing
optional.

Regards,
-- 
Christian


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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Stephen Connolly]

+1

On 5 August 2016 at 14:34, Tamás Cservenák  wrote:

> ... Mercury
>
> On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl  wrote:
>
> > When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
> > Tycho. None of them very useful for people to understand what they
> actually
> > do. I think I’m done with catchy names. I’m old.
> >
> >
>

Re: PR Inquiry

[Rajiv Jain]

Hi Herve

I have appended some things on this ticket. Please take a look.

I will have some more answers soon.

Thanks.

Regards,
Rajiv

> On 4 Aug 2016, at 22:50, herve.bout...@free.fr wrote:
> 
> Hi,
> 
> Please have a look at answers from Robert and myself on 
> https://issues.apache.org/jira/browse/MDEP-519 (for the second PR)
> 
> Regards,
> 
> Hervé
> 
> - Mail original -
> De: "Rajiv Jain" 
> À: "Maven Developers List" 
> Envoyé: Jeudi 4 Août 2016 22:45:40
> Objet: PR Inquiry
> 
> Hi
> 
> I opened 2 pull requests and wanted to chase up whether somebody can look 
> over it? I believe that it can be merged in.
> 
> My company is dependent on some changes. I have made some changes that I 
> think will make the fix.
> 
> The pull requests are https://github.com/apache/maven/pull/88 
>  (opened 17 days ago) and 
> https://github.com/apache/maven/pull/91 
> .
> 
> I hope to hear positively from you soon.
> 
> Thanks.
> 
> Regards,
> Rajiv
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: opinions on MJAVADOC-451

[Gary Gregory]

On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
>
> On Fri, Aug 5, 2016 at 10:37 AM, Christopher  wrote:
> > I'm always in favor of adding skip properties. They are very useful for
> > manipulating builds for debugging, running on CI servers, controlling
> > executions in child poms, etc. Even if it's not recommended to run
> > unattended, it's still possible, so a skip option is useful.
>
> Me too.  I don't see the point about arguing that some goal 'doesn't
> belong in a lifecycle'. We can't predict what people will find useful.

Why not add the ability to skip various (named) activities to maven itself?

Gary
>
> >
> > On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
> >
> >> Anyone want to give this a quick read/opinion? :-)
> >>
> >> -Richard
> >>
> >> -- Original Message --
> >>
> >> From: "Richard Sand" 
> >> To: dev@maven.apache.org
> >> Sent: 8/1/2016 6:33:30 PM
> >> Subject: opinions on MJAVADOC-451
> >>
> >> >Hi all,
> >> >
> >> >I'd like to ask for opinions on
> >> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
> >> >I have been discussing this off list and essentially disagree on it.
> >> >
> >> >The request is very simple - to add a "skip" parameter to the
> >> >javadoc:fix goal. In my projects we are using the fix goal unattended,
> >> >i.e. with the parameter "force=true", as part of the regular build
> >> >lifecycle.
> >> >
> >> >Most goals (including javadoc) that run in the regular lifecycle have
a
> >> >skip option. Robert's position (and forgive me if I misrepresent this
> >> >at all Robert and please weigh in) is that javadoc:fix should not be
> >> >used in the lifecycle and that the goal should in fact have
> >> >requireDirectInvocation=true. He also pointed out to me that I can
> >> >create a profile to enable/disable the goal as an alternative.
> >> >
> >> >My opinion is that, since the goal does not require direct invocation,
> >> >then running within the lifecycle has to be considered acceptable use
> >> >of the goal. And having a skip parameter adds 5 lines of code, is a
> >> >common and normal pattern used by many other plugins/goals, and allows
> >> >the goal to be used in this fashion without introducing even more
> >> >profiles.
> >> >
> >> >I've submitted patches for this issue and also several other issues in
> >> >the javadoc plugin as I continue to work through getting the goal to
> >> >work well automated. Just pointing out that I'm not just asking for
the
> >> >larger community to do stuff to make my life easier - I'm trying to
> >> >contribute as best I can and provide patches for what I uncover.
> >> >
> >> >Best regards,
> >> >
> >> >Richard
> >> >
> >> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: opinions on MJAVADOC-451

[Benson Margulies]

On Fri, Aug 5, 2016 at 10:37 AM, Christopher  wrote:
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.

Me too.  I don't see the point about arguing that some goal 'doesn't
belong in a lifecycle'. We can't predict what people will find useful.

>
> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>
>> Anyone want to give this a quick read/opinion? :-)
>>
>> -Richard
>>
>> -- Original Message --
>>
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>>
>> >Hi all,
>> >
>> >I'd like to ask for opinions on
>> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>> >I have been discussing this off list and essentially disagree on it.
>> >
>> >The request is very simple - to add a "skip" parameter to the
>> >javadoc:fix goal. In my projects we are using the fix goal unattended,
>> >i.e. with the parameter "force=true", as part of the regular build
>> >lifecycle.
>> >
>> >Most goals (including javadoc) that run in the regular lifecycle have a
>> >skip option. Robert's position (and forgive me if I misrepresent this
>> >at all Robert and please weigh in) is that javadoc:fix should not be
>> >used in the lifecycle and that the goal should in fact have
>> >requireDirectInvocation=true. He also pointed out to me that I can
>> >create a profile to enable/disable the goal as an alternative.
>> >
>> >My opinion is that, since the goal does not require direct invocation,
>> >then running within the lifecycle has to be considered acceptable use
>> >of the goal. And having a skip parameter adds 5 lines of code, is a
>> >common and normal pattern used by many other plugins/goals, and allows
>> >the goal to be used in this fashion without introducing even more
>> >profiles.
>> >
>> >I've submitted patches for this issue and also several other issues in
>> >the javadoc plugin as I continue to work through getting the goal to
>> >work well automated. Just pointing out that I'm not just asking for the
>> >larger community to do stuff to make my life easier - I'm trying to
>> >contribute as best I can and provide patches for what I uncover.
>> >
>> >Best regards,
>> >
>> >Richard
>> >
>> >

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

Re: opinions on MJAVADOC-451

[Christopher]

I'm always in favor of adding skip properties. They are very useful for
manipulating builds for debugging, running on CI servers, controlling
executions in child poms, etc. Even if it's not recommended to run
unattended, it's still possible, so a skip option is useful.

On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:

> Anyone want to give this a quick read/opinion? :-)
>
> -Richard
>
> -- Original Message --
>
> From: "Richard Sand" 
> To: dev@maven.apache.org
> Sent: 8/1/2016 6:33:30 PM
> Subject: opinions on MJAVADOC-451
>
> >Hi all,
> >
> >I'd like to ask for opinions on
> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
> >I have been discussing this off list and essentially disagree on it.
> >
> >The request is very simple - to add a "skip" parameter to the
> >javadoc:fix goal. In my projects we are using the fix goal unattended,
> >i.e. with the parameter "force=true", as part of the regular build
> >lifecycle.
> >
> >Most goals (including javadoc) that run in the regular lifecycle have a
> >skip option. Robert's position (and forgive me if I misrepresent this
> >at all Robert and please weigh in) is that javadoc:fix should not be
> >used in the lifecycle and that the goal should in fact have
> >requireDirectInvocation=true. He also pointed out to me that I can
> >create a profile to enable/disable the goal as an alternative.
> >
> >My opinion is that, since the goal does not require direct invocation,
> >then running within the lifecycle has to be considered acceptable use
> >of the goal. And having a skip parameter adds 5 lines of code, is a
> >common and normal pattern used by many other plugins/goals, and allows
> >the goal to be used in this fashion without introducing even more
> >profiles.
> >
> >I've submitted patches for this issue and also several other issues in
> >the javadoc plugin as I continue to work through getting the goal to
> >work well automated. Just pointing out that I'm not just asking for the
> >larger community to do stuff to make my life easier - I'm trying to
> >contribute as best I can and provide patches for what I uncover.
> >
> >Best regards,
> >
> >Richard
> >
> >

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Christian Schulte]

Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe:
> ... oh ... I was 200% sure that parent did not allow a version range ...

Introduced in Maven 3.2.2. Broken since a few releases. Fixed in
3.4.0-SNAPSHOT.

> 
> I tried, -> BUILD SUCCESS.
> 
> Hourah, and thanks.
> 
> Let see now if this option is ok with our developers.
> 
> In any case, don't you think there is some valid reason to fill a jira entry ?

Issue is the repository being in an inconsistent state. It would not
have been possible to deploy lib-1.0-SNAPSHOT without its parent being
available in the repository.

> I mean, iterating over a set of possible resolutions should not fail if one 
> of the set fails, but if no acceptable resolution is found at the end, no ?
> 
> In fact, this is what happen when the (failing) parent relationship is 
> replaced with a (failing as well) dependency relationship.

What exactly do you mean with "failing as well"? There is a difference
between not finding a dependency and not finding a parent. The first is
comparable to an "optional file not found" whereas the parent is nothing
optional.

Regards,
-- 
Christian


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

RE: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Thiebaud, Christophe]

... oh ... I was 200% sure that parent did not allow a version range ...

I tried, -> BUILD SUCCESS.

Hourah, and thanks.

Let see now if this option is ok with our developers.

In any case, don't you think there is some valid reason to fill a jira entry ?

I mean, iterating over a set of possible resolutions should not fail if one of 
the set fails, but if no acceptable resolution is found at the end, no ?

In fact, this is what happen when the (failing) parent relationship is replaced 
with a (failing as well) dependency relationship.

I understand that the root cause is that failing to build the pom is considered 
an error that stops the whole process, 
whereas failing to resolve a transitive dependency just marks this particular 
resolution path as unacceptable, and continue the search.

IMHO, the behavior should not depend on the type of relationship (parent vs.  
dependency).
behavior should be the same in both cases, and I vote for continuing the 
version range resolution until the end.

Thanks!
Christophe


-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Freitag, 5. August 2016 14:32
To: Maven Developers List 
Subject: Re: project having a dependency with a version range fails building 
when parent pom of dependency is evicted from remote repo

You maybe also could overcome this by using parent version ranges.

Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe:
> Reading Aether documentation : 
> 
> https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
> 
> looks that aether has been thought to manage this kind of issue:
> 
> « For each direct dependency, a dependency selector is given a chance to 
> exclude the dependency from the graph »
> 
> Any hint if and how it is possible to configure aether to ignore 'lib' 
> 0.0.1-SNAPSHOT when resolving the version range ?
> 
> Thanks
> Christophe
> 
> -Original Message-
> From: Thiebaud, Christophe [mailto:christophe.thieb...@sap.com] 
> Sent: Donnerstag, 4. August 2016 16:03
> To: Maven Developers List 
> Cc: Schmoigl, Dominic ; Holl, Marcus 
> 
> Subject: RE: project having a dependency with a version range fails building 
> when parent pom of dependency is evicted from remote repo
> 
> Hi Christian,
> 
> Thanks for the hint to try  maven 3.4.0-SNAPSHOT
> 
> I tried, and the result is again BUILD FAILURE - but with a nice colored 
> system out, and - more seriously - a different, and IMHO misleading, error 
> message.
> 
> (Cf. full reproducible commands at 
> https://github.com/iroif/iroif-parent/blob/master/README.md  , starting below 
> " To reproduce the issue")
> 
> ---
> maven 3.4.0-SNAPSHOT
> 
> $ mvn clean install -s ../iroif-parent/settings.xml 
> -Dmaven.repo.local=/c/tmp/iroif-app-xxx
> 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.075 s
> [INFO] Finished at: 2016-08-04T15:37:25+02:00
> [INFO] Final Memory: 26M/456M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project iroif-app: Could not resolve 
> dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
> Could not find artifact net.aequologica.iroif:iroif-lib:jar:0.0.2-SNAPSHOT -> 
> [Help 1]
> [ERROR]
> 
> -
> maven 3.3.9
> 
> $ mvn clean install -s ../iroif-parent/settings.xml 
> -Dmaven.repo.local=/c/tmp/iroif-app-yyy
> 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.810 s
> [INFO] Finished at: 2016-08-04T16:01:14+02:00
> [INFO] Final Memory: 21M/289M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project iroif-app: Could not resolve 
> dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
> Failed to collect dependencies at 
> net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Failed to read artifact 
> descriptor for net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Could not 
> find artifact net.aequologica.iroif:iroif-parent:pom:0.0.1-SNAPSHOT in 
> local_nexus (http://localhost:1082/nexus/content/groups/public/) -> [Help 1]
> [ERROR]
> 
> Also, the -U (--update snapshots) parameter makes no difference, as a new, 
> fresh local repo is created for each command of the scripts to reproduce the 
> issue.
> 
> Thanks
> Christophe
> 
> -Original Message-
> From: Christian Schulte [mailto:c...@schulte.it] 
> Sent: Donnerstag, 4. August 2016 13:00
> To: Maven Developers List 
> Subject: Re: project having a dependency with a version range fails 

Re: Upgrading m-pmd-p - PMD 5.5.1

[Gary Gregory]

On Aug 5, 2016 2:56 AM, "Andreas Dangel"  wrote:
>
> Hi all,
>
>
> I want to implement https://issues.apache.org/jira/browse/MPMD-220 -
> which is upgrading the m-pmd-p to use the latest PMD version.
>
> As of PMD 5.4.x, the minimum java runtime is 7, so I would upgrade the
> plugin accordingly.
>
> m-pmd-p 3.6 would be the last version, that supports Java 6. From
> m-pmd-p 3.7 on, at least Java 7 will be required.
>
> Any thoughts on that?

Yes please :-)

Gary
>
>
> Regards,
>
> Andreas
>
>
> --
> Andreas Dangel
> https://github.com/adangel
> skype: andreas_dangel
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: [DISCUSSION] finishing Aether import: help find a new name

[Tamás Cservenák]

... Mercury

On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl  wrote:

> When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
> Tycho. None of them very useful for people to understand what they actually
> do. I think I’m done with catchy names. I’m old.
>
>

AW: [DISCUSSION] finishing Aether import: help find a new name

[Christofer Dutz]

AIR could be something Adobe might have a problem with ...


Chris


Von: Jörg Schaible 
Gesendet: Freitag, 5. August 2016 14:54:29
An: dev@maven.apache.org
Betreff: Re: [DISCUSSION] finishing Aether import: help find a new name

Uwe Barthel wrote:

> Hi,
>
>> Eclipse owns the Aether name. We cannot use the name Aether.
>
> And the Eclipse Foundation doesn't like to provide that name to the ASF
> (only the name without the eclipse namespace)?
>
> Aethel means over the AIR.
>
> WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more
> general than resolve?
>
> -- barthel

Prepend 'M' ... ;-)

Mare

M_aven
A_rtefact
RE_solver

- Jörg


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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jörg Schaible]

Uwe Barthel wrote:

> Hi,
> 
>> Eclipse owns the Aether name. We cannot use the name Aether.
> 
> And the Eclipse Foundation doesn't like to provide that name to the ASF
> (only the name without the eclipse namespace)?
> 
> Aethel means over the AIR.
> 
> WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more
> general than resolve?
> 
> -- barthel

Prepend 'M' ... ;-)

Mare

M_aven
A_rtefact
RE_solver

- Jörg


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

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Christian Schulte]

You maybe also could overcome this by using parent version ranges.

Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe:
> Reading Aether documentation : 
> 
> https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
> 
> looks that aether has been thought to manage this kind of issue:
> 
> « For each direct dependency, a dependency selector is given a chance to 
> exclude the dependency from the graph »
> 
> Any hint if and how it is possible to configure aether to ignore 'lib' 
> 0.0.1-SNAPSHOT when resolving the version range ?
> 
> Thanks
> Christophe
> 
> -Original Message-
> From: Thiebaud, Christophe [mailto:christophe.thieb...@sap.com] 
> Sent: Donnerstag, 4. August 2016 16:03
> To: Maven Developers List 
> Cc: Schmoigl, Dominic ; Holl, Marcus 
> 
> Subject: RE: project having a dependency with a version range fails building 
> when parent pom of dependency is evicted from remote repo
> 
> Hi Christian,
> 
> Thanks for the hint to try  maven 3.4.0-SNAPSHOT
> 
> I tried, and the result is again BUILD FAILURE - but with a nice colored 
> system out, and - more seriously - a different, and IMHO misleading, error 
> message.
> 
> (Cf. full reproducible commands at 
> https://github.com/iroif/iroif-parent/blob/master/README.md  , starting below 
> " To reproduce the issue")
> 
> ---
> maven 3.4.0-SNAPSHOT
> 
> $ mvn clean install -s ../iroif-parent/settings.xml 
> -Dmaven.repo.local=/c/tmp/iroif-app-xxx
> 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.075 s
> [INFO] Finished at: 2016-08-04T15:37:25+02:00
> [INFO] Final Memory: 26M/456M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project iroif-app: Could not resolve 
> dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
> Could not find artifact net.aequologica.iroif:iroif-lib:jar:0.0.2-SNAPSHOT -> 
> [Help 1]
> [ERROR]
> 
> -
> maven 3.3.9
> 
> $ mvn clean install -s ../iroif-parent/settings.xml 
> -Dmaven.repo.local=/c/tmp/iroif-app-yyy
> 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.810 s
> [INFO] Finished at: 2016-08-04T16:01:14+02:00
> [INFO] Final Memory: 21M/289M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project iroif-app: Could not resolve 
> dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
> Failed to collect dependencies at 
> net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Failed to read artifact 
> descriptor for net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Could not 
> find artifact net.aequologica.iroif:iroif-parent:pom:0.0.1-SNAPSHOT in 
> local_nexus (http://localhost:1082/nexus/content/groups/public/) -> [Help 1]
> [ERROR]
> 
> Also, the -U (--update snapshots) parameter makes no difference, as a new, 
> fresh local repo is created for each command of the scripts to reproduce the 
> issue.
> 
> Thanks
> Christophe
> 
> -Original Message-
> From: Christian Schulte [mailto:c...@schulte.it] 
> Sent: Donnerstag, 4. August 2016 13:00
> To: Maven Developers List 
> Subject: Re: project having a dependency with a version range fails building 
> when parent pom of dependency is evicted from remote repo
> 
> Am 08/04/16 um 12:36 schrieb Thiebaud, Christophe:
>> I understand that pom file of lib 0.0.1-SNAPSHOT dependency cannot be built 
>> because of missing (evicted) parent 0.0.1-SNAPSHOT.
>>
>> The point is that failing to build lib 0.0.1-SNAPSHOT pom file should not 
>> result in a app failed build, as there exists another valid lib 
>> 0.0.2-SNAPSHOT (having parent 0.0.2-SNAPSHOT) that abides to the app-to-lib 
>> version range.
>>
>> Note that when the relationship between parent and lib is a dependency 
>> relationship (instead of a parent relationship, as in the failing case), the 
>> build of ‘app’ correctly succeeds, as there exists another valid lib 
>> 0.0.2-SNAPSHOT (dependent on parent 0.0.2-SNAPSHOT) in the version range.
> 
> Does the issue go away using a current Maven snapshot (3.4.0-SNAPSHOT)?
> Already tried if '-U,--update-snapshots' changes the situation?
> 
> 
> 
> Regards,
> 


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

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Christian Schulte]

Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe:
> Reading Aether documentation : 
> 
> https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution
> 
> looks that aether has been thought to manage this kind of issue:
> 
> « For each direct dependency, a dependency selector is given a chance to 
> exclude the dependency from the graph »
> 
> Any hint if and how it is possible to configure aether to ignore 'lib' 
> 0.0.1-SNAPSHOT when resolving the version range ?

I am a bit confused about the different error message right now. When it
comes to version ranges, Aether reads all POMs of all versions it finds.
If a parent has disappeared, it will fail building that model. Is there
a way for you to purge the repository in a way not leaving broken
projects around? I think that is the real issue. You would need some
kind of index for this so that you can purge snapshots in a consistent
way. Regarding the 'DependencySelector'. There currently is no way to
change that. It's only used during initialization and I think that would
be the wrong way of doing it
.

Regards,
-- 
Christian


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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Christian Schulte]

Am 08/05/16 um 01:21 schrieb Gary Gregory:
> On Thu, Aug 4, 2016 at 3:24 PM, Christian Schulte  wrote:
> 
>> Am 08/05/16 um 00:15 schrieb Gary Gregory:
>>> But here you would just tell the manager: "I want to use Maven" as
>> opposed
>>> to "I want to use Ant and Ivy".
>>
>> So lets rename Maven. We need a name sounding cool to management. Just
>> so that we do not need to discuss why we want to use it...something
>> implying less costs (due to speed or whatever).
>>
> 
> But Maven IS a cool name :-) and it means "an expert or connoisseur", what
> could be better! I am serious to boot :-)
> 

Did he just say build monkeys? :-)

Seriously. I never noticed that. Perfect demonstration of how much I do
not care about product names. Glad I've choosen the right build tool for
me not just because of its name. I thought "Maven" really is just a name.


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

RE: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Thiebaud, Christophe]

Reading Aether documentation : 

https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution

looks that aether has been thought to manage this kind of issue:

« For each direct dependency, a dependency selector is given a chance to 
exclude the dependency from the graph »

Any hint if and how it is possible to configure aether to ignore 'lib' 
0.0.1-SNAPSHOT when resolving the version range ?

Thanks
Christophe

-Original Message-
From: Thiebaud, Christophe [mailto:christophe.thieb...@sap.com] 
Sent: Donnerstag, 4. August 2016 16:03
To: Maven Developers List 
Cc: Schmoigl, Dominic ; Holl, Marcus 

Subject: RE: project having a dependency with a version range fails building 
when parent pom of dependency is evicted from remote repo

Hi Christian,

Thanks for the hint to try  maven 3.4.0-SNAPSHOT

I tried, and the result is again BUILD FAILURE - but with a nice colored system 
out, and - more seriously - a different, and IMHO misleading, error message.

(Cf. full reproducible commands at 
https://github.com/iroif/iroif-parent/blob/master/README.md  , starting below " 
To reproduce the issue")

---
maven 3.4.0-SNAPSHOT

$ mvn clean install -s ../iroif-parent/settings.xml 
-Dmaven.repo.local=/c/tmp/iroif-app-xxx

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.075 s
[INFO] Finished at: 2016-08-04T15:37:25+02:00
[INFO] Final Memory: 26M/456M
[INFO] 
[ERROR] Failed to execute goal on project iroif-app: Could not resolve 
dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
Could not find artifact net.aequologica.iroif:iroif-lib:jar:0.0.2-SNAPSHOT -> 
[Help 1]
[ERROR]

-
maven 3.3.9

$ mvn clean install -s ../iroif-parent/settings.xml 
-Dmaven.repo.local=/c/tmp/iroif-app-yyy

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 1.810 s
[INFO] Finished at: 2016-08-04T16:01:14+02:00
[INFO] Final Memory: 21M/289M
[INFO] 
[ERROR] Failed to execute goal on project iroif-app: Could not resolve 
dependencies for project net.aequologica.iroif:iroif-app:jar:0.1.0-SNAPSHOT: 
Failed to collect dependencies at 
net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Failed to read artifact 
descriptor for net.aequologica.iroif:iroif-lib:jar:0.0.1-SNAPSHOT: Could not 
find artifact net.aequologica.iroif:iroif-parent:pom:0.0.1-SNAPSHOT in 
local_nexus (http://localhost:1082/nexus/content/groups/public/) -> [Help 1]
[ERROR]

Also, the -U (--update snapshots) parameter makes no difference, as a new, 
fresh local repo is created for each command of the scripts to reproduce the 
issue.

Thanks
Christophe

-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Donnerstag, 4. August 2016 13:00
To: Maven Developers List 
Subject: Re: project having a dependency with a version range fails building 
when parent pom of dependency is evicted from remote repo

Am 08/04/16 um 12:36 schrieb Thiebaud, Christophe:
> I understand that pom file of lib 0.0.1-SNAPSHOT dependency cannot be built 
> because of missing (evicted) parent 0.0.1-SNAPSHOT.
> 
> The point is that failing to build lib 0.0.1-SNAPSHOT pom file should not 
> result in a app failed build, as there exists another valid lib 
> 0.0.2-SNAPSHOT (having parent 0.0.2-SNAPSHOT) that abides to the app-to-lib 
> version range.
> 
> Note that when the relationship between parent and lib is a dependency 
> relationship (instead of a parent relationship, as in the failing case), the 
> build of ‘app’ correctly succeeds, as there exists another valid lib 
> 0.0.2-SNAPSHOT (dependent on parent 0.0.2-SNAPSHOT) in the version range.

Does the issue go away using a current Maven snapshot (3.4.0-SNAPSHOT)?
Already tried if '-U,--update-snapshots' changes the situation?



Regards,
-- 
Christian


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

B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[X]�[��\X�K�ܙ�B�

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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Uwe Barthel]

Hi,


Eclipse owns the Aether name. We cannot use the name Aether.


And the Eclipse Foundation doesn't like to provide that name to the ASF 
(only the name without the eclipse namespace)?


Aethel means over the AIR.

WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more 
general than resolve?


-- barthel



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

Upgrading m-pmd-p - PMD 5.5.1

[Andreas Dangel]

Hi all,


I want to implement https://issues.apache.org/jira/browse/MPMD-220 -
which is upgrading the m-pmd-p to use the latest PMD version.

As of PMD 5.4.x, the minimum java runtime is 7, so I would upgrade the
plugin accordingly.

m-pmd-p 3.6 would be the last version, that supports Java 6. From
m-pmd-p 3.7 on, at least Java 7 will be required.

Any thoughts on that?


Regards,

Andreas


-- 
Andreas Dangel
https://github.com/adangel
skype: andreas_dangel



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[herve . boutemy]

yes, in the current case, this is an internal component name we're looking for: 
end-users will not notice

Regards,

Hervé

- Mail original -
De: "Gary Gregory" 
À: "Maven Developers List" 
Envoyé: Vendredi 5 Août 2016 00:15:24
Objet: Re: [DISCUSSION] finishing Aether import: help find a new name

On Thu, Aug 4, 2016 at 2:53 PM, Christian Schulte  wrote:

> Am 08/04/16 um 23:08 schrieb Jason van Zyl:
> > When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
> Tycho. None of them very useful for people to understand what they actually
> do. I think I’m done with catchy names. I’m old.
>
> There is one quote I can make here. Working on a boring project I needed
> to generate code massively. When I told the manager I would go using
> something called Velocity he replied: "Velocity. I like that one. Go for
> it. This will speed things up." Just because the name implied I will get
> the job done quicker using it. If the same technology would have been
> called "something very error-prone templating engine" he would have
> said: Oh no. Don't do it that way...
>

But here you would just tell the manager: "I want to use Maven" as opposed
to "I want to use Ant and Ivy".

So this seems to be all about an internal name.

Gary


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Stephen Connolly]

Eclipse owns the Aether name. We cannot use the name Aether.

On 5 August 2016 at 05:14, Uwe Barthel  wrote:

> Hi,
>
> I know Aether is one of the catchy non telling name.
> But, why not leave Aether with new Maven namespace like
> org.apache.maven.aether?
>
> -- barthel
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

AW: Building Apache Maven

[Christofer Dutz]

Hi Rajiv,


I just had a look at my build. The version string comes from build.properties 
in maven-core.jar:/org/apache/maven/messages/build.properties


As the values are updated by the resources plugin during the build, I would 
imagine that they should be 3.4.0-SNAPSHOT or ${project.version} ... could you 
please check the following:

1. The maven-core.jar in the distribution is actually re-written and you are 
not using an old version?

2. The maven-core/target/classes/org/apache/maven/messages/build.properties 
contains the correct version?

3. The version in maven-core's pom is wrong (cause you're on the some other 
branch, not on head)?


Chris


Von: Rajiv Jain 
Gesendet: Donnerstag, 4. August 2016 22:42:08
An: Maven Developers List
Betreff: Re: Building Apache Maven

Hi

I wanted to chase up whether anybody can reply to the below e-mail?

Basically, I would like to produce a fresh build and test my changes on my 
fresh build.

I am using mvn - 
DdistributionTargetFolder=/Users/rajivpjs/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
 clean package

>From this I used 
>/Users/rajivpjs/tools/maven-test/apache-test/apache-3.4.0-SNAPSHOT/bin/mvn -f 
>/path/to/pom.xml clean package -V

It displays version 3.3.9, instead of 3.4.0.

What am I doing wrong?

Thanks.

Regards,
Rajiv

> On 31 Jul 2016, at 08:40, Rajiv Jain  wrote:
>
> I forgot to mention pull request is 88.
>
> Sent from my iPhone
>
> On 31 Jul 2016, at 07:37, Rajiv Jain  > wrote:
>
>> Hi
>>
>> Based on a couple of previous e-mails and me doing one of the tasks, I 
>> identified that once I append -V during my fresh build I reliased I was 
>> still using the installed Maven.
>>
> mvn - 
> DdistributionTargetFolder=/Users/rajivpjs/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> clean package
>>
>> From this I used 
>> /Users/rajivpjs/tools/maven-test/apache-test/apache-3.4.0-SNAPSHOT/bin/mvn 
>> -f /path/to/pom.xml clean package -V
>>
>> Is this correct?
>>
>> Please could you review the pull request MNG-5910?
>>
>> Thanks.
>>
>> Regards,
>> Rajiv
>>
>>
>>
>> Sent from my iPhone
>>
>> On 23 Jul 2016, at 12:45, Karl Heinz Marbaise > > wrote:
>>
>>> Hi Rajiv,
>>>
>>> I have taken another look into your updated pull request...
>>>
>>> We usually don't use asterik imports...and furthermore you don't follow the 
>>> code style guide we have:
>>>
>>> http://maven.apache.org/developers/conventions/code.html 
>>> 
>>>
>>> If you runn a full build of what you have changed checkstyle should fail 
>>> here already...and give you a hint that the code style you have used is not 
>>> correct...
>>>
>>>
>>> Kind regards
>>> Karl Heinz
>>>
>>>
>>>
>>> On 7/22/16 7:50 PM, Rajiv Jain wrote:
 Hi

 Thanks for the quick reply. I will give that ago.

 Ignore me for the jre. My details are:

 mvn --version
 Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
 2015-11-10T16:41:47+00:00)
 Maven home: /Users/rajivpjs/Desktop/apache-maven-3.3.9/apache-maven-3.3.9

 For some reason I thought maven home is
 Users/rajivpsj/Desktop/apache-maven-3.3.9/apache-maven-3.3.9/jre

 Sorry for the confusion.

 Thanks once again.

 Just out of question, I raised a pull request a few days ago MNG-5910
 (https://github.com/apache/maven/pull/88 
 ). There was one review comment
 which I have fixed and I think this can be merged in. Could someone
 please look at and if fine then we can merge and close the pull request?

 Regards,
 Rajiv

> On 22 Jul 2016, at 18:33, Karl Heinz Marbaise  
> >> wrote:
>
> Hi,
>
>
> On 7/22/16 7:17 PM, Rajiv Jain wrote:
>> Hi
>>
>> I have recently started to make contributions to the Apache Maven
>> source code.
>>
>> I would like to know that if I wish to build a maven project using my
>> changes how would I do this?
>
>
> You can build Maven Core by using the following and let also the
> distribution being copied to a particular directory like this:
>
> mvn
> -DdistributionTargetFolder=/Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> clean package
>
> I have a particular folder for the test version which I build from
> Maven core .
>
>
> Now if I like to use the build Maven version I simply use it directly:
>
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean package
>
> So I use the build version here...
>
> Apart from that if you are making changes to Maven Core you should
> become familiar with the