Re: svn commit: r1595491 - in /maven/shared/trunk/maven-dependency-tree: ./ src/it/multi-module-plugin/ src/it/multi-module-plugin/resources/ src/it/multi-module-plugin/resources/META-INF/ src/it/mult

+1 In my circles, changing method params is a bad practice. Enforcement of rules is key - I do the same thing Manfred, fail the build on a set of FindBugs, PMD, and CheckStyle violations. Really makes coders adhere! On Fri, May 23, 2014 at 10:15 PM, Manfred Moser wrote: > I totally agree with

Re: svn commit: r1595491 - in /maven/shared/trunk/maven-dependency-tree: ./ src/it/multi-module-plugin/ src/it/multi-module-plugin/resources/ src/it/multi-module-plugin/resources/META-INF/ src/it/mult

I totally agree with William here. I also think that any standard that is not enforced easily is pointless. Thats why I implemented the checkstyle verification to be part of the default build in the android maven plugin (and other projects). I find this tremendously helpful. It removes any doubt

Re: svn commit: r1595491 - in /maven/shared/trunk/maven-dependency-tree: ./ src/it/multi-module-plugin/ src/it/multi-module-plugin/resources/ src/it/multi-module-plugin/resources/META-INF/ src/it/mult

> > parameters and local variables are not considered final: there is nothing > wrong > with modifying their value, and nothing good to get by forcing them to be > final > But there *is* value is defining them to be final. If you as the programmer know that a value should never change, then by de

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

Thanks Igor. > A correct LifeCycleParticipant implementation should always scope > component lookups to the current project's classloader and should use > the original classloader to allow lookup of the core components only. But in a multi-module build the LifeCycleParticipant is only ever call

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

On 2014-05-23, 19:45, William Ferguson wrote: Thanks Jason, that was most informative. But I am running into one issue and I am not sure whether it is a bug or by design. I have a project that has no config for my plugin (containing a LifeCycleParticipant) and that project has a child module

Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?

Thanks Jason, that was most informative. But I am running into one issue and I am not sure whether it is a bug or by design. I have a project that has no config for my plugin (containing a LifeCycleParticipant) and that project has a child module that does have config for my plugin. During LifeCy

Re: svn commit: r1595491 - in /maven/shared/trunk/maven-dependency-tree: ./ src/it/multi-module-plugin/ src/it/multi-module-plugin/resources/ src/it/multi-module-plugin/resources/META-INF/ src/it/mult

Le jeudi 22 mai 2014 15:25:05 William Ferguson a écrit : > > I do not agree on this one, and that's the meaning of the coding style > > Wouldn't you rather have the compiler catch the error as opposed to > manually introspecting the code each time? parameters and local variables are not considered

Re: Which is the real duplicate?

I've updated the duplicate field. Dupes of MNG-5613 which is marked fixed for 3.2.2. Sample project in MNG-5637 doesn't work. On May 23, 2014, at 2:29 PM, Stuart McCulloch wrote: > Looks like they’re both linked as duplicates of > http://jira.codehaus.org/browse/MNG-5637 - should that issue be

Re: Which is the real duplicate?

Looks like they’re both linked as duplicates of http://jira.codehaus.org/browse/MNG-5637 - should that issue be marked as fixed in 3.2.2? On 23 May 2014, at 19:24, Paul Benedict wrote: > Both MNG-5633 and MNG-5628 >

Which is the real duplicate?

Both MNG-5633 and MNG-5628 are listed as "fixed" in 3.2.2 and both resolved are duplicates. The real one should be fixed as "Resolved" and the duplicate should be taken out of the 3.2.2 version. Tips? Cheers, Pa

Re: Anyone else having issues reaching https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 ?

Of course it works fast now... On May 23, 2014, at 8:36 AM, Jeff Jensen wrote: > I just successfully viewed the page, so no problems reaching it. > > > > On Fri, May 23, 2014 at 7:30 AM, Jason van Zyl wrote: > >> For the last few days the instance seems to be in distress. Anyone else >> ha

[GitHub] maven pull request: MNG-5625: Provide a terse information about th...

GitHub user nerro opened a pull request: https://github.com/apache/maven/pull/14 MNG-5625: Provide a terse information about the used thread builder Fix for this issue http://jira.codehaus.org/browse/MNG-5625 You can merge this pull request into a Git repository by running: $ g

Re: Anyone else having issues reaching https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 ?

I just successfully viewed the page, so no problems reaching it. On Fri, May 23, 2014 at 7:30 AM, Jason van Zyl wrote: > For the last few days the instance seems to be in distress. Anyone else > having issues? > > Thanks, > > Jason > > --

Re: Anyone else having issues reaching https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 ?

Seems fine to me (true, I have no karma to edit, but logged in and pageload is quite fast). Thanks, ~t~ On Fri, May 23, 2014 at 2:30 PM, Jason van Zyl wrote: > For the last few days the instance seems to be in distress. Anyone else > having issues? > > Thanks, > > Jason > > --

Anyone else having issues reaching https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 ?

For the last few days the instance seems to be in distress. Anyone else having issues? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --

Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net

Hi Robert,Kristian, Early Access builds for JDK 9 b13 , JDK 8u20 b15 and JDK 7u60 b15 are available on java.net. As we enter the later phases of development for JDK 7u60 & JDK 8u20 ,