workaround style already in place.
Modified it0012 to be useful (it always succeeded!) and added a child
project to demonstrate this commit fixes MNG-805.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@278741 13f79535-47bb-0310-9956-ffa450edef68
o new version of plexus-utils with Xpp3Dom.mergeXpp3Dom(..) modification allows appending of list elements.
o added it0060 to test new functionality.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@240129 13f79535-47bb-0310-9956-ffa450edef68
If a v3 POM is encountered (or any POM where modelVersion is != '4.0.0'), an InvalidModelException is thrown.
This exception extends ProjectBuildingException, to enable piggybacking on the same catch() clause.
When the MavenMetadataSource catches InvalidModelException, it returns a ResolutionGroup with the pomArtifact and empty collections for the pom dependency artifacts and the repository list with which to resolve the empty artifacts set.
Also, added it0059 to test builds where a dependency POM is a v3 pom (missing <modelVersion/>).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@239981 13f79535-47bb-0310-9956-ffa450edef68
o Separated profile injection logic from the inheritance assembly. While they look similar superficially, the
merge-out vs. merge-in semantics make it pretty complex to put this logic together in the same methods. It's
easier to understand what's going on if they remain similar but separate code...
o Added it0058 to test that application of a profile from settings.xml doesn't transport module lists from POM
to POM inside of a reactor build.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@239918 13f79535-47bb-0310-9956-ffa450edef68
o Added includes/excludes for compile and testCompile
o added integration tests for single execution of compile and testCompile with excludes
o Added integration test for multiple execution of compile in different phases per Dan Tran's request
The bulk of this commit is KrisBravo's work (I think that's who Corridor Software Developer is??). Thanks for the help.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@239272 13f79535-47bb-0310-9956-ffa450edef68
o Artifact attachment via MavenProjectHelper was using string literals of the variables I was trying to use to fill in type and classifier (dumb, I know!)
o Source plugin didn't have an @phase for the JarSourceMojo...added, then added the goal configuration in the release profile in the super-pom
o Removed the source plugin bindings for the lifecycle mappings in maven-core
o Re-added [deprecated] method MavenProjectBuilder.build( File, ArtifactRepository, List )...you should use MavenProjectBuilder.build( File, ArtifactRepository, ProfileManager ) instead.
o Added profile handling/injection for the super-pom in two places: in buildStandaloneSuperPom() and in private build(..). This enables injection of the release profile which is provided in the super-pom.
o Added integration test to verify that using -DperformRelease=true results in the sources being attached...to override this behavior, another profile keyed on -DperformRelease could turn the 'attach' param for the source plugin off.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233245 13f79535-47bb-0310-9956-ffa450edef68
o Improving error messages for ResourceDoesNotExistException in the transformations
o Adding specificity to the dependency validation stuff, to output which dependency is offending...
o Added it1013 to show off the new dependency validation stuff.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@232399 13f79535-47bb-0310-9956-ffa450edef68
o Reverted the logic of the DefaultProfileInjector to merge-and-override the model, with the profile being dominant
o Added merging for distributionManagement and modules (conditionally, based on flag) in the modelBase merge
o Refactored the override logic into a couple of methods in ModelUtils to make it easier to understand what's going on here.
o Verified that both the build and the model itself are being merged correctly during profile injection, with profile dominance, but persistence of changes to the model.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@231481 13f79535-47bb-0310-9956-ffa450edef68
o Split profile injection out into its own component away from the defaults assembler
o Moved code common to the defaults assembler and the profile injector into ModelUtils
o Removed the profile-related method from ModelIntheritanceAssembler
o added it0048 to test that profile values will override POM values.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@231294 13f79535-47bb-0310-9956-ffa450edef68
o Modified the PluginMappingDeployMojo in maven-plugin-plugin to always deploy the plugins.xml regardless. This may be a bit heavy, but it avoids the snag with the plugins.xml being detected in the local repository after the install phase runs...plugin mappings weren't making it to the repository during deploy.
o Added a new series of IT: it2xxx which will be tests that require more than a single maven invocation, and will be run via shell script, at least for now. This one builds and deploys a plugin, then attempts to use the plugin by referencing the prefix mapping in the (non-central) remote repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@231058 13f79535-47bb-0310-9956-ffa450edef68
o Added --fail-fast --fail-at-end --fail-never CLI options, with appropriate summary and exclusion of dependent projects from the build when --fail-at-end is specified. Also, implemented it0046 and it1011 to test it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227490 13f79535-47bb-0310-9956-ffa450edef68
o Adding cli-options.txt for three ITs that failed when I cleaned out the local repo
o Fixing the setFile(..) method of ActiveProjectArtifact (hopefully) for Emmanuel's continuum build problem...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226426 13f79535-47bb-0310-9956-ffa450edef68
o Added lines in it0015 and it0020 prebuild-hooks to remove the IT plugins before executing, to avoid weird, intermittent Zip exceptions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226330 13f79535-47bb-0310-9956-ffa450edef68
implement ability to retrieve packaging handlers (lifecycle mappings) from extension plugins. Remove plugin mapping
metadata for the same
integration tests are in place for type handlers but commented out until implemented (41)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225263 13f79535-47bb-0310-9956-ffa450edef68
o Added '-f' CLI option, to allow use of non-standard pom files, or spawning of a build from outside of the project dir.
o Added preferential processing of release-pom.xml over pom.xml if it exists (assumes that the current checkout is a release of the software)
o Moved all file discovery from MavenCli to DefaultMaven, to allow embedders to have access to this logic.
o Modified MavenExecutionRequest to add a flag for reactor-activation and the name of a non-standard pom to use, if appropriate.
o Removed getFiles() and getProjectFiles() from MavenExecutionRequest, since file discovery is now done in the DefaultMaven.
o Added integration tests to check preference of release-pom.xml in standalone and '-r' mode
o Added integration tests to check usage of '-f' option within and outside of the project directory
o Added processing for cli-options.txt to maven-core-it-verifier (Verifier.java) to allow specification of '-f' and '-r' in tests
NOTE: the release plugin still doesn't correctly remove the release-pom.xml from HEAD/trunk, since I don't have access to the SCM remove command from maven-scm. I'm waiting for Emmanuel to finish some API changes before moving to the new maven-scm version, and implementing this final step.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225226 13f79535-47bb-0310-9956-ffa450edef68