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
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
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 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
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
Added new mojos to the plugin-plugin that will update the plugins.xml mapping metadata in the plugin's group on the distribution repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@210153 13f79535-47bb-0310-9956-ffa450edef68
o Added component descriptor for the MavenPluginMappingBuilder
o Added a new ComponentDiscoveryListener implementation to factor the DefaultPluginManager out of the plexus.xml for maven-core...the DefaultPluginManager now delegates to this component for plugin registration/lookup/etc. and has proper component requirements.
o Moved the DefaultPluginManager component declaration into components.xml, and added a component definition for MavenPluginCollector to plexus.xml in maven-core
Next step is to get rid of the old pluginKey junk, and start using o.a.m.Plugin instances to hold g🅰️v info for all plugins in the system...this will make the interface cleaner and remove the need to concat/parse the plugin identity. Then, I'll add the mapped-plugin lookup functionality to the lifecycle executor.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209563 13f79535-47bb-0310-9956-ffa450edef68
o Added maven-plugin-mapping project to handle repository metadata that contains prefix-to-artifactId mappings for groups of plugins
o Added builder classes for plugin mappings
o Modified maven-artifact and maven-artifact-manager to handle the concept of repository metadata in addition to artifact metadata.
o Added pluginGroups section to settings.xml, new code to merge these lists of plugin groups, and a unit test to ensure that this merge is taking place properly.
o Added maven-plugin-mapping to dependencies of maven-core, along with the list of builds to be performed by mboot.
Should be ready to incorporate plugin mapping consultation into the lifecycle executor and the deploy mojo...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209550 13f79535-47bb-0310-9956-ffa450edef68
simplified by removing a bunch of duplicated code in addArtifacts - no need to merge, you have the full list.
separated the original artifacts (dependency artifacts) from the resolved artifacts (getArtifacts)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191667 13f79535-47bb-0310-9956-ffa450edef68
split artifact impl from api so that dep resolution can be used independently of wagon
only the first step in making maven-artifact more useful as a public api - more changes to be made
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191634 13f79535-47bb-0310-9956-ffa450edef68
o Added checksumPolicy to artifact repository construction, which meant changing all the places where the factory was called.
o Added two command-line switches (-C=strict-checksum-checking, -c=lax-checksum-checking, or warning)
o Added checksum policy to all repository definitions (profiles.mdo, settings.mdo, maven.mdo)
o Changed the maven-artifact-ant stuff to use a Repository definition with checksumPolicy added to it
NOTE: I just realized that I haven't touched the inheritance/conversion of repository stuff from profiles/settings.xml to the model. I'll do this, and commit the additional changes.
Currently, the default checksum policy is to warn, since there are still bad checksums out there that prevent bootstrapping. Once we chase these down, we can change to default-strict checking. When verifying checksums, SHA-1 is attempted first, with MD5 acting as a backup verification method. If the checksum verification fails legitimately (not related to the process of retrieving/reading the checksum file), then the verification process is repeated ONCE ONLY.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191536 13f79535-47bb-0310-9956-ffa450edef68
refactor artifact creation to all go through the factory, and assign the type handler from there.
Attach EJB client to the EJB artifact so that it is installed/deployed along with it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191096 13f79535-47bb-0310-9956-ffa450edef68
Added specified stop-gap patch for issue: MNG-473 (affects settings-builder and registry-builder)
Today I've made the following progress on this so far:
- Added a new project, called maven-plugin-registry, to house the model for this new file.
- Developed/debugged/tested PluginVersionManager/DefaultPluginVersionManager to isolate the plugin-version checks/management code away from the PluginManager
- Added interactiveMode (<interactiveMode>true|false</interactiveMode> directly under the root element of settings.xml, or -B short CLI option or --batch-mode CLI option, where the CLI options turn OFF interactiveMode). This will allow things like the maven-plugins build to register new plugins (and, for now, new versions of plugins) automatically.
- Added user input handler for when interactiveMode = true, to get a yes/no on whether to use the discovered version over the installed version and/or no version at all. If there is no installed version, and the user selects 'n', then the discovered version is used FOR THAT SESSION ONLY, and won't be recorded in the registry.
- Added checks/recording rejected versions against the registry, before attempting to use the discovered version.
Pending:
- Still need to add update-policies, to determine two things:
1. how often to check for updates
2. what to do when updates are found (autoUpdate, etc.)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190854 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Rahul Thakur
Reviewed by: Brett Porter
Create artifact directories in the wagon so that they are only created when the file will actually be downloaded.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190539 13f79535-47bb-0310-9956-ffa450edef68
Now, we're using all artifacts referenced by the plugin in the artifacts list for that PluginDescriptor...the only drawback is since we're not using a repository layout for the maven /lib, there is no good way to include the artifact-path from /lib...we're using the artifact-file from the local repo for those deps. This SHOULDN'T cause a problem, but it's possible...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190414 13f79535-47bb-0310-9956-ffa450edef68
o Created corresponding runtime exception: InvalidArtifactRTException
o Added error diagnoser for InvalidArtifactRTException
o Changed logError() in DefaultMaven to use error diagnosers (even the devs could use a hand!)
o Added unit test for InvalidArtifactDiagnoser.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@179265 13f79535-47bb-0310-9956-ffa450edef68
o Fixed issue in createXXX(..) method for constructing an artifact with a classifier...it was not actually calling the constructor that passes in the classifier.
PR: MNG-312
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163989 13f79535-47bb-0310-9956-ffa450edef68
This still means ALL tests get the test dependencies of their compile time dependencies. Check if there is really a valid use case for that.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163780 13f79535-47bb-0310-9956-ffa450edef68
o Repoclean still not working with the new artifact/artifactmetadata stuff...the above modifications to the repo layout classes was primarily meant to improve performance when using repoclean.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163736 13f79535-47bb-0310-9956-ffa450edef68
This has ironed out most wrinkles. Still need to implement the snapshot checking cache, and special case the use of installed snapshots over deployed ones.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163706 13f79535-47bb-0310-9956-ffa450edef68
o Removed AbstractArtifactComponent as it was simply delegating to the class and prevented other inheritence for the resolver which seems more appropriate.
o fixed test failure in ProjectClasspathTest due to incorrectly constructed component - using plexus even though still working around the problem with a hack
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163675 13f79535-47bb-0310-9956-ffa450edef68
o Fixed a formatting issue for the layout in DefaultRepositoryLayout relating to groupId's.
o Revamped the repoclean tool to use an Artifact-centric approach to converting, cleaning, and reporting on repositories.
o Added the ability for repoclean to report on the health of an existing v3 or v4 repository, using a DefaultArtifactDiscoverer (Default* being the prefix given to the new repo layout going forward) and a V4PomRewriter implementation.
o Tested repoclean by converting my local m1 repository to a m2 repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163669 13f79535-47bb-0310-9956-ffa450edef68
------------------------
o Factored the layout for a repository into a separate set of components in o.a.m.a.repository.layout
o Added new DefaultRepositoryLayout that uses the repo layout in http://docs.codehaus.org/pages/viewpage.action?pageId=22230 (it is not used by default until we get the repo1 conversion done)
o Added command-line switches to force legacy local-repo or new format (-a/-A, I know, but try to find something that makes more sense!)
o Added path formatting to the repository itself, which is now constructed with a ArtifactRepositoryLayout instance (since layout should be tied to the repository)
o Removed path formatting altogether from the DefaultArtifactHandlerManager.
o Changed the AbstractArtifactBasedComponent (or whatever it's called) to use the repository formatting in the path() and localPath() methods.
o Moved the plugin repo construction (still intact as a hard-coded singleton list) into the DefaultMavenProjectBuilder, where it will eventually build from POM info.
o Added a new method to build an artifact repository for a <distributionManagement/> section, if possible. This reduced the strain on mojos to construct an ArtifactRepository on demand.
o Refactored all *DeployMojo to use #project.distributionManagementArtifactRepository instead of the #settings, #component..ArtifactRepositoryFactory, ... that it used to require. This is a big simplifying step.
o Removed remote artifact repository construction from DefaultMaven, and changed the MavenSession to delegate to MavenProject for remoteArtifactRepositories, just as it does for pluginRepositories.
o Added remoteArtifactRepositories, pluginArtifactRepositories, distributionManagementArtifactRepository to MavenProject as a cache for the higher-level repos used throughout the system. This is project info, so it belongs here.
o Fixed all the tests in maven-core and maven-artifact which I broke. :)
o Dropped what is probably a big format-bomb, since the Eclipse formatter doesn't really handle 'throws Exception' wrapping the right way.
o Added MavenProject to the MavenSession constructor, since there should always be a MavenProject associated with a build, even if it's just the super-pom.
TODO:
--------------------------
- Write an integration/unit test to ensure that the new repo format works with $classifier (was: $extra) and $groupId[0]/../$groupId[n]. This is a simple adaptation of the old layout, but still needs testing.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163638 13f79535-47bb-0310-9956-ffa450edef68
o Adjusted the maven-archetype stuff to work with the new artifact creation/resolution/etc. methods in maven-artifact and maven-core.
o Removed all direct construction of DefaultArtifact and replaced with ArtifactConstructionSupport where it would have involved putting the DefaultArtifactFactory in the plexus.xml, and where the code doesn't need dependency-oriented methods.
o Archetype works now, using the example provided in plexus/plexus-site/src/site/apt/building-plexus-applications.apt
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163615 13f79535-47bb-0310-9956-ffa450edef68
change type of maven plugins to "maven-plugin" instead of plugin.
This should allow other products to have different plugin types, if necessary.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163562 13f79535-47bb-0310-9956-ffa450edef68
o Added ArtifactRepositoryFactory stuff to construct with AuthenticationInfo if possible.
o Added UserModelBuilder stuff for componentizing UserModel construction.
-> DefaultUserModelBuilder has a configuration point 'userModelPath' which can redirect where it reads user.xml from (${user.home} is substitutable here).
o Added warning message to deployment plugin when deployment repo has no authentication info available.
o Added warning message for repos with null <id/> (auth info cannot be assigned here).
o Added a couple of debug-level messages for aid in debugging repo- and userModel-related problems.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163558 13f79535-47bb-0310-9956-ffa450edef68
collection of artifacts.
-> I was previously using a an exclude list but that was only taking into
account the top-level pass of the artifacts so what was happening was
things like maven-core weren't going in repeatedly but all of
maven-core's deps were going in repeatedly. So by using the filter
in the collector that sort of behaviour is stopped and now I can
make the filter do anything I want to account for any weirdisms
I subsequently encounter.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163185 13f79535-47bb-0310-9956-ffa450edef68
o Removed PluginDownloadPhase, since plugin resolution/download has to be a part of the prereq and pre/postGoal resolution, too
o Changed DefaultMaven to execute the session lifecycle, and the component wiring to likewise wire the DefaultMaven with a session lifecycle manager
o Removed the org.apache.maven.decoration package and its contents, since this is all in the model now
o Fixed the GoalResolutionPhase to verify each goal's plugin in turn as it resolves prereqs, preGoals and postGoals
o Fixed the GoalResolutionPhaseTest to work with the new resolution model
o Added a new createGoalExecutionContext to the MavenTestCase base class, to allow me to inject a MavenProject directly rather than a pom file
o Fixed the MavenLifecycleManagerTest to only expect 4 lifecycle phases, now than the plugin resolution and goal decoration phases are obsoleted
o All builds on local machine, but will depend on plexus-0.17.jar/pom and plexus-artifact-container-1.0-alpha-1.jar/pom to build on beaver
o I uploaded plexus-artifact-container-1.0-alpha-1.jar to ${plexus.home}/dist, but cannot upload POMs due to priveleges problem in poms dir.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163007 13f79535-47bb-0310-9956-ffa450edef68
Brett Leslie Porter
John Dennis Casey
Kenney Westerhof
Trygve Laugstol
Jason van Zyl
Emmanuel Venisse
Carlos Sanchez Gonzalez