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

[William Ferguson]

Hervé Boutemy 
 said:
notice there are a few places where coding conventions are not respected:
this would be great if you could have a look (previous comments are more
important :) )
see http://maven.apache.org/developers/conventions/code.html for more
information, and tooling for automatic IDE handling


I thought I was adhering. Thought I had configured IntelliJ with an
appropriate checkstyle config, but I'll apply it again. Two questions:

1) Is there no automatic checkstyle verification as part of the build? We
use it in the android-maven-plugin and I though it was standard practice
across the Maven projects.

2) Why is the following one of the Java code conventions? Why would you
remove that information from the compiler? I always work to the exact
opposite of that unless I need to conform with a tool that uses reflection
and can't handle final variables.

   - *Modifier*: Avoid using final modifier on all member variables and
   arguments.


William



On Mon, May 19, 2014 at 3:39 AM, Jason van Zyl  wrote:

> All the formatting and license header issues are resolved. William needs
> to verify the license for one file. Aside from that he can answer any other
> questions here.
>
> BTW, SVN makes this not very fun. I think we should get more aggressive on
> our conversion. Most contributions I'm seeing lately are coming through
> Github. Having to use git-svn or make patches between copies is not really
> fun.
>
> On May 18, 2014, at 10:51 AM, Hervé BOUTEMY  wrote:
>
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilter filter, Map >> MavenProject> reactorProjects ) +throws
> >> DependencyGraphBuilderException;
> >
> > why expect a Map reactorProjects, when a
> > List seems simpler and more natural (result from
> > MavenSession.getProjects())?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> >> Author: jvanzyl
> >> Date: Sat May 17 14:33:40 2014
> >> New Revision: 1595491
> >>
> >> URL: http://svn.apache.org/r1595491
> >> Log:
> >> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> >> accepts the reactor projects and resolves dependencies from within the
> >> reactor. - Added multi-module-test to validate that the new method works
> >> against both direct and transitive deps. - Added multi-module-plugin to
> be
> >> used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> as
> >> there is currently no public method to generate the key for
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Separated the reflective invocation
> >> out into the Invoker class.
> >> - Made maven-project dependency scope=provided as at runtime we want the
> >> version in the maven install, not 2.2.0 Submitted by: William Ferguson
> >> 
> >>
> > ...
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java (original) +++
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
> 2014 @@
> >> -22,6 +22,8 @@ package org.apache.maven.shared.dependen
> >> import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
> >> import org.apache.maven.project.MavenProject;
> >>
> >> +import java.util.Map;
> >> +
> >> /**
> >>  * Maven project dependency graph builder API, neutral against Maven 2
> or
> >> Maven 3. *
> >> @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
> >> public interface DependencyGraphBuilder
> >> {
> >> /**
> >> - * Build the dependency graph.
> >> + * Build the dependency graph from the repository.
> >> + *
> >> + * This is the same as {@link
> >> #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> >> org.apache.maven.artifact.resolver.filter.ArtifactFilter,
> java.util.Map)}
> >> with an empty reactorProjects Map. *
> >>  * @param project the project
> >>  * @param filter artifact filter (can be null
> >> @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
> >>  */
> >> DependencyNode buildDependencyGraph( MavenProject project,
> >> ArtifactFilter filter ) throws DependencyGraphBuilderException;
> >> +
> >> +/**
> >> + * Build the dependency graph including any dependencies contained
> in
> >> the reactor projects. + *
> >> + * @param project the project
> >> + * @param filter artifact filter (can be null
> >> + * @param reactorProjects Map of those projects contained in the
> >> reactor. + *Key is made up of
> >> groupId-artifactId-version. + * @return the dependency graph
> >> + * @throws DependencyGraphBuilderException
> >> + */
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilt

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

[William Ferguson]

Thanks Jason, appreciate it.

William


On Mon, May 19, 2014 at 11:39 AM, Jason van Zyl  wrote:

>
> On May 18, 2014, at 9:31 PM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > So it boils down to ProjectDependenciesResolver being able to resolve an
> > s3wagon dependency from a Mojo, but not from MavenLifecycleParticipant.
> >
> > Is it because RepositorySystem has not been fully configured by
> > MLCP#afterProjectsRead?
> > If so, is there a way to ensure that it is configured by then?
> >
> > Someone, anyone?
> >
>
> The RepositorySystem is fully initialized at that point. I'll take a look
> at the test projects you made but I've never tried to use an extension from
> a participant and I think that's the issue.
>
> > William
> >
> >
> > On Sun, May 18, 2014 at 9:23 AM, William Ferguson <
> > william.fergu...@xandar.com.au> wrote:
> >
> >> OK, I'm really hoping someone can provide some more insight on this as I
> >> have reached my limit.
> >>
> >> To make things clearer, I have created a project containing
> >> integration-tests showing the failure that is causing us grief (external
> >> wagon dependencies not being resolvable from within
> >> MavenLifeCycleParticipant) and well as integration tests showing that
> that
> >> same deps are resolvable either using the std Maven dep resolution or
> >> explicit resolution from within a Mojo,
> >>
> >> https://github.com/william-ferguson-au/example-resolution-plugin.
> >>
> >> Could someone please have a look and help me work out how to get the
> >> external wagon deps to resolve from the MLCP?
> >>
> >> William
> >>
> >>
> >> On Fri, May 16, 2014 at 1:22 AM, William Ferguson <
> >> william.fergu...@xandar.com.au> wrote:
> >>
> >>> No one on the user's list wanted to have a go at this. How about
> someone
> >>> from the Dev list?
> >>>
> >>> William
> >>>
> >>>
> >>> -- Forwarded message --
> >>> From: William Ferguson 
> >>> Date: Mon, May 12, 2014 at 8:58 PM
> >>> Subject: Wagon extensions not available from
> >>> AbstractMavenLifecycleParticipant or maven-dependency-tree?
> >>> To: Maven Users List 
> >>>
> >>>
> >>> I have a MavenLifecycleParticipant in my plugin. It uses
> >>> maven-dependency-tree to resolve some deps that we need to do extra
> >>> processing on. It works fine if the deps are in the local repo.
> >>>
> >>> But if the s3 Wagon is defined in the project along with a dependency
> >>> from the s3 bucket, then the following debug log shows that
> >>> DependencyGraphBuilder of maven-dependency-tree can't resolve the s3
> wagon,
> >>> and the dependency is not resolved now or later in the build, so
> >>> compilation fails.
> >>>
> >>> NB If I remove the MavenLifecycleParticipant then the dep is resolved
> via
> >>> the S3 Wagon.
> >>>
> >>> Q1) When are the Wagons configured? Shouldn't it be prior to
> >>> MavenLifecycleParticipant being called?
> >>> Q2) How can I get the DependencyGraphBuilder to resolve the s3 artifact
> >>> from within the MavenLifecycleParticipant?
> >>>
> >>>
> >>> Here is the stacktrace:
> >>>
> >>> [DEBUG] Could not find metadata
> >>>
> com.viewpagerindicator:viewpagerindicator:2.4.2-SNAPSHOT/maven-metadata.xml
> >>> in local (D:\dev\maven-local-repository)
> >>> [DEBUG] java.util.NoSuchElementException
> >>>  role: org.apache.maven.wagon.Wagon
> >>>  roleHint: s3
> >>>
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> >>> java.util.NoSuchElementException
> >>>  role: org.apache.maven.wagon.Wagon
> >>>  roleHint: s3
> >>> at
> >>>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264)
> >>> at
> >>>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> >>> at
> >>>
> org.eclipse.aether.internal.connector.wagon.PlexusWagonProvider.lookup(PlexusWagonProvider.java:33)
> >>> at
> >>>
> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.lookupWagon(WagonRepositoryConnector.java:337)
> >>> at
> >>>
> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.(WagonRepositoryConnector.java:157)
> >>> at
> >>>
> org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactory.newInstance(WagonRepositoryConnectorFactory.java:159)
> >>> at
> >>>
> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:139)
> >>> at
> >>>
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:613)
> >>> at
> >>>
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> >>> at
> >>>
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute(DefaultMetadataResolver.java:540)
> >>> at
> >>>
> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:395)
> >>> at
> >>>
> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:218)
> >>> at
> >>>
>

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

