so tough noogies for people still trying to use Maven 1.x repositories with Maven 2.x.
The next series of refactoring I will be doing with GIT.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@580609 13f79535-47bb-0310-9956-ffa450edef68
while i transform the settings components to take a MavenSession. Any component executing within Maven should be able to use
a session. the session will contain everything required and any new component added to the system should only take the
session as a parameter. same pattern for all components. that's the goal. it will take a few hops.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573462 13f79535-47bb-0310-9956-ffa450edef68
here i am just collecting all the profile code into one place as it's scattered over several packages and is
hard to determine what the profile system as a whole is doing. the first task i would like to do is decouple
the profile system from the Settings. this can be done at the front-end i.e the profile information from Settings
can be fed into the profile manager up front.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573325 13f79535-47bb-0310-9956-ffa450edef68
related to it. this great simplifies a lot of code
o caching the super project in the default project builder as it's never going to change now as no profiles
are inject so it will only have to be constructed once an instance.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@571910 13f79535-47bb-0310-9956-ffa450edef68
This commit makes sure that pom.* and project.* are resolved using the model reflector,
but if the prefix isn't pom or project, context and model properties are consulted.
If the value still isn't found, the model reflector is used as a legacy fallback,
and a warning is printed.
Also, project.* is deprecated in favour of pom.*.
TODO: env.*.
N.B.: there's loads of warnings about ${artifactId}. I can turn these off,
but if you specify -DartifactId on the commandline, all hell breaks loose.
See http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@549786 13f79535-47bb-0310-9956-ffa450edef68
http://jira.codehaus.org/browse/MNG-2591
Added tests to verify the XML attribute that switches merge-mode from replace/merge to append for children...then, fixed append semantics to force the dominant children (those given by the child POM, in this case) to be appended to those of the recessive/parent-POM configuration.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@545315 13f79535-47bb-0310-9956-ffa450edef68
http://jira.codehaus.org/browse/MNG-2784
NOT applying this patch, as there is a much simpler solution. The processing is currently in the correct order, so all we need to do is make sure the Map.values() method retains this order. Therefore, I changed the Map implementation for plugin executions to LinkedHashMap.
I've also added a test for this issue...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@543599 13f79535-47bb-0310-9956-ffa450edef68
o fix shade plugin so the new uber is produced
o allow plexus-utils back into the mix
o take out the dep.xml assembly descriptor as shade is making the uber jar now
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@531259 13f79535-47bb-0310-9956-ffa450edef68
The order of the tests is important since the same groupId/artifactId/version
combinations are used in different local repositories in the tests, containing
different poms. The DefaultMavenProjectBuilder caches models with g🅰️v,
so it can serve a model from another local repo.
Solved this by changing groupId's in the poms and repositories so they don't
conflict.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@513720 13f79535-47bb-0310-9956-ffa450edef68
* Created org.apache.maven.artifact.manager.ArtifactManager
* Deprecated org.apache.maven.artifact.manager.WagonManager in favor of new ArtifactManager
* Updated the rest of maven to utilize this new ArtifactManager.
* The default wagon providers list is now managed from within wagon-manager's dependency list.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@505520 13f79535-47bb-0310-9956-ffa450edef68
Revert accidental commit on ProjectSorter.java in revision r462868.
I locally modified the ProjectSorter to exclude the build plugins from the DAG
to fix some cycles in the reactor when importing the entire trunk (components,
shared, scm, plugins etc..) in Eclipse. This was never meant to be committed.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@463922 13f79535-47bb-0310-9956-ffa450edef68
NOTE: accidently commited other files too. Only build.xml was
supposed to be committed.
- it0074/pom.xml: leave as is; it fixes a <depedencies> section;
- maven-plugin-tools-java/pom.xml was fixed by jason at revision 462919;
- ProjectSorter.java is fixed in revision 463922;
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@462868 13f79535-47bb-0310-9956-ffa450edef68
Version not taken into account for reactor projects.
Artifacts for reactor projects get replaced by a wrong version local repo artifact.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@419624 13f79535-47bb-0310-9956-ffa450edef68
Submitted by: Jerome Lacoste
Reviewed by: Kenney Westerhof
Modifications: minor cosmetic changes.
Add an 'implementation' parameter to @parameter annotation, so
a default implementation can be specified in Mojo's in case the Mojo parameter
is an interface.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@413054 13f79535-47bb-0310-9956-ffa450edef68
Profiles are activated in random order so overriding settings doesn't produce
the same results on all environments.
Use a LinkedHashMap for the profilesById to preserve profile ordering.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@408021 13f79535-47bb-0310-9956-ffa450edef68
The interpolator was only working based on an incorrect assumption for a limited set of expressions. This assumption is
guaranteed by the solution in the interim, until it can be properly reconsidered. The proper solution would be to not
cache an interpolated model, and to apply path translation and then interpolation after retrieving the cached model. However,
this will require some other related changes and should be planned for 2.1.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@390098 13f79535-47bb-0310-9956-ffa450edef68
o Cleaned up example in the comment-header of the plugin-metadata.mdo
o Added code to initialize a dummy Model instance in MavenProject, to avoid NPEs in things like getId().
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@389203 13f79535-47bb-0310-9956-ffa450edef68
From the original revision log:
--------------------------------------
o Fixed formatting of lines in DefaultMaven to ensure that the output:
[INFO] ----------------------------------------------------------------------
doesn't exceed 80 columns, for readability.
o Fixed error reporting when building a POM's parent, in cases where:
- relativePath refers to a directory, but there is no pom.xml in that directory...in
this case, simply set the parentDescriptor == null, and allow repository resolution
to proceed.
- attempt to resolve parent POM from repository fails...in this case, we need to tell
the user which project specified the missing parent.
Neither of these had any impact on existing tests, and should only improve the user
experience. I don't believe they introduce any ambiguous behavior.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@386447 13f79535-47bb-0310-9956-ffa450edef68
to be checked for in the project builder. I have removed the model caching for now while I'm refactoring
the project builder. The plan is to break the 1000+ lines down into its constituent components and use
a pipeline to build up the project.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@371079 13f79535-47bb-0310-9956-ffa450edef68
new interpolator so the one from 2.0 was used and some envar handling was back ported. Unit tests
have been added for envar handling as well as an IT. The maven-core-it script will now set
an envar which is used in it0090.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@368108 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Bernd Bohmann
Reviewed By: John Casey
Applied patches. These patches added the OS activator to the component descriptor, fixed the activation implementation for it, and finally added a unit test for OS activation.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@355387 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied patch, with small logic fix. This patch will validate that if a systemPath is specified for a dependency, it is absolute. It's possible to use expressions in this path, but by the time it's validated in this step, those expressions will have been resolved.
My change was to add the same validation to managed dependencies.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@354635 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied patches, with minor changes.
These patches will ensure that the optional flag is passed on and inherited correctly when dealing with managed dependencies.
I changed the patches, in that I added a new createDependencyArtifact(..) method on ArtifactFactory, which will eliminate the need to call an older variant of the method by passing in a null value for the inheritedScope parameter.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@354544 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied patch, with small logical fix (used getArtifactId() where getGroupId() was the intention).
This patch will guard against overwriting cached models in the project builder (check for pre-existing model in cache before adding), and will validate that a POM's parent has a different groupId:artifactId than the current POM.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@354473 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
NOT applying this patch. I found a better solution that will factor the interpolation of the POM into a flexible utility in plexus-utils, and will allow introduction of envar resolution to the POM. It will also make interpolating the settings.xml and profiles.xml using any of a number of expression resolvers (using envar resolution only for now).
BTW, I tried using System.getenv(..) in JDK1.4, and it fails with java.lang.Error and a deprecation message. So, I'm using Edwin's code to extract the envars into a Properties object. We can improve this later.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@354462 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: David Jackman
Reviewed By: John Casey
Applied. Thanks, David.
This patch makes the ordering of plugins deterministic after they are merged via inheritance or other mechanism.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@345312 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied. Thanks, Edwin!
NOTE: I added a debug statement in the case where relativePath refers to a directory, to tell the user that we're looking for 'pom.xml' in that dir.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@345109 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: David Jackman
Reviewed By: John Casey
Did not apply this patch. The typo fix in MavenMetadataSource was already fixed, and the xpp3 parse error in the DefaultMavenProjectBuilder didn't need to be wrapped in a ModelValidationResult...Added it to the exception message instead.
Still, thanks for isolating this code for reformatting, David.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@345105 13f79535-47bb-0310-9956-ffa450edef68
Submitted By: Edwin Punzalan
Reviewed By: John Casey
Applied patch, with some modifications. Specifically, changed the validation message when <modelVersion>4.0.0</modelVersion> is not found, added reason to the warning line (no newlines here, just a hint at why it's wrong), and reformatted the debug output to be a bit more terse.
Thanks, Edwin.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@345081 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
Added ArtifactFactory.cloneArtifact(..) +implementation, and made MavenProject(MavenProject) use that to create a copy of the project's artifact.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@330080 13f79535-47bb-0310-9956-ffa450edef68
When the version or type are missing from a dependency a g:a string will
be displayed so you can easily find the problematic dependency in question.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@329419 13f79535-47bb-0310-9956-ffa450edef68
o Removed -cpl and related command line switches for controlling use of LATEST metadata for resolving plugin versions
o Made LATEST the only metadata used to resolve plugin versions, since this is also available when releases are performed
o Added various error diagnostics for project build exceptions
o Enhanced artifact not found error diagnostics
o Removed maven-project and added maven-artifact to maven-surefire-plugin's pom
o Removed the stanza that added pluginArtifacts to the test-booter's classpath...they are already covered by the classpathElements
o Fixed ITs in connection to the removal of -cpl
o Changed the plugin manager to detect whether a plugin's artifact file has changed since the plugin container was created...if so, reload it.
o Took the projecthelp plugin out of the build until I can diagnose the problems with its build (probably tomorrow).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@312827 13f79535-47bb-0310-9956-ffa450edef68
reverting: Fail build if the model contains an expression that doesn't evaluate
(This is the desired behaviour, however there are too many crappy poms in the repo and an issue with the timing of executing the interpolation)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@307315 13f79535-47bb-0310-9956-ffa450edef68
The group ID has changed, so add a bunch of exclusions to ensure the old is not picked up
fix bugs in mboot that wasn't honoring excludes.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@307294 13f79535-47bb-0310-9956-ffa450edef68
o Added check for projectArtifact.isResolved() before attempting to read the model from it within DefaultMavenProjectBuilder, otherwise, stub out a dummy model just like if an ArtifactResolutionException occurs.
o Disabled metadata handling for AttachedArtifact...attachments should be slaves to the main artifact, deriving version info and metadata from it.
o Cleaned up entry for it2003 in maven-core-it/README.txt...that test has been removed.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@295069 13f79535-47bb-0310-9956-ffa450edef68
attempt to move toward true embeddability.
- System properties are still populated in the CLI to make sure that the
system property profile activator functions and the settings are dealt with
correctly. I will look at each of those shortly but this is a first step.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293504 13f79535-47bb-0310-9956-ffa450edef68
o Added AttachedArtifact, and changed the DefaultMavenProjectHelper to create and attach artifacts of this type. AttachedArtifact uses a parent artifact (constructor parameter) for versioning and basic identity attributes, but requires the user to specify a type and classifier specific to the new artifact. We may want to add flexibility for artifactId, too...though I have reservations on that score.
o See it0079 for a test.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293497 13f79535-47bb-0310-9956-ffa450edef68
o Changed default value for usePluginRegistry to 'false' in settings.mdo
o Changed default value for updateInterval to 'never' in plugin-registry.mdo
o Added ActivationOS in settings.mdo, profiles.mdo, maven.mdo
o Added code to the conversion utilities for Settings and Profiles to corresponding maven-model classes for ActivationOS
o Added OS activator for profiles which allows architecture, name, family, and version (with '!' negation of any of these)
o Added ActivationFile to settings.mdo, along with conversion code in the Settings->Model conversion utility
o Added packageWithVersion configuration to the modello plugin definition in maven-settings (this is apparently required now)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293479 13f79535-47bb-0310-9956-ffa450edef68
o Added pluginManagement injection to MavenProject.addPlugin(..) so that no Plugin definition added to the project can go without having managed info injected into it.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293454 13f79535-47bb-0310-9956-ffa450edef68
o Changed the profile activation in it0075 to use a system property which is not always present
o Added projecthelp:active-profiles, package, and clean:clean to the goals list, in case it was only happening with the clean plugin
o Fixed the projecthelp mojos to be aggregators where appropriate
o Changed the ordering of modules in the profile injector (used to be that profile modules were prepended; now, they're appended)
NOTE: I still cannot reproduce the described behavior. Dan: Am I missing something WRT the test setup? I changed the activation trigger to be non-inherent, and I'm not using a boolean string to trigger the profile. What am I doing wrong??
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@292781 13f79535-47bb-0310-9956-ffa450edef68
o Extracting basedir from the project instance when PluginParameterExpressionEvaluator is init'ed if project != null...otherwise, using ${user.dir} from sysprops.
o Extracting values for resolution from POM properties before POM instance during POM interpolation, and adding checks to guard against self-reference of POM elements.
o Added three ITs (one contra) to test these resolutions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291735 13f79535-47bb-0310-9956-ffa450edef68
as a parameter. this method is currently being used in the embedder
o see MNG-1015 for notes on where the monitor may be bested placed. if
everything eventually uses the embedder then it won't matter so much.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291499 13f79535-47bb-0310-9956-ffa450edef68
o We should have a viable offline mode now. Plugin sensitivity updates to follow.
o See it0069 and it1014 for offline mode tests.
o Brett, building maven-plugins in offline mode with org/apache/maven/plugin/* removed will now give a nice error message. :)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@291124 13f79535-47bb-0310-9956-ffa450edef68
o Fixed profile properties cloning in ModelUtils
o Added properties to the test profile in it2002
o Moved the checkout dir for it2002 to be under target, to make it easier to clean.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@290552 13f79535-47bb-0310-9956-ffa450edef68
o Verified that plugins are added to the list in the model when invoked from the command line (878)
o Reformatted ModelUtils after the profiles-cloning addition
o Added cache-flush for the plugin map in MavenProject
o Moved dependencies for subproject/subproject2 into the parent-project POM, inside a profile
o Added activation property for this new profile into the test.sh script
o Added explicit activation inside of release:perform's m2 invocation for all profile-ids active in the release-plugin's execution.
o Added code to remove the dynamic parts of the POM from the release-pom.xml...it's not meant to be a dynamic version of a POM.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@290336 13f79535-47bb-0310-9956-ffa450edef68
o Added complex test case for the release plugin, called it2002.
o Added copying of reportArtifacts and extensionArtifacts sets when one MavenProject is constructed with another.
o Added some logging statements to PrepareReleaseMojo, which I will remove later when I'm done with this rash of bugfixes.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@289294 13f79535-47bb-0310-9956-ffa450edef68
o Added it0068 to guard against regressions of the type causing MNG-836
o Added it2001, which must be run manually, to verify the test case laid out in MNG-757
o Reinstated the repository accumulation for successive traversal down the transitivity chain, so that transitively resolved artifacts can be found in repositories declared by POMs up the chain.
o Added a check for 'file:' at the beginning of the Settings.getLocalRepository() result, before prepending 'file://' to allow for relative definition of the local repository in test cases
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280755 13f79535-47bb-0310-9956-ffa450edef68
when the parent model also has a <parent> and doesn't specify a groupId.
This would also be resolved if maven-model would just have getVersion
and getGroupId implementations that check for the <parent> tag's
versions of these attributes when the current ones are null.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280537 13f79535-47bb-0310-9956-ffa450edef68
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
o Added check for null child pluginManagement section, and setting to parent value if null.
o Added integration test for parent->child pluginManagement inheritance and injection, to prevent regressions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@201693 13f79535-47bb-0310-9956-ffa450edef68
o Pressing [ENTER] at a plugin update prompt should result in the plugin being registered, as indicated by the prompt.
o Use CLI switch '--no-plugin-updates' to suppress usage of the plugin registry
o Use CLI switch '--update-plugins' to force updated/resolved plugin versions to be registered
o Neither of these has a short CLI option, since we're starting to run out of sensible char options for these types of things.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@193082 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 method to MavenProject called writeModel( Writer )
o Added code in MavenArchiver to export the full effective POM to ${project.build.directory}/exported-pom.xml and then embed that in the archive, rather than simply embedding ${project.file}.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191588 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
configure reports according to spec:
- <reporting> section affects reports run through site and standalone
- <build> section affects reports run standalone and overrides anything already in <reporting>
- command line parameters rule all
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191298 13f79535-47bb-0310-9956-ffa450edef68
This fixed a couple of bugs along the way.
One change that this has brought to bear from the document is you now must specify a goal for it to be bound to the LC
(see it0008)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191285 13f79535-47bb-0310-9956-ffa450edef68
o Changed <reports/> in the Model to <reporting/>, to accommodate the <reports/> inside of <reportSet/>.
o Changed the report-plugin class <plugins/> inside of <report[ing]/> to <reporters/>, which means using a new class called Reporter (this is meant to be a Plugin-like model for reports, with reportSets rather than executions...)
o Changed the MavenProject to reflect these two model changes
o Added support to the inheritance assembler to perform deep inheritance of the reporting model (complete with calculations based on the <inherit/> attributes on Reporter and ReportSet).
o Updated DoxiaMojo, Pom, and DefaultPluginVersionManager to reflect the new model classes and MavenProject methods.
This is only round one of the changes for this issue. The next step is to start binding report configuration to the plugin manager via the lifecycle executor (it will traverse the reporting section, and verifyPlugin() to enable direct calls to the report's mojo).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191239 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
o Split ModelNormalizationUtils into two utility classes in the maven-profile and maven-settings projects, to be used for converting Profile instances from the settings.xml and profiles.xml into maven-model instances.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190344 13f79535-47bb-0310-9956-ffa450edef68
o Adding @phase declarations for those mojos that seem to be part of the main build, just for completeness
o Added two ITs, to test that <executions/> doesn't mess up the normal operation, and to test multi-execution for a goal.
Should resolve: MNG-172.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190335 13f79535-47bb-0310-9956-ffa450edef68
Carlos Sanchez Gonzalez
John Dennis Casey
Brian E Fox
Herve Boutemy
Jason van Zyl
Ralph Goers
Brett Leslie Porter
Vincent Siveton
Kenney Westerhof
Patrick Schneider
Andrew Williams
Joakim Erdfelt
Fabrizio Giustina
Milos Kleint
Emmanuel Venisse
Trygve Laugstol