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
make repository metadata behave more like snapshots with daily updates.
next step is to move the version checking to use that instead and fallback to the old files
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@266298 13f79535-47bb-0310-9956-ffa450edef68
o Dependencies don't have a default scope value, to allow DependencyManagement to set the scope if null...then, the metadata source sets the scope to 'compile' when it constructs the artifacts from deps that still have a null scope. Oh, and it will at that point back-propagate the 'compile' scope to these dependency instances, for later reference...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@240428 13f79535-47bb-0310-9956-ffa450edef68
correct ordering of repositories in POM (also fixed problem of not correctly overriding "central" - properly this time!)
took note of a simpler way to ensure this is correct in future
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@240204 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 transformation manager
o snapshot timestamp/buildnumber is now managed from the transformation rather than the metadata
o maven-archiver now clones the MavenProject and resolves snapshot versions for introduction into manifest and exported pom.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@239219 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 Added @requiresDirectInvocation (was: @cliOnly, but this implies m2 is run from CLI...counter-intuitive for embedding)
o Added handling for new @requiresDirectInvocation (generation/parsing, MojoDescriptor support, etc.)
o Added check in DefaultLifecycleExecutor to throw a LifecycleExecutionException if a mojo specified in a lifecycle binding is marked as direct-invocation only.
o Added MavenProjectHelper/DefaultMavenProjectHelper to provide convenience methods for manipulating MavenProject instances (for example, attaching artifacts or adding resources)
o Removed maven-artifact dependency from maven-source-plugin, and added dependency on maven-plugin-api (should've been there)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233021 13f79535-47bb-0310-9956-ffa450edef68
Fixing profile application to separate profiles discovered in and around POM from those in settings.xml, and apply them separately in the order:
for-each-project-in-inheritance:{POM, profiles.xml}, settings.xml
Added common interface for accumulating, explicitly activating and deactivating, and retrieving profiles to be applied to a given project. This manager interface (ProfileManager) is general enough to be applicable to both the project-level and settings-level profiles.
Added 'performRelease'-keyed profile to super-POM which will be used by the release plugin and anyone using a parallel process, and which will enable '-DupdateReleaseInfo=true' for the deploy mojo, along with enabling the source attachment for the project.
Added 'attach' parameter to JarSourceMojo to allow local POM to turn off source attachments, overriding release profile in super-pom.
Updated the release:perform mojo to use '-DperformRelease=true' for switching on the new release profile, rather than just using '-DupdateReleaseInfo=true'...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@233013 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
and it was obvious: merge code didn't merge the Modules section, and possibly
other sections aswell. Also putting all normal model build info in a profile and
then copying profile data back to the model seemed odd to me. Now only
data from profiles that actually get merged is merged.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@231470 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
Use MavenProject.addResource(..) and .addTestResource(..) to perform this function. I've built a BuildOverlay to insulate the interpolated, initialized Model's Build instance from runtime changes to these, in a similar fashion to addCompileSourceRoots(..), because I wanted to preserve some compat with plugins using ${project.build.resources}.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@230920 13f79535-47bb-0310-9956-ffa450edef68
o Added a check in MavenProject.getArtifacts() to never return null,
but an empty Set, since there's almost no checking.
o Added requiresDependencyResolution test to SurefirePlugin.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@230827 13f79535-47bb-0310-9956-ffa450edef68
o Moved extension-artifact creation and caching to MavenProject, initialized by MavenProjectBuilder, just like plugin-artifacts is.
o Added extension-artifact and report-artifact creation (and initialization in MavenProject) to MavenProjectBuilder, for consistency with plugin-artifacts
o Removed dependency on ArtifactFactory in DefaultExtensionManager (extension artifacts are reachable from MavenProject now)
This makes the process of resolving all artifacts referenced by a project much simpler and more consistent (namely, for the release plugin)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227147 13f79535-47bb-0310-9956-ffa450edef68
under dependencyManagement of m2 and maven-plugins, and removed
versions in all poms having either as a parent.
Used version 1.0.2-SNAPSHOT for plexus-utils as that was used in maven-core
and is not overridable.
o Bumped maven-archiver version to 2.0-beta-1-SNAPSHOT for maven-ear-plugin
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227084 13f79535-47bb-0310-9956-ffa450edef68
MavenProject( MavenProject ) constructor creates an unmodifyable
attachedArtifacts, making it impossible for plugins to attach artifacts.
This constructor is only referenced from DefaultLifeCycleExecutor
in forkLifeCycle, so it's a safe change.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226989 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
This is done to counter the possibility that an artifact's file is set without the artifact actually being resolved, as in the case where the artifact is a snapshot version, but no snapshot-enabled repositories exist (think plugin resolution). This also has the beneficial side-effect of providing a more intuitive method of checking whether an artifact has been resolved (rather than artifact.getFile() != null).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226333 13f79535-47bb-0310-9956-ffa450edef68
o Cleaned up output from discovery of MavenProjectBuilder instance in MavenProjectTestCase.
o Added <relativePath/> to parent in maven.mdo (default value is '../pom.xml')
o Added filesystem parent-POM search using <relativePath/>...if discovered pom doesn't match the parent specification (g🅰️v), then it's not used - the parent is resolved - and search for ancestor POMs on disk goes no further.
NOTE: Next thing is to reactor-ize the release plugin, then MNG-521 should be implemented.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225379 13f79535-47bb-0310-9956-ffa450edef68
o Fixing core-library resolution for expression: ${plugin.artifacts} and ${plugin.artifactMap} (latter is keyed by g:a)
o Modified maven-core-it-plugin to accept something like "-DartifactToFile=org.apache.maven:maven-artifact"...it'll lookup that artifact in ${plugin.artifactMap}, and touch a file that's a mutation of the abs. path for that artifact.
o Added pomArtifact to ResolutionGroup, since the MavenMetadataSource ALWAYS creates a new Artifact for a pom...this allows us to retrieve the resolved Artifact for that pom.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@225234 13f79535-47bb-0310-9956-ffa450edef68
allow separate snapshot and release repositories
deprecate existing snapshotPolicy and checksumPolicy in favour of updatePolicy and checksumPolicy within the <releases> and <snapshots> elements in the <repository> element.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@224707 13f79535-47bb-0310-9956-ffa450edef68
o Changed MavenMetadataSource to a component, to avoid having to lookup artifactFactory and projectBuilder in order to
construct it.
o Added add(..) method to ScmBean in the release plugin to allow addition of release-pom.xml
o Changed the PrepareReleaseMojo to resolve ONLY version and parent-version for the normal pom.xml, and fully resolve all
artifacts used in the release-pom.xml, including version, parent-version, dependency closure (given by project.getArtifacts()), plugins, and reports. It will then add the release-pom.xml, and (attempt to) delete it before performing the final commit for next development version.
o Added some mapping methods to ArtifactUtils, to key by artifact.getId, and to create an Artifact.getId()-compatible string from parameters.
o Added TestProjectBuilder to remove the requirement in ProjectClasspathTest to modify the fields of the project builder directly.
o Cleaned up the AbstractReleaseMojo and PrepareReleaseMojo to avoid container lookups...they're now mojo parameters with the 'component.' prefix.
NOTE: Next step is to figure out how to use maven-scm to remove an SCM resource, to enable the prepare mojo to take the release-pom.xml back out of HEAD after the tag is complete.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@224413 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Kris Bravo
Reviewed by: Brett Porter
add classes directory to compile classpath as some classes are produced during generate-sources to pass to the compiler for XML beans
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@224367 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Rahul Thakur
Reviewed by: Brett Porter
if you define a repository it should override anything in the parent with the same ID
Also, cleaned up logic in assembler based on intentions
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@220240 13f79535-47bb-0310-9956-ffa450edef68
allow a plugin to specify the minimum Maven version (will apply for both building and its execution - this should be separated later).
If you are running an older version then it will not prompt to update when found, and will fail if it is encountered with a hardcoded version.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@220239 13f79535-47bb-0310-9956-ffa450edef68
o Added ResolutionGroup class which contains a set of artifacts and a list of repositories to resolve them.
o Made the ResolutionNode a standalone class, and added the remote repositories to it
o Changed ArtifactMetadataSource.retrieve(..) to return ResolutionGroup rather than Set, in order to help keep track of the repositories which should be used to resolve the retrieved artifacts.
We need some tests for this...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219276 13f79535-47bb-0310-9956-ffa450edef68
To use the new artifact map for either the project or the current plugin from your mojo, simply use one of the following expressions:
${plugin.artifactMap}
${project.artifactMap}
The artifacts in these maps are keyed using org.apache.maven.artifact.ArtifactUtils.versionlessKey( String groupId, String artifactId ) (found in the maven-artifact project).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219234 13f79535-47bb-0310-9956-ffa450edef68
MNG-511
MNG-513
Working on:
MNG-449
o Added code to stop the version manager from prompting the user for unregistered plugins; it will simply register them with the resolved version.
o Added failover fourth plugin-version resolution option, which is a plugin-specific artifact metadata called LATEST.version.txt, and will be published with each install/deployment
o Added MavenProject.get/setArtifact(..) to handle a single artifact instance for a project (allows injection of artifact metadata without having to handle it all within the install/deploy mojos).
o Changed plugin-version resolution to only use MavenMetadataSource rather than resolving the whole plugin artifact.
o Changed the install and deploy mojos to only use ${project.artifact} rather than constructing their own, so they can take advantage of metadata added elsewhere in the build.
o Factored the "RELEASE".equals(..) check in the DefaultRepositoryLayout to use new metadata method storedInArtifactDirectory() instead, since RELEASE and LATEST both share this characteristic.
NOTE: I'm not going to resolve MNG-449 yet, because I'm not sure what else Brett had in mind related to the plugin-development-without-release use case...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@215919 13f79535-47bb-0310-9956-ffa450edef68
o Normalized all references to plugins to use either o.a.m.model.Plugin or o.a.m.plugin.PluginDescriptor instances
o Changed DefaultLifecycleExecutor, PluginManager, DefaultPluginManager, MavenPluginCollector, and DoxiaMojo to reflect the above
o Added mapped-plugin resolution of goal prefixes to the DefaultLifecycleExecutor
o Added caching of PluginMappingManager instance inside of MavenSession
o Modified SettingsUtils to be more resistant to null String-Lists for pluginGroups and activeProfiles during merge.
o Added checks to MavenProject.addPlugin(..) to only add if the plugin doesn't already exist in the model.
Next step is to modify installation and deployment process for plugins to publish plugins.xml repository metadata.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209677 13f79535-47bb-0310-9956-ffa450edef68
Kenney Westerhof
Brett Leslie Porter
Trygve Laugstol
John Dennis Casey
Emmanuel Venisse