[Jason van Zyl]

On May 18, 2014, at 9:31 PM, William Ferguson  
wrote:

> So it boils down to ProjectDependenciesResolver being able to resolve an
> s3wagon dependency from a Mojo, but not from MavenLifecycleParticipant.
> 
> Is it because RepositorySystem has not been fully configured by
> MLCP#afterProjectsRead?
> If so, is there a way to ensure that it is configured by then?
> 
> Someone, anyone?
> 

The RepositorySystem is fully initialized at that point. I'll take a look at 
the test projects you made but I've never tried to use an extension from a 
participant and I think that's the issue.

> William
> 
> 
> On Sun, May 18, 2014 at 9:23 AM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
> 
>> OK, I'm really hoping someone can provide some more insight on this as I
>> have reached my limit.
>> 
>> To make things clearer, I have created a project containing
>> integration-tests showing the failure that is causing us grief (external
>> wagon dependencies not being resolvable from within
>> MavenLifeCycleParticipant) and well as integration tests showing that that
>> same deps are resolvable either using the std Maven dep resolution or
>> explicit resolution from within a Mojo,
>> 
>> https://github.com/william-ferguson-au/example-resolution-plugin.
>> 
>> Could someone please have a look and help me work out how to get the
>> external wagon deps to resolve from the MLCP?
>> 
>> William
>> 
>> 
>> On Fri, May 16, 2014 at 1:22 AM, William Ferguson <
>> william.fergu...@xandar.com.au> wrote:
>> 
>>> No one on the user's list wanted to have a go at this. How about someone
>>> from the Dev list?
>>> 
>>> William
>>> 
>>> 
>>> -- Forwarded message --
>>> From: William Ferguson 
>>> Date: Mon, May 12, 2014 at 8:58 PM
>>> Subject: Wagon extensions not available from
>>> AbstractMavenLifecycleParticipant or maven-dependency-tree?
>>> To: Maven Users List 
>>> 
>>> 
>>> I have a MavenLifecycleParticipant in my plugin. It uses
>>> maven-dependency-tree to resolve some deps that we need to do extra
>>> processing on. It works fine if the deps are in the local repo.
>>> 
>>> But if the s3 Wagon is defined in the project along with a dependency
>>> from the s3 bucket, then the following debug log shows that
>>> DependencyGraphBuilder of maven-dependency-tree can't resolve the s3 wagon,
>>> and the dependency is not resolved now or later in the build, so
>>> compilation fails.
>>> 
>>> NB If I remove the MavenLifecycleParticipant then the dep is resolved via
>>> the S3 Wagon.
>>> 
>>> Q1) When are the Wagons configured? Shouldn't it be prior to
>>> MavenLifecycleParticipant being called?
>>> Q2) How can I get the DependencyGraphBuilder to resolve the s3 artifact
>>> from within the MavenLifecycleParticipant?
>>> 
>>> 
>>> Here is the stacktrace:
>>> 
>>> [DEBUG] Could not find metadata
>>> com.viewpagerindicator:viewpagerindicator:2.4.2-SNAPSHOT/maven-metadata.xml
>>> in local (D:\dev\maven-local-repository)
>>> [DEBUG] java.util.NoSuchElementException
>>>  role: org.apache.maven.wagon.Wagon
>>>  roleHint: s3
>>> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
>>> java.util.NoSuchElementException
>>>  role: org.apache.maven.wagon.Wagon
>>>  roleHint: s3
>>> at
>>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264)
>>> at
>>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
>>> at
>>> org.eclipse.aether.internal.connector.wagon.PlexusWagonProvider.lookup(PlexusWagonProvider.java:33)
>>> at
>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.lookupWagon(WagonRepositoryConnector.java:337)
>>> at
>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.(WagonRepositoryConnector.java:157)
>>> at
>>> org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactory.newInstance(WagonRepositoryConnectorFactory.java:159)
>>> at
>>> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:139)
>>> at
>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:613)
>>> at
>>> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
>>> at
>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute(DefaultMetadataResolver.java:540)
>>> at
>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:395)
>>> at
>>> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:218)
>>> at
>>> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:250)
>>> at
>>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:284)
>>> at
>>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorRe

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

[William Ferguson]

So it boils down to ProjectDependenciesResolver being able to resolve an
s3wagon dependency from a Mojo, but not from MavenLifecycleParticipant.

Is it because RepositorySystem has not been fully configured by
MLCP#afterProjectsRead?
If so, is there a way to ensure that it is configured by then?

Someone, anyone?

William


On Sun, May 18, 2014 at 9:23 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:

> OK, I'm really hoping someone can provide some more insight on this as I
> have reached my limit.
>
> To make things clearer, I have created a project containing
> integration-tests showing the failure that is causing us grief (external
> wagon dependencies not being resolvable from within
> MavenLifeCycleParticipant) and well as integration tests showing that that
> same deps are resolvable either using the std Maven dep resolution or
> explicit resolution from within a Mojo,
>
> https://github.com/william-ferguson-au/example-resolution-plugin.
>
> Could someone please have a look and help me work out how to get the
> external wagon deps to resolve from the MLCP?
>
> William
>
>
> On Fri, May 16, 2014 at 1:22 AM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
>> No one on the user's list wanted to have a go at this. How about someone
>> from the Dev list?
>>
>> William
>>
>>
>> -- Forwarded message --
>> From: William Ferguson 
>> Date: Mon, May 12, 2014 at 8:58 PM
>> Subject: Wagon extensions not available from
>> AbstractMavenLifecycleParticipant or maven-dependency-tree?
>> To: Maven Users List 
>>
>>
>> I have a MavenLifecycleParticipant in my plugin. It uses
>> maven-dependency-tree to resolve some deps that we need to do extra
>> processing on. It works fine if the deps are in the local repo.
>>
>> But if the s3 Wagon is defined in the project along with a dependency
>> from the s3 bucket, then the following debug log shows that
>> DependencyGraphBuilder of maven-dependency-tree can't resolve the s3 wagon,
>> and the dependency is not resolved now or later in the build, so
>> compilation fails.
>>
>> NB If I remove the MavenLifecycleParticipant then the dep is resolved via
>> the S3 Wagon.
>>
>> Q1) When are the Wagons configured? Shouldn't it be prior to
>> MavenLifecycleParticipant being called?
>> Q2) How can I get the DependencyGraphBuilder to resolve the s3 artifact
>> from within the MavenLifecycleParticipant?
>>
>>
>> Here is the stacktrace:
>>
>> [DEBUG] Could not find metadata
>> com.viewpagerindicator:viewpagerindicator:2.4.2-SNAPSHOT/maven-metadata.xml
>> in local (D:\dev\maven-local-repository)
>> [DEBUG] java.util.NoSuchElementException
>>   role: org.apache.maven.wagon.Wagon
>>   roleHint: s3
>> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
>> java.util.NoSuchElementException
>>   role: org.apache.maven.wagon.Wagon
>>   roleHint: s3
>> at
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264)
>>  at
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
>> at
>> org.eclipse.aether.internal.connector.wagon.PlexusWagonProvider.lookup(PlexusWagonProvider.java:33)
>>  at
>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.lookupWagon(WagonRepositoryConnector.java:337)
>> at
>> org.eclipse.aether.connector.wagon.WagonRepositoryConnector.(WagonRepositoryConnector.java:157)
>>  at
>> org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactory.newInstance(WagonRepositoryConnectorFactory.java:159)
>> at
>> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:139)
>>  at
>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:613)
>> at
>> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
>>  at
>> org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute(DefaultMetadataResolver.java:540)
>> at
>> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:395)
>>  at
>> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:218)
>> at
>> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:250)
>>  at
>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:284)
>> at
>> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:217)
>>  at
>> org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:461)
>> at
>> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:261)
>>  at
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
>> at
>> or

