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:
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-
+DependencyNode buildDependencyGraph(
+MavenProject project, ArtifactFilter filter, MapString,
MavenProject reactorProjects ) +throws
DependencyGraphBuilderException;
why expect a MapString, MavenProject reactorProjects, when a
ListMavenProject seems simpler and
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
-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
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
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
On May 18, 2014, at 1:43 PM, Jason Pyeron jpye...@pdinc.us 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
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
+1
On Sunday, 18 May 2014, Jason van Zyl ja...@takari.io 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
+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
Hi,
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12730styleName=Htmlversion=20027
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=12730status=1
Staging repo:
Hervé Boutemy https://plus.google.com/u/0/107251243568189719606?prsrc=4
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 ListProject and construct the Map
On Mon, May 19, 2014 at 8:49 AM, William Ferguson
william.fergu...@xandar.com.au wrote:
Hervé Boutemy https://plus.google.com/u/0/107251243568189719606?prsrc=4
said:
in interface DependencyGraphBuilder, why expect a Map reactorProjects,
when a List seems simpler and more natural (result
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 https://plus.google.com/u/0/107251243568189719606?prsrc=4
said:
in interface DependencyGraphBuilder, why expect a Map reactorProjects, when
Hervé Boutemy https://plus.google.com/u/0/107251243568189719606?prsrc=4
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
Hervé Boutemy https://plus.google.com/u/0/107251243568189719606?prsrc=4
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
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
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?
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
Thanks Jason, appreciate it.
William
On Mon, May 19, 2014 at 11:39 AM, Jason van Zyl ja...@takari.io 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
Hervé Boutemy https://plus.google.com/u/0/107251243568189719606?prsrc=4
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
22 matches
Mail list logo
