[ANN] Maven Enforcer Plugin 1.2 Released
The Maven team is pleased to announce the release of the Maven Enforcer Plugin, version 1.2 The enforcer plugin provides goals to control certain environmental constraints such as Maven version, JDK version and OS family along with many more standard rules and user created rules. http://maven.apache.org/plugins/maven-enforcer-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.2/version /plugin Release Notes - Maven 2.x Enforcer Plugin - Version 1.2 ** Bug * [MENFORCER-135] - Remove log.info in DependencyVersionMap.getVersion * [MENFORCER-139] - Regex rule example is incorrect; matching is not described ** Improvement * [MENFORCER-137] - DependencyConvergence should log only as WARNING instead of ERROR. * [MENFORCER-140] - DependencyConvergence: upgrade maven-dependency-tree dependency to 2.0 for better Maven 3 support * [MENFORCER-141] - Show correct version of the enforcer api / plugin in example ** New Feature * [MENFORCER-97] - Standard rule to check that no dependencies have system scope * [MENFORCER-136] - New enforcer for environment variables * [MENFORCER-138] - Rule to ban all transitive dependencies ** Task * [MENFORCER-144] - generate every enforcer plugin site in /enforcer and redirect previous /plugins/maven-enforcer-plugin * [MENFORCER-145] - use maven-plugin-tools' java 5 annotations Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Enforcer 1.1 Released
The Maven team is pleased to announce the release of the Maven Enforcer, version 1.1 This plugin provides various configurable validation rules for Maven builds. http://maven.apache.org/enforcer/ http://maven.apache.org/plugins/maven-enforcer-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.1/version /plugin Release Notes - Maven 2.x Enforcer Plugin - Version 1.1 ** Bug * [MENFORCER-98] - requirePluginVersions rule is not compatible with maven 3.0-beta-1 * [MENFORCER-114] - Typo in Require Plugin Versions Documentation * [MENFORCER-125] - requireProperty documentation's example for property.version uses wrong regex ** Improvement * [MENFORCER-118] - DependencyConvergence gets better if it doesn't fail on snapshots of same baseVersion ** New Feature * [MENFORCER-128] - Fail the build if a dependency is overwriten with an incompatible lower version (patch) Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Surefire 2.10 Released
The Maven team is pleased to announce the release of the Maven Surefire, version 2.10 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. http://maven.apache.org/plugins/maven-surefire-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.10/version /plugin Release Notes - Maven Surefire - Version 2.10 ** Bug * [SUREFIRE-754] - unbounded memory use when capturing logs * [SUREFIRE-761] - java.lang.NoSuchMethodException when trying to run Junit 3 suite class * [SUREFIRE-763] - environmentVariables fails with useSystemClassLoader=false or forkMode=always * [SUREFIRE-766] - Regression in excludes feature between surefire 2.6 and 2.7. ** Improvement * [SUREFIRE-738] - Fail on not existing run order. * [SUREFIRE-750] - Add custom name suffix for surefire-reports (xml and txt) * [SUREFIRE-752] - Fix duplication in surefire/failsafe sites ** New Feature * [SUREFIRE-755] - Add new reports which default to the failsafe- results Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] License Maven Plugin 1.0-beta-2 Released
Hi, The Mojo team is pleased to announce the release of the License Maven Plugin 1.0-beta-2. This plugin includes several features related to managing the project license and the licenses of project dependencies. http://mojo.codehaus.org/license-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdlicense-maven-plugin/artifactId version1.0-beta-2/version /plugin Release Notes - Mojo - license-maven-plugin-1.0-beta-2 ** Bug * [MOJO-1666] - License plugin fails when previously generated license file is present * [MOJO-1671] - License download-licenses goal doesn't allow parameters to be defined using system properties Enjoy, The Mojo team. Paul Gier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Deploy Plugin 2.6 Released
The Maven team is pleased to announce the release of the Maven Deploy Plugin, version 2.6 This plugin allows artifacts to be deployed to a Maven repository. See the plugin's site for more details: http://maven.apache.org/plugins/maven-deploy-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-deploy-plugin/artifactId version2.6/version /plugin Release Notes - Maven 2.x Deploy Plugin - Version 2.6 ** Bug * [MDEPLOY-112] - deployed snapshot name has different build numbers for multiple artifacts of the same build * [MDEPLOY-123] - http://maven.apache.org/plugins/maven-deploy-plugin/usage.html says maven does not support password hashing ** Improvement * [MDEPLOY-48] - deploy:deploy-file does not support deploying sources jars too * [MDEPLOY-106] - Packaging should not always be required. Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Maven Plugin 1.5.0 Released
Hi, The Mojo team is pleased to announce the release of the JBoss Maven Plugin version 1.5.0. This plugin manages the ability to start/stop the JBoss Application Server and to deploy/undeploy files to the JBoss Application Server. This releases fixes several bugs and provides a couple of minor enhancements. http://mojo.codehaus.org/jboss-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId version1.5.0/version /plugin Release Notes - Maven 2.x JBoss Plugin - Version 1.5.0 ** Bug * [MJBOSS-49] - Console buffer isn't flushed on linux, preventing Jboss SOA-P startup * [MJBOSS-52] - Command arguments not passed correctly to run.sh/shutdown.sh on unix * [MJBOSS-53] - hard-undeploy doesn't cope with exploded archives * [MJBOSS-54] - not runnable run.bat generated on windows * [MJBOSS-55] - jboss plugin incompatible with jboss AS 6 - mojo produces incorrect cmd invocation when starting ** Improvement * [MJBOSS-51] - Remove have a nice day! from hard-undeploy ** New Feature * [MJBOSS-47] - Wait a given app to start * [MJBOSS-57] - Can't skip plugin to run even if tests are skipped and phase is set to test. Enjoy, The Mojo team. Paul Gier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Antlr Maven Plugin 2.2 Released
Hi, The Mojo team is pleased to announce the release of the Antlr Maven Plugin version 2.2. The Antlr Plugin uses the parser generator Antlr v2 to generate source code based on Antlr grammar files. http://mojo.codehaus.org/antlr-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdantlr-maven-plugin/artifactId version2.2/version /plugin Release Notes - Maven 2.x Antlr Plugin - Version 2.2 ** Bug * [MANTLR-1] - ANTLR plugin does not track dependencies based on importVocab/exportVocab options * [MANTLR-3] - ANTLR plugin does not reorder grammars connected by importVocab/exportVocab dependencies * [MANTLR-29] - Impossible to utilize dependent grammars (import/export vocabs) using different packages Enjoy, The Mojo team. Paul Gier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Antrun Plugin 1.6 Released
The Maven team is pleased to announce the release of the Maven Antrun Plugin, version 1.6 This plugin provides the ability to run Ant tasks in a Maven build. See the plugin's site for more details: http://maven.apache.org/plugins/maven-antrun-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId version1.6/version /plugin Enjoy, -The Maven team Release Notes - Maven 2.x Antrun Plugin - Version 1.6 ** Bug * [MANTRUN-152] - Embedded task attachartifact does not work without classifier * [MANTRUN-154] - Antrun double decodes xml escapes * [MANTRUN-155] - Encoding issue with created build-main.xml ** Improvement * [MANTRUN-150] - Update site docs to reflect change to target instead of tasks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Antrun Plugin 1.5 Released
The Maven team is pleased to announce the release of the Maven Antrun
Plugin, version 1.5
This plugin allows Ant tasks to be run within a Maven build. See the
plugin's site for more details:
http://maven.apache.org/plugins/maven-antrun-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-XXX-plugin/artifactId
version1.5/version
/plugin
Enjoy,
-The Maven team
Release Notes - Maven 2.x Antrun Plugin - Version 1.5
** Bug
* [MANTRUN-119] - copy task does not respect failonerror=false
* [MANTRUN-140] - project.build.outputDirectory property is invalid
* [MANTRUN-143] - Regression: 1.4 does not resolve
$(settings.localRepository} or ${localRepository}
** Improvement
* [MANTRUN-132] - Allow the antrun plugin to set the namespace for
the built in tasks.
* [MANTRUN-141] - Merge the AbstractAntMojo with the AntRunMojo
* [MANTRUN-142] - Refactor the tasks parameter to simplify
integration with Ant
* [MANTRUN-144] - Debug info being thrown in System.out.println
* [MANTRUN-145] - Rename ITs so that they describe what they test
* [MANTRUN-146] - Some refactoring seems to have broken the plugin
with Maven 3
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Maven Plugin 1.4.1 Released
The Mojo team is pleased to announce the release of the JBoss Maven Plugin version 1.4.1. http://mojo.codehaus.org/jboss-maven-plugin/ This release includes bug fixes and minor enhancements, specifically related to the way the plugin starts and stops a JBoss server. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId version1.4.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x JBoss Plugin - Version 1.4.1 ** Bug * [MJBOSS-41] - Bug in the site generation that causes the deploy and undeploy mojo pages to not be generated. * [MJBOSS-42] - start-and-wait don't work on a secured jmx-console * [MJBOSS-43] - stop don't work on a secured jmx-console * [MJBOSS-45] - start and stop doesn't work if the server is bound to an address or JNDI port different from localhost:1099 * [MJBOSS-46] - Wrong version of JBOSS is started if JBOSS_HOME env variable is set ** Improvement * [MJBOSS-37] - To allow the deployment of multiple files when using hard-deploy * [MJBOSS-38] - Need to wait for JBoss container to stop before calling start * [MJBOSS-48] - Allow server ID specified on the command line during deployment ** New Feature * [MJBOSS-44] - Patch to allow to pass java options to jboss in the configure goal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] RMIC Maven Plugin 1.1 Released
The Mojo team is pleased to announce the release of the RMI Compiler Maven Plugin version 1.1. http://mojo.codehaus.org/rmic-maven-plugin/ This release includes minors updates to the site and the project configuration. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdrmic-maven-plugin/artifactId version1.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x RMIC Plugin - Version 1.1 ** Improvement * [MRMIC-27] - The example for the package goal is broken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Antrun Plugin 1.4 Released
The Maven team is pleased to announce the release of the Maven Antrun Plugin, version 1.4 This plugin allows Ant tasks to be run inside a Maven build. See the plugin's site for more details: http://maven.apache.org/plugins/maven-antrun-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId version1.4/version /plugin Release Notes - Maven 2.x Antrun Plugin - Version 1.4 ** Bug * [MANTRUN-51] - Problems with multiple antrun declarations in multiproject * [MANTRUN-62] - line.separator property not passed properly to ant * [MANTRUN-104] - Documentation for referring to artifacts classpaths is wrong * [MANTRUN-139] - There is a problem with the site plugin preventing proper site documentation ** Improvement * [MANTRUN-40] - Properties defined in pom properties do not propagate to the antrun environment * [MANTRUN-110] - mistake in antrun docs: refid=maven.dependency * [MANTRUN-126] - Antrun plugin should follow the more common pattern groupId:artifactId:classifier:type pattern for dependency properties. * [MANTRUN-128] - Deprecate sourceRoot and testSourceRoot parameters in favor of using build helper maven plugin * [MANTRUN-135] - Mark antrun plugin as @threadSafe * [MANTRUN-136] - Upgrade to ant 1.8.1 * [MANTRUN-137] - Use ant-nodeps artifact instead of ant and ant-launcher ** New Feature * [MANTRUN-100] - Allow antrun plugin to attach artifacts to maven build * [MANTRUN-138] - Add version mapper to Antrun similar to the Maven Ant tasks ** Wish * [MANTRUN-47] - Provide FileSet references dependencies. Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Ant Tasks 2.1.0 Released
The Maven team is pleased to announce the release of the Maven Ant Tasks, version 2.1.0 The Maven Ant Tasks allow several features of Maven to be used in an Ant build. This includes dependency management, reading and writing pom files, and deployment to a Maven repository. More information is available at the project site. http://maven.apache.org/ant-tasks The current version of the Maven Ant Tasks can be downloaded from the project downloads page. http://maven.apache.org/ant-tasks/download.html Release Notes - Maven Ant Tasks - Version 2.1.0 ** Bug * [MANTTASKS-4] - System scope not working properly in Maven Antlib * [MANTTASKS-152] - Mvn task omit localRepository param * [MANTTASKS-153] - Properties defined in Ant are not passed to Maven * [MANTTASKS-155] - Dependency fileset should set the current ant project * [MANTTASKS-159] - Wrong credentials used for mirrored repositories * [MANTTASKS-160] - Wrong metadata files created for mirrored remote repositories * [MANTTASKS-167] - Generated ant build file should save version list for version mapper ** Improvement * [MANTTASKS-117] - Setting Maven user-properties not possible * [MANTTASKS-169] - Dependencies verbose option should be deprecated in favor of standard ant verbose option ** New Feature * [MANTTASKS-151] - Support for artfacts that are 'classified' from birth * [MANTTASKS-156] - Add feature to dependencies task to write file paths to a file. * [MANTTASKS-168] - New task to write a pom file Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Packaging Maven Plugin 2.1.1 Released
The Mojo team is pleased to announce the release of the JBoss Packaging Maven Plugin version 2.1.1. http://mojo.codehaus.org/jboss-packaging-maven-plugin/ This release includes some minor bug fixes and updates to the plugin site. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.1.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x JBoss Packaging Plugin - Version 2.1.1 ** Bug * [MJBOSSPACK-31] - problems importing 'ejb-client' artifact in PAR ** Improvement * [MJBOSSPACK-32] - Add ability to attach generated .sar to the project, even if classifier is not specifed * [MJBOSSPACK-33] - Packaging types archiver should be matched to JarArchiver instead of ZipArchiver * [MJBOSSPACK-34] - Add site docs about describing attached artifacts - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Maven Plugin 1.4 Released
The Mojo team is pleased to announce the release of the JBoss Maven Plugin version 1.4. http://mojo.codehaus.org/jboss-maven-plugin/ Some notable features in this release include improvements to the start-and-wait mojo and general improvements to the plugin configuration. The plugin site has also been improved and now provides more docs and examples. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId version1.4/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x JBoss Plugin - Version 1.4.0 ** Bug * [MJBOSS-23] - jboss:undeploy causes NPE * [MJBOSS-30] - NullPointerException in UndeployMojo ** Improvement * [MJBOSS-24] - JBoss plugin should be able to read JBOSS_HOME when using JDK 1.5 * [MJBOSS-25] - Refactor to follow Maven code formatting conventions. * [MJBOSS-26] - Should be able to override the parameters for the startAndWait mojo from the command line. * [MJBOSS-28] - harddeploy should skip unconfigured POMs without failing * [MJBOSS-31] - Fix deprecation warnings about using components. * [MJBOSS-32] - Improve parameter configuration * [MJBOSS-33] - Improve site documentation * [MJBOSS-34] - Add a wait period between retries of the JMX Connection when using startAndWaitGoal * [MJBOSS-35] - startAndWait mojo needs a security manager * [MJBOSS-36] - Mojo goal names should follow standard Maven naming format. ** New Feature * [MJBOSS-29] - Add exploded deployment support - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Packaging Maven Plugin 2.1 Released
The Mojo team is pleased to announce the release of the JBoss Packaging Maven Plugin version 2.1. http://mojo.codehaus.org/jboss-packaging-maven-plugin/ Some notable features in this release include handling for the par (process archive) format. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x JBoss Packaging Plugin - Version 2.1 ** Bug * [MJBOSSPACK-17] - deploymentDescriptorFile option needs to be explicitly set ** Improvement * [MJBOSSPACK-25] - Add archiver mappings for each type * [MJBOSSPACK-26] - Create an example in the site docs about how to create a sar using the assembly plugin ** New Feature * [MJBOSSPACK-19] - Create a Par archive for deployable jbpm processes - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Build Helper Maven Plugin 1.4 Released
The Mojo team is pleased to announce the release of the Build Helper Maven Plugin version 1.4. http://mojo.codehaus.org/build-helper-maven-plugin/ This is mainly a bug fix release. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId version1.4/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x Build Helper Plugin - Version 1.4 ** Bug * [MBUILDHELPER-11] - ParseVersionMojo throws NPE when there is no qualifier ** New Feature * [MBUILDHELPER-12] - Version parser should be more flexible with the format of the version string - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Packaging Maven Plugin 2.0 Released
The Mojo team is pleased to announce the release of the JBoss Packaging Maven Plugin version 2.0. http://mojo.codehaus.org/jboss-packaging-maven-plugin/ This is mainly a bug fix and minor refactoring release. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packagin-maven-plugin/artifactId version2.0/version /plugin Please allow up to 24 hours for the new version to sync to the central repository. A comprehensive list of changes can be see in the release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11731styleName=Htmlversion=14186 Regards, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Build Helper Maven Plugin 1.3 Released
The Mojo team is pleased to announce the release of the Build Helper Maven Plugin version 1.3. http://mojo.codehaus.org/build-helper-maven-plugin/ Some notable features in this release include: - A new goal to retrieve the current version of Maven to a property. - A new goal to parse the current project version into it's components (major version, minor version, etc) - A new goal to add resources to a project A comprehensive list of changes is attached at the end of this mail. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId version1.3/version /plugin Please allow up to 24 hours for the new release to synchronize with the central repository. Regards, The Mojo team. Release Notes - Maven 2.x Build Helper Plugin - Version 1.3 ** New Feature * [MBUILDHELPER-4] - build-helper-maven-plugin: Add resources * [MBUILDHELPER-9] - New Mojo to store the maven version in a property * [MBUILDHELPER-10] - Add mojo to set properties containing parsed project version string - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Ant Tasks 2.0.10 Released
The Maven team is pleased to announce the release of the Maven Ant Tasks, version 2.0.10 The Maven Ant Tasks allow several features of Maven, (dependency management, artifact deployment, etc.) to be used within an Ant build. More information is available at the project site. http://maven.apache.org/ant-tasks The binaries can be downloaded from the maven download page. http://maven.apache.org/download.html Release Notes - Maven Ant Tasks - Version 2.0.10 ** Bug * [MANTTASKS-87] - Using a pom.xml for dependencies, in which the pom.xml has a parent pom.xml will cause a Error downloading parent pom error * [MANTTASKS-106] - Maven ant tasks artifact has maven inside the jar and so can't be used from inside the maven (maven-antrun-plugin) - classes do conflict * [MANTTASKS-111] - Support for SNAPSHOT deployment * [MANTTASKS-116] - NPE when install target is missing file and pom type is JAR * [MANTTASKS-142] - Default remote repository id not safe * [MANTTASKS-144] - Error reading settings file error is reported when settings.xml is deleted from maven/conf folder. * [MANTTASKS-145] - Dependency management doesn't work with pom and dependencies tasks ** Improvement * [MANTTASKS-35] - Support profiles in pom type * [MANTTASKS-114] - improve documentation * [MANTTASKS-146] - Improvements to site documentation * [MANTTASKS-147] - Improvements to scope filtering ** New Feature * [MANTTASKS-71] - running m2 inside Ant * [MANTTASKS-149] - Allow multiple types in the type filter * [MANTTASKS-150] - Add option for creating fileset refs for each resolved artifact. Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Source Plugin 2.1 Released
The Maven team is pleased to announce the release of the Maven Source Plugin, version 2.1 This plugin is used to create jar of the project source files. http://maven.apache.org/plugins/maven-source-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.1/version /plugin Release Notes - Maven 2.x Source Plugin - Version 2.1 ** Bug * [MSOURCES-28] - No test for up todate/no ablity to exclude pom.properties from resulting jar * [MSOURCES-31] - forking lifecycle of source:jar goal results in release-plugin error * [MSOURCES-36] - Source jar manifest should contain Specification and Implementation details * [MSOURCES-37] - CLONE -maven-source-plugin causes generate-sources phase to execute twice * [MSOURCES-40] - Add throws MojoExecutionException on getSources() mehtod ** Improvement * [MSOURCES-13] - No-Forking mojos for use within a POM instead of CLI * [MSOURCES-34] - Allow the artifact type to be changed * [MSOURCES-39] - Add an includePom option to the sources:jar goal ** New Feature * [MSOURCES-41] - Generate source jars supporting Eclipse Source Bundle format. ** Wish * [MSOURCES-33] - provide includes excludes configuration * [MSOURCES-42] - Please add support for MavenArchiveConfiguration Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin - testFailureIgnore and its behaviour with forkMode
As far as I know, it's not expected behaviour. If you can create a jira issue with a sample project to reproduce this, I'm sure someone can take a look. Also, try version 2.4.3 since that is the latest. Jaikiran wrote: I am using Maven surefire plugin 2.4.2 with the following configurations: plugin artifactIdmaven-surefire-plugin/artifactId configuration ... testFailureIgnorefalse/testFailureIgnore ... forkModealways/forkMode ... /configuration /plugin I have intentionally set testFailureIgnore=false (i.e. the default value), so that if the test fails the build process fails. However when my tests fail with ERROR, i see that irrespective of this property value, the rest of the build is carried out and the build reports a SUCCESS. A bit of debugging and playing with the forkMode, shows that the testFailureIgnore=false results in the build to fail (which is what i expect) *only* when the forkMode is set to never. Setting the forkMode to always or once always results in a successful build irrespective of the testFailureIgnore setting. Is this the expected behaviour? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate name in parent and current
I think it's the duplicated artifactId's that is causing the problem. Maybe the artifactId of the pom in the subdirectory modA/modA should be set to modA-modA or something like that. huser wrote: Hi, I have a situation in which the dir names are same. Example: /base /base/modA /base/modA/modA I get the following error while trying to run mvn compile. The code for 2 POM's is below. What should I change in the parent to make this work ? Thanks, Reason: Parent element is a duplicate of the current project for project com.co.t3:modA [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parent element is a duplicate of the current project for project com.co.t3:modA at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) /base/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdt3/artifactId version1.0-SNAPSHOT/version relativePath../base/pom.xml/relativePath /parent name modA /name groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingpom/packaging version1.0-SNAPSHOT/version /base/modA/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingjar/packaging version1.0-SNAPSHOT/version - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven2 properties reference page
There is an associated JIRA issue related to this [1]. Please vote for it if you are interested. [1]http://jira.codehaus.org/browse/MNG-3720 Rusty Wright wrote: Why does the url for MavenPropertiesGuide start with docs.codehaus.org? I would think it should start with maven.apache.org. I recently spent a long time one day looking for a list of the maven properties on the apache maven site and finally gave up. I am repeatedly frustrated by the documentation on the apache maven site. I suspect that this is hindering the adoption of maven. Wayne Fay wrote: Why aren't any of these properties documented for Maven2? Is anyone aware??? Can I use them with Maven2 without having problems? http://maven.apache.org/maven-1.x/reference/properties.html As you said, those properties are for Maven1. You can generally assume they will not work for Maven2. The corresponding page for Maven2 is in the wiki: http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Properties maven plugin 1.0-alpha-1 Released
The Mojo team is pleased to announce the release of the Properties Maven Plugin version 1.0-alpha-1. http://mojo.codehaus.org/properties-maven-plugin/ This is the first alpha release of the plugin. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdproperties-maven-plugin/artifactId version1.0-alpha-1/version /plugin Regards, Paul Gier - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Rmic Maven Plugin 1.0 Released
The Mojo team is pleased to announce the release of the Rmic Maven Plugin version 1.0. http://mojo.codehaus.org/rmic-maven-plugin/ This is the first stable release and fixes a few issues from the previous beta. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdrmic-maven-plugin/artifactId version1.0/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, Paul Gier Release Notes - Maven 2.x RMIC Plugin - Version 1.0 ** Bug * [MRMIC-23] - rmic creates multiple stub files when run multiple times * [MRMIC-24] - rmic is run even when the classes are already up to date ** Improvement * [MRMIC-25] - Add configuration for testOutputDirectory * [MRMIC-26] - Fix checkstyle errors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] JBoss Packaging Maven Plugin 2.0-beta-1 Released
The Mojo team is pleased to announce the release of the JBoss Packaging Maven Plugin, version 2.0-beta-1 http://mojo.codehaus.org/jboss-packaging-maven-plugin/ This plugin is a replacement of the earlier jboss-sar-maven-plugin. The plugin has been deployed to the codehaus repository, and it should be available shortly via the central repository. plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.0-beta-1/version /plugin Release Notes ** Bug * [MJBOSSPACK-1] - jboss-packaging plugin does not include ejb-client jars * [MJBOSSPACK-2] - Dependency scope not respected * [MJBOSSPACK-3] - Dependency to project with packaging-type 'jboss-sar' doesn't work * [MJBOSSPACK-6] - Source repository - Web access redirects you to a missing 404 URL * [MJBOSSPACK-7] - Add pluginRepository definition to the docs * [MJBOSSPACK-8] - SAR plugin does not work with cobertura report * [MJBOSSPACK-10] - Add pom configuration example to docs ** Improvement * [MJBOSSPACK-15] - Set up integration tests using maven invoker plugin * [MJBOSSPACK-16] - Fix checkstyle warnings Enjoy, -The Mojo team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] RMIC Maven Plugin 1.0-beta-1 Released
The Mojo team is pleased to announce the release of the RMIC Maven Plugin version 1.0-beta-1. This release contains some minor enhancements and bug fixes. A list of changes is attached at the end of this mail. Enjoy! Paul Gier Release Notes - Maven 2.x RMIC Plugin - Version 1.0-beta-1 ** Bug * [MRMIC-19] - dependencies with scope provided are not considered within rmic * [MRMIC-20] - No stubs are created for remote interfaces in IIOP mode ** Improvement * [MRMIC-13] - Create basic unit tests and/or integration tests. * [MRMIC-18] - Fix some java 1.5 specific code. * [MRMIC-21] - Should have a documented way to put the stubs in the main jar ** New Feature * [MRMIC-12] - Add support for running rmic against the test classes directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set the classifier of an Artifact for install-plugin ?
Assuming you are creating a DefaultArtifact object, you have to set the classifier when you first call the constructor. Does that work for you? https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/DefaultArtifact.java Guillaume Durand wrote: Hello, I wrote a packaging plugin replacing the jar-plugin and accepting a classifier as parameter to generate the proper artifact name. Once the artifact is created I use Artifact.setFile with the newly created artifact. It works fine but the install-plugin copies the artifact into the repository without the classifier. If the package plugin is jar-plugin the classifier is kept though. How do I set in my plugin the classifier to use for the install-plugin? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to override POM properties from CLI
This seems to work ok for me. I tried it locally and my profile properties override my pom properties, and cli props defined with -D override both pom and profile properties. I tried with maven 2.0.6 and 2.0.8. Can you attach a small zipped project to a jira issue that reproduces the problem? Igor Romanov wrote: Thank you for reply. Are you saying that properties specified in POM can not be overridden with -D option? Igor Wayne Fay wrote: You should put the properties in different profiles, and then specify which profile using -Penv1 when running Maven. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rmic maven plugin 1.0-alpha-1 release
For anyone that uses rmic in their builds, I have released the rmic-maven-plugin version 1.0-alpha-1. It is now in the codehaus repository, and it should be available via the central repository later today. Please check it out and submit feedback through jira. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plugin (prepare) doesn't update more than one dependencies in multi modules project
Sorry this is not much help, but I haven't had good luck with getting the
release plugin to update my snapshot dependencies either. So I always update
them manually before doing a release. If you can create a jira issue for this
(in the release plugin project) and attach a small test project to reproduce the
problem, I'm sure someone will get around to take a look at this.
alexsil wrote:
Hi all,
I have a project so structured:
au au-business
|
|--- au-sistema
Dependencies in au are:
...
dependencyManagement
dependencies
dependency
groupIdcom.zucchetti.qweb.au/groupId
artifactIdau-business/artifactId
version${project.version}/version
/dependency
!-- external dependencies--
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdsistema/artifactId
version03.00.02-SNAPSHOT/version
/dependency
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdbusiness/artifactId
version03.00.02-SNAPSHOT/version
/dependency
/dependencies
/dependencyManagement
...
Dependencies in au-business are:
...
dependencies
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdbusiness/artifactId
/dependency
/dependencies
...
Dependencies in au-sistema are:
...
dependencies
dependency
groupIdcom.zucchetti.qweb.au/groupId
artifactIdau-business/artifactId
/dependency
dependency
groupIdcom.zucchetti.qweb.framework/groupId
artifactIdsistema/artifactId
/dependency
/dependencies
...
When I make a mvn release:clean release:prepare the plugin, correctly, ask
me to resolve SNAPSHOTs dependencies. (framework-business
framework-sistema)
Unfortunatly at the end of the process only framework-sistema has been
modified, while framework-business no.
I've debuged the problem and I found that if I force the two dependencies
(framework-sistema, framework-business) in the parent pom (pom of au) all
run fine (also if the process to resolve SNAPSHOT dependencies get prompted
tree times ... too much I say ...).
Is this the correct behavior ?
I hope no, becouse I should modify al my poms.
Morever , the flag updateDependencies=false doesn't run. I think it has
not managed.
Best regards
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: release from a specific tag
I would think checking out from the tag, and then running release:prepare from that would work fine for you in this case. It will create another tag, but that shouldn't be a problem, since you probably want to keep one tag nightly x/x/x and then another tag release x.x.x even though they have basically the same code. There's nothing in the release plugin, as far as I know, that says you have to be working from trunk. Benoit Decherf wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf [EMAIL PROTECTED] wrote: But I don't want to create an official version every night. In the nightly version, there still have the -SNAPSHOT versions. So I can't use release:perform to do it. I realy need to execute the release:prepare from the nightly tag. All projects here ask for this feature. I think this is a very good feature to be able to release an unofficial version that is entirely tested. It seems strange that nobody has asked for this feature. All of you always create a version from the last commits files of the trunk (integration branch) ? Is it possible to make an evolution of the release plugin to support this ? Benoit Nicole Lacoste wrote: Hi Benoit, Yes I think so. Well I know you can release from a tag made with the release prepare. The command is mvn release:perform -DconnectionUrl=scm:svn:file://your-url-here/tag-name Look at page 224 of better builds with maven for more details Nicole On 06/02/2008, Benoit Decherf [EMAIL PROTECTED] wrote: Hi, I think that we should be able to perform a release from an old nightly tag rather than do it always from the trunk : Every night functional tests run on a project A. On day d everything works, but after, I decide to add a feature and I broke the trunk. I'd like to be able to release the project in it's state of day d without losing the work I done. This could be useful in some cases. Is there already a way to do it ? Benoit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generate PDF books from maven
Hi Julien, Can you create a jira issue for the jboss maven-jdocbook-plugin with some sample input? Here is the jira URL (http://jira.jboss.com/jira/browse/MPJDOCBOOK). Then maybe we can get it fixed. Tahnks! Julien Graglia wrote: What do you use to generate PDF books? I'am using doxia-maven-plugin to generate html books, but the pdf format is 'deprecated' because it is generated by iText and iText no longer support pdf output. (http://maven.apache.org/doxia/modules/index.html). I have pb with UTF 8 encoding of french pages...(it is a known pb of iText...) I have read that from the doc-book output of doxia, I can generate a PDF book but I don't have found how...docbook seems very dark to me : need a xsltranslator , how? not a word of doxia site... I also have found the JBoss Plugin : maven-jdocbook-plugin (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't get correct result : i try to inject the docbook xml generated by doxia, but it is invalid for jdocbook plugin...I have made some hand made corrections to the xml... but the result is awfull... Well, I try many things, but did not found ONE way to generate a pdf from maven What do you use? and how? Thanks! May be it's just a dream? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release from a specific tag
Sorry, I was thinking you were using svn. Maybe you should convert ;) Yes, when I said the code is the same, I meant your project code minus the changes to the pom. So maybe you would need to do something like 1. checkout the tag 2. make a branch 3. check the code from the tag into the branch 4. make the changes to the pom. Then run your maven release. I agree this is not a very nice process. Benoit Decherf wrote: A tag is a fixed version, not a branch. So I can't make a release:prepare on a tag. This can probably be done in svn because there is no real difference between a tag and a branch, but that's not true in cvs. The nightly x/x/x and the release x/x/x are not the same code. The pom of a release has no SNAPSHOTs dependencies. Paul Gier wrote: I would think checking out from the tag, and then running release:prepare from that would work fine for you in this case. It will create another tag, but that shouldn't be a problem, since you probably want to keep one tag nightly x/x/x and then another tag release x.x.x even though they have basically the same code. There's nothing in the release plugin, as far as I know, that says you have to be working from trunk. Benoit Decherf wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf [EMAIL PROTECTED] wrote: But I don't want to create an official version every night. In the nightly version, there still have the -SNAPSHOT versions. So I can't use release:perform to do it. I realy need to execute the release:prepare from the nightly tag. All projects here ask for this feature. I think this is a very good feature to be able to release an unofficial version that is entirely tested. It seems strange that nobody has asked for this feature. All of you always create a version from the last commits files of the trunk (integration branch) ? Is it possible to make an evolution of the release plugin to support this ? Benoit Nicole Lacoste wrote: Hi Benoit, Yes I think so. Well I know you can release from a tag made with the release prepare. The command is mvn release:perform -DconnectionUrl=scm:svn:file://your-url-here/tag-name Look at page 224 of better builds with maven for more details Nicole On 06/02/2008, Benoit Decherf [EMAIL PROTECTED] wrote: Hi, I think that we should be able to perform a release from an old nightly tag rather than do it always from the trunk : Every night functional tests run on a project A. On day d everything works, but after, I decide to add a feature and I broke the trunk. I'd like to be able to release the project in it's state of day d without losing the work I done. This could be useful in some cases. Is there already a way to do it ? Benoit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Upcoming rmic plugin release
Hi Everyone, I'm currently doing some work on the rmic maven plugin, and I plan to do a 1.0-alpha-1 release in the upcoming weeks. If you use this plugin or you are interested in it, please take a look at some of the jira issues (http://jira.codehaus.org/browse/MRMIC). If there are issues that you agree or disagree with, please comment and/or vote on the issues, and create new issues for desired features, bugs, etc. Thank! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JavaCC Maven Plugin 2.3 released!
Hi Everyone, The JavaCC maven plugin version 2.3 has been released, and should show up in the central maven repository later today. This release includes several bug fixes, a couple new features including a new jjdoc mojo, and some improvements to the project site (http://mojo.codehaus.org/javacc-maven-plugin). A list of all the changes in this release can be found in the release notes (http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11216styleName=Htmlversion=13802). Enjoy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release 2.3 of javacc maven plugin
Hi Everyone, I'm planning to do a release of the javacc maven plugin (http://mojo.codehaus.org/javacc-maven-plugin/) sometime next week. If you use this plugin or are interested in it, I encourage you to try out the 2.3-SNAPSHOT that is available in the codehaus snapshots repository. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant tasks to deploy a jar
Has anyone successfully deployed a jar file to a maven repository using the artifact:deploy ant task? I tried using this task with both maven 2.0.6 and maven 2.0.8, and it would only deploy the pom files and not the jar. I ended up using ant exec/ and just calling mvn deploy:deploy-file. I'm wondering if I'm just missing something? Or if this is broken I will create a jira issue. Also if anyone has other suggestions about the easiest way to deploy ant built jars into a maven repo I would appreciate your ideas. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Downloading dependency sources
Hi Everyone, Is there a way to tell maven to download source jars by default? I didn't see anything in the pom or settings model to do this. I know I can download sources using the eclipse plugin or the dependency plugin, but I would like to tell maven to always download source jars when building a project. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Control transitive dependencies
You can also use mvn project-info-reports:dependencies That will generate an html page with the dependency tree in the target/site directory. That should make it a little easier to figure out where transitive dependencies are coming from. Erez Nahir wrote: Thanks Larry for the prompt and detailed reply. The strange thing is that maven debug info (and the dependencies reports) shows only the dependency on 1.2.14, it does not list who uses 1.2.12 (I figured it out by searching the poms in my local repository). Anyway, I'll give it a try. Thanks, Erez. BTW, this is on maven 2.0.7 Larry Suto wrote: There are a few ways: mvn -X will give you the debug output and will show the transitive that are brought in by the main dependencies, though I found this to be a bit tricky to use...my preferred way is too find the jars in my project(s) that mvn bundles a pom.xml in...if you look ar the pom.xmls in these jars you will find the dependencies they are bringing inyou then need to declare the jar as a dependency in the pom.xml in the particular artifact you want this excluded in and add excludesexcludes...place only groupId and artifactId inside here.../exclude/excludes inside the dependency declaration or you can add the tag in the jar plugin config that excludes the pom.xml if you have control over the build...then you dont have to worry about this stuff On 8/25/07, Larry Suto [EMAIL PROTECTED] wrote: There are a few ways. mvn -X will give you debug output On 8/25/07, EN [EMAIL PROTECTED] wrote: Hi, We have a multi module project: parent - pom, dependencyManagement proj1 - jar proj2 - jar proj3 - war Although we use log4j 1.2.14, our proj3.war file contains log4j 1.2.12 which probably added by maven as transitive dependency of one of our dependencies (activemq-parent-4.1.1.pom or commons-logging-1.1.pom). How can I force maven to package only log4j 1.2.14? Thanks, Erez. -- View this message in context: http://www.nabble.com/Control-transitive-dependencies-tf4330206s177.html#a12332508 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Access Execution Id from plugin
Anyone know how to get the current execution Id from within a plugin? I would like to be able to compare the current execution Id to a system property while the plugin is running. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Property validation
I would like to verify that certain properties are set in my pom. If the property is not set, I would like the build to fail. Is there a way to do this with the enforcer plugin or with another plugin? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
One profile activate another
I would like to have two profiles. One profile can be called by itself. The second one should activate the first one so that the configuration of the first is included. Is this possible? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0.6 using JDK 1.3
It seems like a better default behavior for the compiler plugin would be
to use the current jvm version.
If I'm running maven with jdk1.5 I would expect the compiler plugin to
default to source level 1.5.
Is there a reason that it can't work like that?
Wayne Fay wrote:
This is one of the most common questions on this list...
It has been answered repeatedly -- check the archives at Nabble.
Also it is very well documented on the Maven website -- both in the
FAQ and in the Maven Compiler plugin docs.
Google also has numerous links when you search for maven generics.
Wayne
On 5/4/07, David Smith [EMAIL PROTECTED] wrote:
I'm having a problem compiling my project with maven 2.0.6. Maven is
using JDK 1.3 to compile the java files that contain generics. The
build fails with an error stating that 1.3 does not support generics.
How do I switch JDKs so that maven will use 1.5 instead of 1.3? My
classpath and path variables both point to 1.5.
---
[INFO] Building Unnamed - com.javaworld.hotels:HotelDatabase:jar:0.0.1
[INFO]task-segment: [package]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 2 source files to
C:\workspace.3.2.2\HotelDatabase\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
C:\workspace.3.2.2\HotelDatabase\src\main\java\com\javaworld\hotels\mode
l\HotelM
odel.java:[22,19] generics are not supported in -source 1.3
(try -source 1.5 to enable generics)
public ListHotel findHotelsByCity(String city){
C:\workspace.3.2.2\HotelDatabase\src\main\java\com\javaworld\hotels\mode
l\HotelM
odel.java:[24,32] for-each loops are not supported in -source 1.3
(try -source 1.5 to enable for-each loops)
for(Hotel hotel : hotels){
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Specify snapshot build number
Is there a way I can specify which snapshot build my project should use in it's dependencies? I would like maven to ignore the latest snapshot version, and refer to a specific snapshot build number. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Questions about surefire plugin
How do I change the log level of the surefire plugin? I would like to change the log level from DEBUG to INFO. If I have multiple execution IDs in my surefire configuration, is there a way to run just one of the executions? I could do it using profiles, but I was wondering if there is an easier way. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing an execution id from pom
Is there a way I can access the current execution ID if I have multiple
executions of a plugin?
I have multiple executions of the surefire plugin, and I would like the
output to go to a different directory for each execution.
So in my plugin configuration I would like to have something like:
configuraiton
reportsDirectory|surefire-reports/${executionId}|/reportsDirectory
/configuration
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Attached artifacts
When working on a maven plugin, I noticed that two attached artifacts can have the same name and overwrite each other when they are deployed. Is this by design? Maybe the artifacts attached to a project should be a set instead of a list, and a warning should be generated when one artifact replaces another. An easy way to reproduce this is to define the maven source plugin with two different execution ids. When the deploy plugin is run, the source jar is deployed twice, with the second overwriting the first. Changing the attached artifacts from a List to a Set would probably break a bunch of existing code, but it might be something for a maven 3.0 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multi module assembly with dependencies
I'm trying to create an assembly for a multi-module project that
includes the dependencies of the modules.
My assembly descriptor looks something like this:
assembly
idstandalone/id
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
moduleSets
moduleSet
includes
includegroup:moduleA/include
includegroup:moduleB/include
/includes
binaries
outputDirectorymodules/${artifactId}/outputDirectory
unpackfalse/unpack
dependencySets
dependencySet
unpackfalse/unpack
outputDirectorylib/outputDirectory
/dependencySet
/dependencySets
/binaries
/moduleSet
/moduleSets
/assembly
I get an error that says the dependencySets tag is not recognized. I'm
using version 2.1 of the assembly plugin. Is dependencySets only
supported in 2.2-SNAPSHOT? Or am I doing something else wrong.
Thanks!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Transitive dependencies of artifacts with classifiers
How are transitive dependencies handled when the artifacts have a non-default classifier? For example, I have the following dependency tree: A - B B - C Now let's say I want to build a jdk1.4 version of A. So I depend on B-jdk14.jar (B with jdk14 classifier), and B-jdk14.jar depends on C-jdk14.jar. Is it possible to include the C-jdk14 dependency through B? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven without an intyernet connection
What's the easiest way to download the whole central repository? Is there a maven plugin to do that? Or is there some way to get a zip of the whole thing? On Mon, 2007-03-19 at 14:26 +, Andrew Williams wrote: If you can run maven on an internet connected computer first to download all the dependencies then you could just copy the ~/.m2/ repository/ directory to the computer without the internet and run maven in offline mode (mvn -o) Andy On 19 Mar 2007, at 07:17, Ivan Biddles wrote: Hi, I am integrating several open source projects into an application and some of these projects are built with Maven, which I have not used to date. I have read the FAQs etc. but I could not find a mention of being able to do a Maven build on a machine that is not directly connected to the Internet or whether such a connection is a prerequisite. My situation is that my development machine is not connected but I do need to be able to build some of these projects. Is there some way that Maven supports this disconnected build? Thanks. Best wishes, Ivan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multimodule assembly plugin question
I have a project with multiple modules, and I would like to assemble the classes of the modules into a single jar file. If the names of the modules (and directories) match the artifact ID, the assembly works fine. But if the artifactId does not match the module name, then the files are not picked up. Is there a way to configure this to work with the different names? Or do I need to just rename my modules or artifacts so that they match? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inter module dependencies with release plugin
I have a multi-module project where some modules depend on others. parent |--module1 |--module2 `--module3 And module 2 depends on the current snapshot version of module 1. I would like to release them all at the same time, but the problem is that the release plugin tells me that module 2 is dependent on a snapshot version of module 1 so it cannot run. How can I get around this issue? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Username and password for deploy plugin
Thanks. Yes that issue is similar to what I'm asking for. I linked my issue to that one, and voted for it. I also found this issue which is the same as what I was asking for: http://jira.codehaus.org/browse/WAGON-52 On Sat, 2007-03-03 at 16:50 +0530, Gregory Kick wrote: I think that you might be talking about what was reported in http://jira.codehaus.org/browse/MNG-553 . This issue was reported a long time ago and doesn't seem to be getting much attention anymore... Maybe a few more votes for it? On 3/3/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/28/07, Paul Gier [EMAIL PROTECTED] wrote: Is there a way to supply a username and password for a remote repository on the command line instead of in the settings.xml? It would be helpful if the deploy plugin could prompt the user as needed for this information. The password could be hidden from view this way, and developers would not have to worry about configuring settings.xml. Specifically, I would like to have this feature for the wagon-webdav plugin, but I think it could apply to all the deploy related plugins. No idea if it takes userid/password on the command line, but there is some work in the gpg plugin to prompt for a passphrase (and mask it). Perhaps that could be borrowed. (wagon-webdav isn't a plugin, is it? I only know it as an artifact that needs to be configured as a build extension or otherwise added to Maven since it doesn't support dav by default.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing the release plugin
When I use the dryRun option, it seems to work fine. But then if I try to use the standard release:prepare after a dry run, maven tells me that the prepare step is finished and does not tag my release. Is this a bug? If I set resume to false then the prepare step starts over and everything works ok. The problem that I'm having now, is that the default scm url for my tag is not what I want, and I would like to be able to change it manually after the using dry run option. On Fri, 2007-03-02 at 15:52 +0100, Thorsten Heit wrote: Hi Christophe, I need to use the release plugin but I want to test it before really use it for release. How can I do to NOT modify my svn trunk files. Is it better to work on a branch? mvn release:prepare -DdryRun=true Is that what you're looking for? (see http://maven.apache.org/plugins/maven-release-plugin/usage.html) HTH Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing the release plugin
Some additional info, I'm using an svn repository, and maven 2.0.5 Thanks! On Mon, 2007-03-05 at 15:01 -0600, Paul Gier wrote: When I use the dryRun option, it seems to work fine. But then if I try to use the standard release:prepare after a dry run, maven tells me that the prepare step is finished and does not tag my release. Is this a bug? If I set resume to false then the prepare step starts over and everything works ok. The problem that I'm having now, is that the default scm url for my tag is not what I want, and I would like to be able to change it manually after the using dry run option. On Fri, 2007-03-02 at 15:52 +0100, Thorsten Heit wrote: Hi Christophe, I need to use the release plugin but I want to test it before really use it for release. How can I do to NOT modify my svn trunk files. Is it better to work on a branch? mvn release:prepare -DdryRun=true Is that what you're looking for? (see http://maven.apache.org/plugins/maven-release-plugin/usage.html) HTH Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Username and password for deploy plugin
Is there a way to supply a username and password for a remote repository on the command line instead of in the settings.xml? It would be helpful if the deploy plugin could prompt the user as needed for this information. The password could be hidden from view this way, and developers would not have to worry about configuring settings.xml. Specifically, I would like to have this feature for the wagon-webdav plugin, but I think it could apply to all the deploy related plugins. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Get the scm settings from plugin
I would like to be able to access the scm settings (connection, tag, etc) in the pom.xml from within a plugin. Is this possible? It seems like there should be an easy way to get access to all of the pom configuration from within a plugin, but I haven't found it yet. I tried looking in project.properties, but it was empty. Is project.properties used for anything? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Get the scm settings from plugin
Thanks, it works!
Does that work for the other objects in the model?
For example if I also want to get the license information can I use
${project.license} to get a License object from model?
Is that functionality documented anywhere?
David Jackman wrote:
It seems project.properties will always be empty (I've been working on
that issue in the Mojo accessing project properties thread in this
forum).
However, what you want isn't in the properties anyway. What you want is
the project.scm value. Declare your plugin field like this:
/**
* Source control information.
* @parameter expression=${project.scm}
* @required
* @readonly
*/
private org.apache.maven.model.Scm scm;
You'll need to add maven-model as a dependency to your plugin as well:
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-model/artifactId
version2.0.4/version
/dependency
That should be enough to get the scm information in your plugin.
..David..
-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 9:01 AM
To: users@maven.apache.org
Subject: Get the scm settings from plugin
I would like to be able to access the scm settings (connection, tag,
etc) in the pom.xml from within a plugin. Is this possible? It seems
like there should be an easy way to get access to all of the pom
configuration from within a plugin, but I haven't found it yet. I tried
looking in project.properties, but it was empty. Is project.properties
used for anything?
Thanks!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