Re: Let's fix the Rat Check usability fail

[Bernd Eckenfels]

Hello,

I was speaking about the Rat report for the whole project (which is the parent 
of the core). The Rat-Plugin in the site creation seems to run for 107s on my 
machine (the Javadoc runs 17s).

But maybe I read the output wrong, maven logs can be quite confusing:

73090 [INFO] Generating "Rat Report" report--- apache-rat-plugin:0.10
73112 [DEBUG] Adding plexus default exclusions...
73112 [DEBUG] Adding exclusions often needed by Maven projects...
73112 [DEBUG] Adding exclusions often needed by projects developed in Eclipse...
73112 [DEBUG] Adding exclusions often needed by projects developed in IDEA...
73113 [DEBUG] Finished creating list of implicit excludes.
73113 [INFO] 54 implicit excludes (use -debug for more details).
73114 [INFO] Exclude: site-content/**
73114 [INFO] Exclude: .pmd
73114 [INFO] Exclude: src/site/resources/download_*.cgi
73114 [INFO] Exclude: src/site/resources/profile.*
73895 [DEBUG] Excluded 4081 resources:
...
73984 [DEBUG]  - excluded target\site\xref-test\stylesheet.css
73984 [INFO] 206 resources included (use -debug for more details)
...
73987 [DEBUG]  - included test.txt
Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property 
'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
recognized.
Compiler warnings:
  WARNING:  'org.apache.xerces.jaxp.SAXParserImpl: Property 
'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.'
Warning:  org.apache.xerces.parsers.SAXParser: Feature 
'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
Warning:  org.apache.xerces.parsers.SAXParser: Property 
'http://javax.xml.XMLConstants/property/accessExternalDTD' is not recognized.
Warning:  org.apache.xerces.parsers.SAXParser: Property 
'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
recognized.
180110 [DEBUG] Multipage report: 0 subreports
180134 [DEBUG] Velocimacro : added #relreplace(  text ) : source = 
META-INF/maven/site.vm
...
180145 [DEBUG] Velocimacro : added #forkMeOnGitHub(  ) : source = 
META-INF/maven/site.vm
180205 [INFO] Generating "Checkstyle" report--- 
maven-checkstyle-plugin:2.9.1

Greetings
Bernd


Am Sun, 18 May 2014 14:38:56 -0400
schrieb Jason van Zyl :

> It's the site phase itself that takes a long time.
> 
> On the commons-vfs core module it's takes little time:
> 
> https://gist.github.com/jvanzyl/69c038c0f100803f10db
> 
> I argue that the release should always be in a ready state to
> release, all requirements need to be met at all times in order for
> this to be the case. Aside from the surprise factor at release time
> when something doesn't work.
> 
> On May 18, 2014, at 2:15 PM, Bernd Eckenfels 
> wrote:
> 
> > Currently the Rat Report in the Site phase of commons-vfs takes
> > enormous time, for really no good use when the commits are reviewed
> > anyway (and it has all kinds of excludes and warnings you manually
> > need to check).
> > 
> > So I argue it would be better to run it only in relase (candidate)
> > builds. Not sure if the same process applies to maven development.
> > 
> > Greetings
> > Bernd
> > 
> > Am 18.05.2014 um 19:43 schrieb "Jason Pyeron" :
> > 
> >>> -Original Message-
> >>> From: Jason van Zyl 
> >>> Sent: Sunday, May 18, 2014 13:05
> >>> 
> >>> Right now though we require all files to have license headers 
> >>> we do not run the check to verify this by default.
> >> 
> >> Can it be turned off by option?
> >> 
> >>> It kept dinging me until I turned it on by default in Maven 
> >>> core. Someone currently trying to contribute has no idea this 
> >>> is a requirement and is not told so because it doesn't run by 
> >>> default. If it's required how about we just run all the time 
> >>> everywhere?
> >> 
> >> What phase? 
> >> 
> >>> 
> >>> I would like to change the POMs so that it always runs. 
> >>> Having to run RAT separately is a usability fail. The chances 
> >>> of anyone contributing knowing they have to run it are pretty 
> >>> close to zero.
> >>> 
> >>> Anyone see a reason not to always run it?
> >> 
> >> How much time do they take (add)?
> >> 
> >> -Jason
> >> 
> >> --
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> -   -
> >> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> >> - Principal Consultant  10 West 24th Street #100-
> >> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> >> -   -
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> This message is copyright PD Inc, subject to license 20080407P00.

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

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

[William Ferguson]

Hervé Boutemy 
 said:

in Maven31DependencyGraphBuilder.java, why use invoker for invoker.invoke(
result.getUnresolvedDependencies(), "removeAll", Collection.class,
reactorDeps ); : this is simply collection, no?

Correct, it is simply a collection. In the first instance I did indeed just
call
  result.getUnresolvedDependencies().removeAll( reactorDeps );
But the intent of the code was obfuscated by the 2 different types of
invocation so I converted it to use reflection as it is required by #addAll
on the next line. I think the small runtime cost of reflection is vastly
outweighed by the readability off the code.

William



On Mon, May 19, 2014 at 3:39 AM, Jason van Zyl  wrote:

> All the formatting and license header issues are resolved. William needs
> to verify the license for one file. Aside from that he can answer any other
> questions here.
>
> BTW, SVN makes this not very fun. I think we should get more aggressive on
> our conversion. Most contributions I'm seeing lately are coming through
> Github. Having to use git-svn or make patches between copies is not really
> fun.
>
> On May 18, 2014, at 10:51 AM, Hervé BOUTEMY  wrote:
>
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilter filter, Map >> MavenProject> reactorProjects ) +throws
> >> DependencyGraphBuilderException;
> >
> > why expect a Map reactorProjects, when a
> > List seems simpler and more natural (result from
> > MavenSession.getProjects())?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> >> Author: jvanzyl
> >> Date: Sat May 17 14:33:40 2014
> >> New Revision: 1595491
> >>
> >> URL: http://svn.apache.org/r1595491
> >> Log:
> >> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> >> accepts the reactor projects and resolves dependencies from within the
> >> reactor. - Added multi-module-test to validate that the new method works
> >> against both direct and transitive deps. - Added multi-module-plugin to
> be
> >> used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> as
> >> there is currently no public method to generate the key for
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Separated the reflective invocation
> >> out into the Invoker class.
> >> - Made maven-project dependency scope=provided as at runtime we want the
> >> version in the maven install, not 2.2.0 Submitted by: William Ferguson
> >> 
> >>
> > ...
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java (original) +++
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
> 2014 @@
> >> -22,6 +22,8 @@ package org.apache.maven.shared.dependen
> >> import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
> >> import org.apache.maven.project.MavenProject;
> >>
> >> +import java.util.Map;
> >> +
> >> /**
> >>  * Maven project dependency graph builder API, neutral against Maven 2
> or
> >> Maven 3. *
> >> @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
> >> public interface DependencyGraphBuilder
> >> {
> >> /**
> >> - * Build the dependency graph.
> >> + * Build the dependency graph from the repository.
> >> + *
> >> + * This is the same as {@link
> >> #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> >> org.apache.maven.artifact.resolver.filter.ArtifactFilter,
> java.util.Map)}
> >> with an empty reactorProjects Map. *
> >>  * @param project the project
> >>  * @param filter artifact filter (can be null
> >> @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
> >>  */
> >> DependencyNode buildDependencyGraph( MavenProject project,
> >> ArtifactFilter filter ) throws DependencyGraphBuilderException;
> >> +
> >> +/**
> >> + * Build the dependency graph including any dependencies contained
> in
> >> the reactor projects. + *
> >> + * @param project the project
> >> + * @param filter artifact filter (can be null
> >> + * @param reactorProjects Map of those projects contained in the
> >> reactor. + *Key is made up of
> >> groupId-artifactId-version. + * @return the dependency graph
> >> + * @throws DependencyGraphBuilderException
> >> + */
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilter filter, Map >> MavenProject> reactorProjects ) +throws
> >> DependencyGraphBuilderException;
> >> }
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> 

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

