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
Brett Leslie Porter
John Dennis Casey
Emmanuel Venisse
Jason van Zyl
Kenney Westerhof