o Disabled version-range checking for system-scoped dependencies...will use recommendedVersion where available, if a concrete version is not available.
o Disabled collection of the transitive deps of a system-scoped dep.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@332220 13f79535-47bb-0310-9956-ffa450edef68
o Fixed unit test for resolving direct optional dependencies.
o Added isChildOfRootNode() method in ResolutionNode, to check whether the parent node's parent is null.
o Added check in the artifact collector to include optional artifacts if they are direct dependencies of the root node.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@332213 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Piotr Bzdyl
Reviewed By: John Casey
Applied portions of the patch that pertained to the lifecycle mappings and artifact handlers for ejb3/par. The implementations of these plugins is in the sandbox (or soon will be).
Thanks for the patch, Piotr!
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@332151 13f79535-47bb-0310-9956-ffa450edef68
- MNG-1444: added directory scanner to exclude common directories (subversion, CVS files, etc). Added earSourceIncludes and earSourceExcludes properties to specify the list of tokens to include and exclude respectively.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@332123 13f79535-47bb-0310-9956-ffa450edef68
o Modified private resolveAlways(..) method to throw TransferFailedException, after blacklisting the repository.
o Added handling for the new TransferFailedException as it's thrown from resolveAlways(..). In two cases, where it's not essential that the metadata be non-empty, this exception is ignored. I'm anticipating this will change for 2.1, but for now it's just marked TODO. In the final case (the one that prompted this MNG), the exception is used to inhibit writing of the empty metadata to the local repository when the transfer fails. NOTE: The metadata is still handled the same as before when the system encounters ResourceDoesNotExistException, to prevent re-checking the remote repo on every build.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@331836 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Tomislav Stojcevich
Reviewed by: Stephane Nicoll
Fixed compliance of generated application.xml (display-name and description different in 1.3 and 1.4)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330981 13f79535-47bb-0310-9956-ffa450edef68
core and everything else will come in transitively
o rolling things back to use the 2.0 release maven artifacts, i can
subsequently, deploy 2.0.1-SNAPSHOTs and when 2.0.1 is released I will
release 2.0.1 of the embedder. I think the releases of the embedder must
follow closely on the heels of Maven itself.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330845 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Allan Ramirez
Reviewed By: John Casey
Applied. Thanks, Allan.
Minor change I made was to throw a MojoFailureException with the offending path, rather than logging to the error message-level.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330646 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied Edwin's patch to create the resource-target directory if it doesn't exist. Thanks for the work, Edwin!
Also, I modified this patch slightly per Jerome's suggestion, to fail with a message if outputDir.mkdirs() doesn't succeed. This is fine, since it's within the scope of !outputDir.exists().
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330639 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Jerome Lacoste
Reviewed By: John Casey
I did not apply this patch. A better solution was to initialize the artifact data a little more thoroughly, and only delegate those methods which must track changes to the main artifact (like version info, groupId, and artifactId...essentially, the things that determine how to locate metadata on the repository). For these delegating methods, I've disabled the corresponding setter methods with UnsupportedOperationException to indicate that these attributes must be managed via the main artifact, and why. The MavenProjectHelper will now lookup the proper ArtifactHandler for the given attachment type, and pass that on to the AttachedArtifact constructor also.
Jerome, thanks very much for the effort in exploring this issue. I appreciate the help.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330392 13f79535-47bb-0310-9956-ffa450edef68