[William Ferguson]

Hervé Boutemy 
 said:
in pom.xml, why remove */pom.xml?

I can't recall. Possibly because I was explicitly declaring the ITs to
ensure the execution order which I later found out depends entirely upon
folder name. Or maybe because my sensibilities were offended by the
combination of explicit definition + overlapping wildcard definition.

In any case, I would suggest that the explicit definition be replaced with
a single */.pom.xml wild card definition.

Where/how would you like me to make the change?

William



On Mon, May 19, 2014 at 3:39 AM, Jason van Zyl  wrote:

> All the formatting and license header issues are resolved. William needs
> to verify the license for one file. Aside from that he can answer any other
> questions here.
>
> BTW, SVN makes this not very fun. I think we should get more aggressive on
> our conversion. Most contributions I'm seeing lately are coming through
> Github. Having to use git-svn or make patches between copies is not really
> fun.
>
> On May 18, 2014, at 10:51 AM, Hervé BOUTEMY  wrote:
>
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilter filter, Map >> MavenProject> reactorProjects ) +throws
> >> DependencyGraphBuilderException;
> >
> > why expect a Map reactorProjects, when a
> > List seems simpler and more natural (result from
> > MavenSession.getProjects())?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> >> Author: jvanzyl
> >> Date: Sat May 17 14:33:40 2014
> >> New Revision: 1595491
> >>
> >> URL: http://svn.apache.org/r1595491
> >> Log:
> >> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> >> accepts the reactor projects and resolves dependencies from within the
> >> reactor. - Added multi-module-test to validate that the new method works
> >> against both direct and transitive deps. - Added multi-module-plugin to
> be
> >> used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> as
> >> there is currently no public method to generate the key for
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Separated the reflective invocation
> >> out into the Invoker class.
> >> - Made maven-project dependency scope=provided as at runtime we want the
> >> version in the maven install, not 2.2.0 Submitted by: William Ferguson
> >> 
> >>
> > ...
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java (original) +++
> >>
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> >> red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
> 2014 @@
> >> -22,6 +22,8 @@ package org.apache.maven.shared.dependen
> >> import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
> >> import org.apache.maven.project.MavenProject;
> >>
> >> +import java.util.Map;
> >> +
> >> /**
> >>  * Maven project dependency graph builder API, neutral against Maven 2
> or
> >> Maven 3. *
> >> @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
> >> public interface DependencyGraphBuilder
> >> {
> >> /**
> >> - * Build the dependency graph.
> >> + * Build the dependency graph from the repository.
> >> + *
> >> + * This is the same as {@link
> >> #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> >> org.apache.maven.artifact.resolver.filter.ArtifactFilter,
> java.util.Map)}
> >> with an empty reactorProjects Map. *
> >>  * @param project the project
> >>  * @param filter artifact filter (can be null
> >> @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
> >>  */
> >> DependencyNode buildDependencyGraph( MavenProject project,
> >> ArtifactFilter filter ) throws DependencyGraphBuilderException;
> >> +
> >> +/**
> >> + * Build the dependency graph including any dependencies contained
> in
> >> the reactor projects. + *
> >> + * @param project the project
> >> + * @param filter artifact filter (can be null
> >> + * @param reactorProjects Map of those projects contained in the
> >> reactor. + *Key is made up of
> >> groupId-artifactId-version. + * @return the dependency graph
> >> + * @throws DependencyGraphBuilderException
> >> + */
> >> +DependencyNode buildDependencyGraph(
> >> +MavenProject project, ArtifactFilter filter, Map >> MavenProject> reactorProjects ) +throws
> >> DependencyGraphBuilderException;
> >> }
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> htt

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

[Hervé BOUTEMY]

if you want to work on github and send pull requests, no problem

Regards,

Hervé

