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
Fixing abstract scripted mojo descriptor extractor to properly construct script resource directories. Also, cleaned up the usage integration test. Ant support works now, but we need to decide what version this should be released under. It will involve re-releasing the plugin-plugin, to take advantage of the new maven-plugin-tools-api, I think.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@329948 13f79535-47bb-0310-9956-ffa450edef68
o Added maven-script-ant to wrapper Ant-based Plexus components in a Mojo-compliant shell
o Added maven-plugin-tools-ant to extract plugin descriptor metadata from Ant-based plugin sources
o Revised the maven-plugin-tools-model, which can be used as a generic companion metadata file for things like Ant-based mojos. It now includes an analogy to @parameter default-value=""
o Added javadoc format for DefaultWagonManager, correcting the name of an exception thrown by the configureWagon() method.
o Changed the required version of maven-plugin-tools-api in the plugin-plugin to 2.0.1-SNAPSHOT, to accommodate changes in the script-based mojo descriptor extractor API. This allows companion metadata files for mojo scripts, as in the case of Ant.
o Removed maven-plugin-tools-beanshell from the plugin-plugin's dependencies. It can be included as a plugin-dependency in the plugin projects that need it, in similar fashion to Ant's extractors.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@326372 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
1.0-alpha-5-SNAPSHOT for all so they're all the same.
o Updated modello plugin invocations in all poms to by adding execution elements
and fixing goals section to get rid of deprecated notation.
o Removed dependency on modello-core in maven-plugin-tools; it seems it
was there because maven-plugin-tools-java used StringUtils from modello -
changed that to use the plexus-utils version.
o Reversed commons-cli version back to 1.0 (brett asked me to, a few days back).
o Updated all models to use fully qualified classnames - do not assume
java.util.* is included! (it won't be anymore from modello
1.0-alpha-5-SNAPSHOT onward).
o Added some <?xml processing instructions to some models that didn't have them
- vim now recognizes these files as XML (so I get syntax highlighting :))
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280539 13f79535-47bb-0310-9956-ffa450edef68
reading/writing configuration values. I briefly discussed this with John but
is up for discussion. We felt the most "bean" like way would be to allow
something like the following:
@parameter property="project"
Which would mean that for that particular field to read/write it a
getProject() and setProject(Project) method would be present.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@279997 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
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
Resolving MNG-488
o Brought the metadata tags for marmalade mojos up to snuff with the java-mojo annotations
o Added @aggregator annotation ( <aggregator>true</aggregator> in marmalade) for mojos
o Added support for aggregator flag throughout plugin-descriptor, generator, and builder.
More commits to follow...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226329 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