Le lundi 19 mai 2014 08:49:28 William Ferguson a écrit :
> Hervé Boutemy 
>  said:
> in interface DependencyGraphBuilder, why expect a Map reactorProjects, when
> a List seems simpler and more natural (result from
> MavenSession.getProjects())?
> 
> Good point. We could pass in List and construct the Map internally.
> Where/How would you like me to make the change?
> William
> 
> On Mon, May 19, 2014 at 12:51 AM, Hervé BOUTEMY 
wrote:
> > > +DependencyNode buildDependencyGraph(
> > > +MavenProject project, ArtifactFilter filter, Map > > MavenProject> reactorProjects ) +throws
> > > DependencyGraphBuilderException;
> > 
> > why expect a Map reactorProjects, when a
> > List seems simpler and more natural (result from
> > MavenSession.getProjects())?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> > > Author: jvanzyl
> > > Date: Sat May 17 14:33:40 2014
> > > New Revision: 1595491
> > > 
> > > URL: http://svn.apache.org/r1595491
> > > Log:
> > > MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> > > accepts the reactor projects and resolves dependencies from within the
> > > reactor. - Added multi-module-test to validate that the new method works
> > > against both direct and transitive deps. - Added multi-module-plugin to
> > 
> > be
> > 
> > > used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> > 
> > as
> > 
> > > there is currently no public method to generate the key for
> > > MavenProject#projectReferences, MavenSession#projectMap or the Map of
> > > reactor projects that we will use. - Separated the reflective invocation
> > > out into the Invoker class.
> > > - Made maven-project dependency scope=provided as at runtime we want the
> > > version in the maven install, not 2.2.0 Submitted by: William Ferguson
> > > 
> > 
> > ...
> > 
> > maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sh
> > a
> > 
> > > red/dependency/graph/DependencyGraphBuilder.java (original) +++
> > 
> > maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sh
> > a
> > 
> > > red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
> > 
> > 2014 @@
> > 
> > > -22,6 +22,8 @@ package org.apache.maven.shared.dependen
> > > 
> > >  import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
> > >  import org.apache.maven.project.MavenProject;
> > > 
> > > +import java.util.Map;
> > > +
> > > 
> > >  /**
> > >  
> > >   * Maven project dependency graph builder API, neutral against Maven 2
> > 
> > or
> > 
> > > Maven 3. *
> > > @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
> > > 
> > >  public interface DependencyGraphBuilder
> > >  {
> > >  
> > >  /**
> > > 
> > > - * Build the dependency graph.
> > > + * Build the dependency graph from the repository.
> > > + *
> > > + * This is the same as {@link
> > > #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> > > org.apache.maven.artifact.resolver.filter.ArtifactFilter,
> > > java.util.Map)}
> > > with an empty reactorProjects Map. *
> > > 
> > >   * @param project the project
> > >   * @param filter artifact filter (can be null
> > > 
> > > @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
> > > 
> > >   */
> > >  
> > >  DependencyNode buildDependencyGraph( MavenProject project,
> > > 
> > > ArtifactFilter filter ) throws DependencyGraphBuilderException;
> > > +
> > > +/**
> > > + * Build the dependency graph including any dependencies contained
> > 
> > in
> > 
> > > the reactor projects. + *
> > > + * @param project the project
> > > + * @param filter artifact filter (can be null
> > > + * @param reactorProjects Map of those projects contained in the
> > > reactor. + *Key is made up of
> > > groupId-artifactId-version. + * @return the dependency graph
> > > + * @throws DependencyGraphBuilderException
> > > + */
> > > +DependencyNode buildDependencyGraph(
> > > +MavenProject project, ArtifactFilter filter, Map > > MavenProject> reactorProjects ) +throws
> > > DependencyGraphBuilderException;
> > > 
> > >  }
> > 
> > -
> > 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: 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

[William Ferguson]

On Mon, May 19, 2014 at 8:49 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:

> Hervé Boutemy 
>  said:
> in interface DependencyGraphBuilder, why expect a Map reactorProjects,
> when a List seems simpler and more natural (result from
> MavenSession.getProjects())?
>
> Good point. We could pass in List and construct the Map
> internally.
> Where/How would you like me to make the change?
> William
>
>
>
> On Mon, May 19, 2014 at 12:51 AM, Hervé BOUTEMY wrote:
>
>> > +DependencyNode buildDependencyGraph(
>> > +MavenProject project, ArtifactFilter filter, Map> > MavenProject> reactorProjects ) +throws
>> > DependencyGraphBuilderException;
>>
>> why expect a Map reactorProjects, when a
>> List seems simpler and more natural (result from
>> MavenSession.getProjects())?
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
>> > Author: jvanzyl
>> > Date: Sat May 17 14:33:40 2014
>> > New Revision: 1595491
>> >
>> > URL: http://svn.apache.org/r1595491
>> > Log:
>> > MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
>> > accepts the reactor projects and resolves dependencies from within the
>> > reactor. - Added multi-module-test to validate that the new method works
>> > against both direct and transitive deps. - Added multi-module-plugin to
>> be
>> > used to validate multi-module-test - Added ProjectReferenceKeyGenerator
>> as
>> > there is currently no public method to generate the key for
>> > MavenProject#projectReferences, MavenSession#projectMap or the Map of
>> > reactor projects that we will use. - Separated the reflective invocation
>> > out into the Invoker class.
>> > - Made maven-project dependency scope=provided as at runtime we want the
>> > version in the maven install, not 2.2.0 Submitted by: William Ferguson
>> > 
>> >
>> ...
>> >
>> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
>> > red/dependency/graph/DependencyGraphBuilder.java (original) +++
>> >
>> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
>> > red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
>> 2014 @@
>> > -22,6 +22,8 @@ package org.apache.maven.shared.dependen
>> >  import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
>> >  import org.apache.maven.project.MavenProject;
>> >
>> > +import java.util.Map;
>> > +
>> >  /**
>> >   * Maven project dependency graph builder API, neutral against Maven 2
>> or
>> > Maven 3. *
>> > @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
>> >  public interface DependencyGraphBuilder
>> >  {
>> >  /**
>> > - * Build the dependency graph.
>> > + * Build the dependency graph from the repository.
>> > + *
>> > + * This is the same as {@link
>> > #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
>> > org.apache.maven.artifact.resolver.filter.ArtifactFilter,
>> java.util.Map)}
>> > with an empty reactorProjects Map. *
>> >   * @param project the project
>> >   * @param filter artifact filter (can be null
>> > @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
>> >   */
>> >  DependencyNode buildDependencyGraph( MavenProject project,
>> > ArtifactFilter filter ) throws DependencyGraphBuilderException;
>> > +
>> > +/**
>> > + * Build the dependency graph including any dependencies contained
>> in
>> > the reactor projects. + *
>> > + * @param project the project
>> > + * @param filter artifact filter (can be null
>> > + * @param reactorProjects Map of those projects contained in the
>> > reactor. + *Key is made up of
>> > groupId-artifactId-version. + * @return the dependency graph
>> > + * @throws DependencyGraphBuilderException
>> > + */
>> > +DependencyNode buildDependencyGraph(
>> > +MavenProject project, ArtifactFilter filter, Map> > MavenProject> reactorProjects ) +throws
>> > DependencyGraphBuilderException;
>> >  }
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

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

[William Ferguson]

Hervé Boutemy 
 said:
in interface DependencyGraphBuilder, why expect a Map reactorProjects, when
a List seems simpler and more natural (result from
MavenSession.getProjects())?

Good point. We could pass in List and construct the Map internally.
Where/How would you like me to make the change?
William



On Mon, May 19, 2014 at 12:51 AM, Hervé BOUTEMY wrote:

> > +DependencyNode buildDependencyGraph(
> > +MavenProject project, ArtifactFilter filter, Map > MavenProject> reactorProjects ) +throws
> > DependencyGraphBuilderException;
>
> why expect a Map reactorProjects, when a
> List seems simpler and more natural (result from
> MavenSession.getProjects())?
>
> Regards,
>
> Hervé
>
> Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> > Author: jvanzyl
> > Date: Sat May 17 14:33:40 2014
> > New Revision: 1595491
> >
> > URL: http://svn.apache.org/r1595491
> > Log:
> > MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> > accepts the reactor projects and resolves dependencies from within the
> > reactor. - Added multi-module-test to validate that the new method works
> > against both direct and transitive deps. - Added multi-module-plugin to
> be
> > used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> as
> > there is currently no public method to generate the key for
> > MavenProject#projectReferences, MavenSession#projectMap or the Map of
> > reactor projects that we will use. - Separated the reflective invocation
> > out into the Invoker class.
> > - Made maven-project dependency scope=provided as at runtime we want the
> > version in the maven install, not 2.2.0 Submitted by: William Ferguson
> > 
> >
> ...
> >
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> > red/dependency/graph/DependencyGraphBuilder.java (original) +++
> >
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> > red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40
> 2014 @@
> > -22,6 +22,8 @@ package org.apache.maven.shared.dependen
> >  import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
> >  import org.apache.maven.project.MavenProject;
> >
> > +import java.util.Map;
> > +
> >  /**
> >   * Maven project dependency graph builder API, neutral against Maven 2
> or
> > Maven 3. *
> > @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
> >  public interface DependencyGraphBuilder
> >  {
> >  /**
> > - * Build the dependency graph.
> > + * Build the dependency graph from the repository.
> > + *
> > + * This is the same as {@link
> > #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> > org.apache.maven.artifact.resolver.filter.ArtifactFilter, java.util.Map)}
> > with an empty reactorProjects Map. *
> >   * @param project the project
> >   * @param filter artifact filter (can be null
> > @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
> >   */
> >  DependencyNode buildDependencyGraph( MavenProject project,
> > ArtifactFilter filter ) throws DependencyGraphBuilderException;
> > +
> > +/**
> > + * Build the dependency graph including any dependencies contained
> in
> > the reactor projects. + *
> > + * @param project the project
> > + * @param filter artifact filter (can be null
> > + * @param reactorProjects Map of those projects contained in the
> > reactor. + *Key is made up of
> > groupId-artifactId-version. + * @return the dependency graph
> > + * @throws DependencyGraphBuilderException
> > + */
> > +DependencyNode buildDependencyGraph(
> > +MavenProject project, ArtifactFilter filter, Map > MavenProject> reactorProjects ) +throws
> > DependencyGraphBuilderException;
> >  }
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Apache Maven SCM Publish Plugin version 1.1

[Hervé BOUTEMY]

Hi,

We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12730&styleName=Html&version=20027

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=12730&status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-1023/
http://repository.apache.org/content/repositories/maven-1023/org/apache/maven/plugins/maven-scm-publish-plugin/1.1/maven-scm-publish-plugin-1.1-source-release.zip

Source release checksum(s):
maven-scm-publish-plugin-1.1-source-release.zip sha1: 
2b75110cc47155c5a2858daed6fa433428e6abf4

Staging site:
http://maven.apache.org/plugins-archives/maven-scm-publish-plugin-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: Let's fix the Rat Check usability fail

[Hervé BOUTEMY]

+1

I think we should have rat on every build by default, and only avoid it if it 
ever cause real performance issue (which doesn't seem to happen)

https://issues.apache.org/jira/browse/MPOM-52 created

Regards,

Hervé

Le dimanche 18 mai 2014 14:38:56 Jason van Zyl a écrit :
> It's the site phase itself that takes a long time.
> 
> On the commons-vfs core module it's takes little time:
> 
> https://gist.github.com/jvanzyl/69c038c0f100803f10db
> 
> I argue that the release should always be in a ready state to release, all
> requirements need to be met at all times in order for this to be the case.
> Aside from the surprise factor at release time when something doesn't work.
> On May 18, 2014, at 2:15 PM, Bernd Eckenfels  wrote:
> > Currently the Rat Report in the Site phase of commons-vfs takes enormous
> > time, for really no good use when the commits are reviewed anyway (and it
> > has all kinds of excludes and warnings you manually need to check).
> > 
> > So I argue it would be better to run it only in relase (candidate) builds.
> > Not sure if the same process applies to maven development.
> > 
> > Greetings
> > Bernd
> > 
> > Am 18.05.2014 um 19:43 schrieb "Jason Pyeron" :
> >>> -Original Message-
> >>> From: Jason van Zyl
> >>> Sent: Sunday, May 18, 2014 13:05
> >>> 
> >>> Right now though we require all files to have license headers
> >>> we do not run the check to verify this by default.
> >> 
> >> Can it be turned off by option?
> >> 
> >>> It kept dinging me until I turned it on by default in Maven
> >>> core. Someone currently trying to contribute has no idea this
> >>> is a requirement and is not told so because it doesn't run by
> >>> default. If it's required how about we just run all the time
> >>> everywhere?
> >> 
> >> What phase?
> >> 
> >>> I would like to change the POMs so that it always runs.
> >>> Having to run RAT separately is a usability fail. The chances
> >>> of anyone contributing knowing they have to run it are pretty
> >>> close to zero.
> >>> 
> >>> Anyone see a reason not to always run it?
> >> 
> >> How much time do they take (add)?
> >> 
> >> -Jason
> >> 
> >> --
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> -   -
> >> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> >> - Principal Consultant  10 West 24th Street #100-
> >> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> >> -   -
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> This message is copyright PD Inc, subject to license 20080407P00.
> >> 
> >> 
> >> 
> >> 
> >> -
> >> 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
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
> 
>   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance


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

Re: Let's fix the Rat Check usability fail

[Stephen Connolly]

+1

On Sunday, 18 May 2014, Jason van Zyl  wrote:

> Right now though we require all files to have license headers we do not
> run the check to verify this by default.
>
> It kept dinging me until I turned it on by default in Maven core. Someone
> currently trying to contribute has no idea this is a requirement and is not
> told so because it doesn't run by default. If it's required how about we
> just run all the time everywhere?
>
> I would like to change the POMs so that it always runs. Having to run RAT
> separately is a usability fail. The chances of anyone contributing knowing
> they have to run it are pretty close to zero.
>
> Anyone see a reason not to always run it?
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> We all have problems. How we deal with them is a measure of our worth.
>
>  -- Unknown
>
>
>
>
>
>
>
>
>
>

-- 
Sent from my phone

Re: Let's fix the Rat Check usability fail

[Jason van Zyl]

It's the site phase itself that takes a long time.

On the commons-vfs core module it's takes little time:

https://gist.github.com/jvanzyl/69c038c0f100803f10db

I argue that the release should always be in a ready state to release, all 
requirements need to be met at all times in order for this to be the case. 
Aside from the surprise factor at release time when something doesn't work.

On May 18, 2014, at 2:15 PM, Bernd Eckenfels  wrote:

> Currently the Rat Report in the Site phase of commons-vfs takes enormous 
> time, for really no good use when the commits are reviewed anyway (and it has 
> all kinds of excludes and warnings you manually need to check).
> 
> So I argue it would be better to run it only in relase (candidate) builds. 
> Not sure if the same process applies to maven development.
> 
> Greetings
> Bernd
> 
> Am 18.05.2014 um 19:43 schrieb "Jason Pyeron" :
> 
>>> -Original Message-
>>> From: Jason van Zyl 
>>> Sent: Sunday, May 18, 2014 13:05
>>> 
>>> Right now though we require all files to have license headers 
>>> we do not run the check to verify this by default.
>> 
>> Can it be turned off by option?
>> 
>>> It kept dinging me until I turned it on by default in Maven 
>>> core. Someone currently trying to contribute has no idea this 
>>> is a requirement and is not told so because it doesn't run by 
>>> default. If it's required how about we just run all the time 
>>> everywhere?
>> 
>> What phase? 
>> 
>>> 
>>> I would like to change the POMs so that it always runs. 
>>> Having to run RAT separately is a usability fail. The chances 
>>> of anyone contributing knowing they have to run it are pretty 
>>> close to zero.
>>> 
>>> Anyone see a reason not to always run it?
>> 
>> How much time do they take (add)?
>> 
>> -Jason
>> 
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> -   -
>> - Jason Pyeron  PD Inc. http://www.pdinc.us -
>> - Principal Consultant  10 West 24th Street #100-
>> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
>> -   -
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> This message is copyright PD Inc, subject to license 20080407P00.
>> 
>> 
>> 
>> 
>> -
>> 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
> 

Thanks,

Jason

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

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: Let's fix the Rat Check usability fail

[Jason van Zyl]

On May 18, 2014, at 1:43 PM, Jason Pyeron  wrote:

>> -Original Message-
>> From: Jason van Zyl 
>> Sent: Sunday, May 18, 2014 13:05
>> 
>> Right now though we require all files to have license headers 
>> we do not run the check to verify this by default.
>> 
> 
> Can it be turned off by option?
> 

It has an option to ignore the errors:

http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html

>> It kept dinging me until I turned it on by default in Maven 
>> core. Someone currently trying to contribute has no idea this 
>> is a requirement and is not told so because it doesn't run by 
>> default. If it's required how about we just run all the time 
>> everywhere?
> 
> What phase? 

It runs in the validate phase.

> 
>> 
>> I would like to change the POMs so that it always runs. 
>> Having to run RAT separately is a usability fail. The chances 
>> of anyone contributing knowing they have to run it are pretty 
>> close to zero.
>> 
>> Anyone see a reason not to always run it?
> 
> How much time do they take (add)?

Negligible in the grand scheme of things. I don't notice on Maven core which is 
still relatively small. For anything here I don't think anyone is going to 
notice it running.

> 
> -Jason
> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -   -
> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> - Principal Consultant  10 West 24th Street #100-
> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> -   -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

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

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: Let's fix the Rat Check usability fail

[Bernd Eckenfels]

Currently the Rat Report in the Site phase of commons-vfs takes enormous time, 
for really no good use when the commits are reviewed anyway (and it has all 
kinds of excludes and warnings you manually need to check).

 So I argue it would be better to run it only in relase (candidate) builds. Not 
sure if the same process applies to maven development.

Greetings
Bernd

Am 18.05.2014 um 19:43 schrieb "Jason Pyeron" :

>> -Original Message-
>> From: Jason van Zyl 
>> Sent: Sunday, May 18, 2014 13:05
>> 
>> Right now though we require all files to have license headers 
>> we do not run the check to verify this by default.
> 
> Can it be turned off by option?
> 
>> It kept dinging me until I turned it on by default in Maven 
>> core. Someone currently trying to contribute has no idea this 
>> is a requirement and is not told so because it doesn't run by 
>> default. If it's required how about we just run all the time 
>> everywhere?
> 
> What phase? 
> 
>> 
>> I would like to change the POMs so that it always runs. 
>> Having to run RAT separately is a usability fail. The chances 
>> of anyone contributing knowing they have to run it are pretty 
>> close to zero.
>> 
>> Anyone see a reason not to always run it?
> 
> How much time do they take (add)?
> 
> -Jason
> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -   -
> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> - Principal Consultant  10 West 24th Street #100-
> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> -   -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
> 
> 
> 
> 
> -
> 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: 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

[Jason van Zyl]

All the formatting and license header issues are resolved. William needs to 
verify the license for one file. Aside from that he can answer any other 
questions here.

BTW, SVN makes this not very fun. I think we should get more aggressive on our 
conversion. Most contributions I'm seeing lately are coming through Github. 
Having to use git-svn or make patches between copies is not really fun.

On May 18, 2014, at 10:51 AM, Hervé BOUTEMY  wrote:

>> +DependencyNode buildDependencyGraph(
>> +MavenProject project, ArtifactFilter filter, Map> MavenProject> reactorProjects ) +throws
>> DependencyGraphBuilderException;
> 
> why expect a Map reactorProjects, when a 
> List seems simpler and more natural (result from 
> MavenSession.getProjects())?
> 
> Regards,
> 
> Hervé
> 
> Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
>> Author: jvanzyl
>> Date: Sat May 17 14:33:40 2014
>> New Revision: 1595491
>> 
>> URL: http://svn.apache.org/r1595491
>> Log:
>> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
>> accepts the reactor projects and resolves dependencies from within the
>> reactor. - Added multi-module-test to validate that the new method works
>> against both direct and transitive deps. - Added multi-module-plugin to be
>> used to validate multi-module-test - Added ProjectReferenceKeyGenerator as
>> there is currently no public method to generate the key for
>> MavenProject#projectReferences, MavenSession#projectMap or the Map of
>> reactor projects that we will use. - Separated the reflective invocation
>> out into the Invoker class.
>> - Made maven-project dependency scope=provided as at runtime we want the
>> version in the maven install, not 2.2.0 Submitted by: William Ferguson
>> 
>> 
> ...
>> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
>> red/dependency/graph/DependencyGraphBuilder.java (original) +++
>> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
>> red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40 2014 @@
>> -22,6 +22,8 @@ package org.apache.maven.shared.dependen
>> import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
>> import org.apache.maven.project.MavenProject;
>> 
>> +import java.util.Map;
>> +
>> /**
>>  * Maven project dependency graph builder API, neutral against Maven 2 or
>> Maven 3. *
>> @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
>> public interface DependencyGraphBuilder
>> {
>> /**
>> - * Build the dependency graph.
>> + * Build the dependency graph from the repository.
>> + *
>> + * This is the same as {@link
>> #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
>> org.apache.maven.artifact.resolver.filter.ArtifactFilter, java.util.Map)}
>> with an empty reactorProjects Map. *
>>  * @param project the project
>>  * @param filter artifact filter (can be null
>> @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
>>  */
>> DependencyNode buildDependencyGraph( MavenProject project,
>> ArtifactFilter filter ) throws DependencyGraphBuilderException;
>> +
>> +/**
>> + * Build the dependency graph including any dependencies contained in
>> the reactor projects. + *
>> + * @param project the project
>> + * @param filter artifact filter (can be null
>> + * @param reactorProjects Map of those projects contained in the
>> reactor. + *Key is made up of
>> groupId-artifactId-version. + * @return the dependency graph
>> + * @throws DependencyGraphBuilderException
>> + */
>> +DependencyNode buildDependencyGraph(
>> +MavenProject project, ArtifactFilter filter, Map> MavenProject> reactorProjects ) +throws
>> DependencyGraphBuilderException;
>> }
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

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

I never make the mistake of arguing with people for whose opinions I have no 
respect.

-- Edward Gibbon

RE: Let's fix the Rat Check usability fail

[Jason Pyeron]

> -Original Message-
> From: Jason van Zyl 
> Sent: Sunday, May 18, 2014 13:05
> 
> Right now though we require all files to have license headers 
> we do not run the check to verify this by default.
> 

Can it be turned off by option?

> It kept dinging me until I turned it on by default in Maven 
> core. Someone currently trying to contribute has no idea this 
> is a requirement and is not told so because it doesn't run by 
> default. If it's required how about we just run all the time 
> everywhere?

What phase? 

> 
> I would like to change the POMs so that it always runs. 
> Having to run RAT separately is a usability fail. The chances 
> of anyone contributing knowing they have to run it are pretty 
> close to zero.
> 
> Anyone see a reason not to always run it?

How much time do they take (add)?

-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 


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

Let's fix the Rat Check usability fail

[Jason van Zyl]

Right now though we require all files to have license headers we do not run the 
check to verify this by default.

It kept dinging me until I turned it on by default in Maven core. Someone 
currently trying to contribute has no idea this is a requirement and is not 
told so because it doesn't run by default. If it's required how about we just 
run all the time everywhere?

I would like to change the POMs so that it always runs. Having to run RAT 
separately is a usability fail. The chances of anyone contributing knowing they 
have to run it are pretty close to zero.

Anyone see a reason not to always run it?

Thanks,

Jason

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

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown

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

[Hervé BOUTEMY]

> +DependencyNode buildDependencyGraph(
> +MavenProject project, ArtifactFilter filter, Map MavenProject> reactorProjects ) +throws
> DependencyGraphBuilderException;

why expect a Map reactorProjects, when a 
List seems simpler and more natural (result from 
MavenSession.getProjects())?

Regards,

Hervé

Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> Author: jvanzyl
> Date: Sat May 17 14:33:40 2014
> New Revision: 1595491
> 
> URL: http://svn.apache.org/r1595491
> Log:
> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> accepts the reactor projects and resolves dependencies from within the
> reactor. - Added multi-module-test to validate that the new method works
> against both direct and transitive deps. - Added multi-module-plugin to be
> used to validate multi-module-test - Added ProjectReferenceKeyGenerator as
> there is currently no public method to generate the key for
> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> reactor projects that we will use. - Separated the reflective invocation
> out into the Invoker class.
> - Made maven-project dependency scope=provided as at runtime we want the
> version in the maven install, not 2.2.0 Submitted by: William Ferguson
> 
> 
...
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> red/dependency/graph/DependencyGraphBuilder.java (original) +++
> maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/sha
> red/dependency/graph/DependencyGraphBuilder.java Sat May 17 14:33:40 2014 @@
> -22,6 +22,8 @@ package org.apache.maven.shared.dependen
>  import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
>  import org.apache.maven.project.MavenProject;
> 
> +import java.util.Map;
> +
>  /**
>   * Maven project dependency graph builder API, neutral against Maven 2 or
> Maven 3. *
> @@ -31,7 +33,10 @@ import org.apache.maven.project.MavenPro
>  public interface DependencyGraphBuilder
>  {
>  /**
> - * Build the dependency graph.
> + * Build the dependency graph from the repository.
> + *
> + * This is the same as {@link
> #buildDependencyGraph(org.apache.maven.project.MavenProject, + *
> org.apache.maven.artifact.resolver.filter.ArtifactFilter, java.util.Map)}
> with an empty reactorProjects Map. *
>   * @param project the project
>   * @param filter artifact filter (can be null
> @@ -40,4 +45,18 @@ public interface DependencyGraphBuilder
>   */
>  DependencyNode buildDependencyGraph( MavenProject project,
> ArtifactFilter filter ) throws DependencyGraphBuilderException;
> +
> +/**
> + * Build the dependency graph including any dependencies contained in
> the reactor projects. + *
> + * @param project the project
> + * @param filter artifact filter (can be null
> + * @param reactorProjects Map of those projects contained in the
> reactor. + *Key is made up of
> groupId-artifactId-version. + * @return the dependency graph
> + * @throws DependencyGraphBuilderException
> + */
> +DependencyNode buildDependencyGraph(
> +MavenProject project, ArtifactFilter filter, Map MavenProject> reactorProjects ) +throws
> DependencyGraphBuilderException;
>  }


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

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

[Hervé BOUTEMY]

there are license problems in this commit

see "mvn apache-rat:check" result:

Unapproved licenses:

  
src/main/java/org/apache/maven/shared/dependency/graph/ProjectReferenceKeyGenerator.java
  src/main/java/org/apache/maven/shared/dependency/graph/internal/Invoker.java
  src/it/multi-module-
plugin/src/main/java/org/apache/maven/its/deptree/ResolveDependenciesLifecycleParticipant.java
  src/it/multi-module-
plugin/src/main/java/org/apache/maven/its/deptree/DummyMojo.java
  src/it/multi-module-
test/moduleZDepsY/src/main/java/org/apache/maven/shared/dependency/ContainingClass.java
  src/it/multi-module-
test/moduleX/src/main/java/org/apache/maven/shared/dependency/SimpleClass.java
  src/it/multi-module-test/expected-tree.txt
  src/it/multi-module-test/invoker.properties
  src/it/multi-module-
test/moduleYDepsX/src/main/java/org/apache/maven/shared/dependency/DependentClass.java
  src/it/multi-module-test/verify.bsh

Regards,

Hervé

Le samedi 17 mai 2014 14:33:41 jvan...@apache.org a écrit :
> Author: jvanzyl
> Date: Sat May 17 14:33:40 2014
> New Revision: 1595491
> 
> URL: http://svn.apache.org/r1595491
> Log:
> MSHARED-336: Added an overloaded method to DependencyGraphBuilder that
> accepts the reactor projects and resolves dependencies from within the
> reactor. - Added multi-module-test to validate that the new method works
> against both direct and transitive deps. - Added multi-module-plugin to be
> used to validate multi-module-test - Added ProjectReferenceKeyGenerator as
> there is currently no public method to generate the key for
> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> reactor projects that we will use. - Separated the reflective invocation
> out into the Invoker class.
> - Made maven-project dependency scope=provided as at runtime we want the
> version in the maven install, not 2.2.0 Submitted by: William Ferguson
> 


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

Re: Why is MavenProject#getprojectRefernceId private?

[William Ferguson]

Yeah, I think we are definitely treading over some of the same path
previously stamped out by the maven-eclipse-plugin.

There are several maps that expose keys for which there are no public
constructors:

groupId-artifactId-version is exposed in :

   - MavenSession#getProjectMap (groupId: artifactId : version)
   - MavenProject#getProjectReferences (groupId : artifactId : version)

groupId-artifactId is exposed in :



   - MavenProject#getArtifactMap (groupId: artifactId)
   - MavenProject#getExtensionArtifactMap (groupId: artifactId)
   - MavenProject#getPluginArtifactMap (groupId: artifactId)

groupId-artifactId-type[-classifier] is exposed in :





   - MavenProject#getManagedVersionMap (groupId: artifactId : type [:
   classifier])

I'm sure there are others I have missed.

It feels like the dependency resolution needs to be its own (configurable)
beast that maven-core and others can call upon.

William


On Sat, May 17, 2014 at 11:34 PM, Jason van Zyl  wrote:

> It honestly should all be closed up. There are odd openings in the API to
> allow strange forms of reactor resolution which is likely what you're
> running into. The most bizarre form of reactor resolution occurs in the
> maven-eclipse-plugin which essentially redoes reactor resolution entirely
> because Maven considers resolution to have happened for an artifact when
> there is a file present. When generating eclipse projects Maven has not run
> to the point of producing a file so inside Maven when trying to find
> referenced projects in the reactor it would fail with the reactor reader
> that is present in master, but the plugin itself goes to some great lengths
> to recast the logic from the file being present as being resolved to the
> artifact being present as being resolved.
>
> There is way, way too much of the guts of Maven exposed for these types of
> resolution activities.
>
> On May 8, 2014, at 6:30 PM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > Since MavenProject#getProjectReferences is public why is
> > MavenProject#getProjectReferenceId (which is the only way of generating
> the
> > key for projectReferences without breaking encapsulation) private?
> >
> > NB in maven-project-2.2 #getProjectReferenceId used to be public.
> >
> > William
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Be not afraid of growing slowly, be only afraid of standing still.
>
>  -- Chinese Proverb
>
>
>
>
>
>
>
>
>
>