[ANN] Maven Compiler Plugin 3.2 Released
The Maven team is pleased to announce the release of the Apache Maven Compiler Plugin, version 3.2 The Compiler Plugin is used to compile the sources of your project. http://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.2/version /plugin Release Notes - Apache Maven Compiler Plugin - Version 3.2 Task * [MCOMPILER-232] Fix RAT Report * [MCOMPILER-224] Maven compiler plugin does not properly consume plexus compiler output * [MCOMPILER-220] Fix o.a.m.p.c.CompilerMojoTestCase.testCompilerFork(), which fails when javac is not on the PATH * [MCOMPILER-159] generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements() * [MCOMPILER-157] Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files 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 Compiler Plugin 3.2 Released
The Maven team is pleased to announce the release of the Apache Maven Compiler Plugin, version 3.2 The Compiler Plugin is used to compile the sources of your project. http://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.2/version /plugin Release Notes - Apache Maven Compiler Plugin - Version 3.2 Task * [MCOMPILER-232] Fix RAT Report * [MCOMPILER-224] Maven compiler plugin does not properly consume plexus compiler output * [MCOMPILER-220] Fix o.a.m.p.c.CompilerMojoTestCase.testCompilerFork(), which fails when javac is not on the PATH * [MCOMPILER-159] generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements() * [MCOMPILER-157] Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While +there is a danger he To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Cheers, Paul -- Sent from my phone -- John Casey GitHub - http://github.com/jdcasey - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Dependency Analyzer 1.4 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Analyzer, version 1.4 As the name implies, the Maven dependency analyzer analyzes the dependencies of a project for undeclared or unused artifacts. http://maven.apache.org/shared/maven-dependency-analyzer/ Release Notes - Maven Shared Components - Version maven-dependency-analyzer-1.4 ** Bug * [MSHARED-276] - analyzer ignores project directories in a multi-module build Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Dependency Plugin 2.7 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.7 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. http://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.7/version /plugin Release Notes - Maven 2.x Dependency Plugin - Version 2.7 ** Bug * [MDEP-391] - Unpack fails on linux with large archives * [MDEP-399] - Multi-module dependencies incorrectly marked as unused * [MDEP-401] - Support include/exclude of artifactId/groupId in resolve-plugins * [MDEP-402] - Allow resolve-plugins to exclude plugins in the current reactor ** Improvement * [MDEP-301] - Allow build-classpath to output to property * [MDEP-396] - Add support to use the baseVersion of an artifact instead of version for the destFileName * [MDEP-403] - add a skip configuration option to the dependency plugin Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Javadoc Plugin 2.8.1 Released
The Maven team is pleased to announce the release of the Maven Javadoc Plugin,
version 2.8.1
The Maven Javadoc Plugin is a plugin that uses the javadoc tool for
generating javadocs for the specified project.
http://maven.apache.org/plugins/maven-javadoc-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.8.1/version
/plugin
Release Notes - Maven Javadoc Plugin - Version 2.8.1
Bug
* [MJAVADOC-336] Reports contain temporary files due to usage of
'File.deleteOnExit'.
* [MJAVADOC-326] docletPath configuration parameter is concatenated incorrectly
* [MJAVADOC-325] Incorrect -link is generated when its URL contains a comma
* [MJAVADOC-320] includeDependencySources does not handle external dependencies
and filters for reactor dependencies correctly
Improvement
* [MJAVADOC-321] Add dutch resource bundles
New Feature
* [MJAVADOC-322] Capabilty to add additionnal dependencies when running javadoc
* [MJAVADOC-250] javadoc:fix mojo should fully qualify {@link} class names
Task
* [MJAVADOC-327] add Java 7 to known javadoc API urls
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-eclipse-plugin: pde support and OSGiManifest writer
+1 Having fewer partial implementations to confuse folks is always better IMO. On 9/27/11 2:08 AM, Carlos Sanchez wrote: I guess there wouldn't be any issue removing it adding a warning pointing to the Felix plugin. Osgi manifests are better handled there. On Fri, Sep 23, 2011 at 8:01 AM, Barrie Treloarbaerr...@gmail.com wrote: Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Try turning that extension into a dependency embedded in the maven-deploy-plugin configuration, IIRC: build plugins plugin artifactIdmaven-deploy-plugin/artifactId version2.5/version dependencies dependency groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh/artifactId version1.0-beta-7/version /dependency /dependencies /plugin /plugins /build On 4/5/11 1:16 PM, Tim Pizey wrote: Hi, I have tried to update my project to use maven3 (version 3.0.2), however I can no longer deploy artifacts to my repository. I have found a number of notes about how to do this: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Gives Transport Protocols (Wagons) Unlike Maven 2, Maven 3 supports out of the box only http:, https: and file: as transport protocols. Why? Surely scp is both a central use case and existing functionality. To use other transport protocols like scp:, the appropriate wagons have to be explicitly declared in the POM as a build extension. If the wagon in question is only used for deployment, it can alternatively be declared as a dependency of the Maven Deploy Plugin. For more information, see Guide to Using Extensions. I have everything set up as per http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html I have followed the recommeds in http://maven.40175.n5.nabble.com/Wagon-in-3-0-No-connector-td3256506.html and followed exactly http://johnsjavapda.blogspot.com/2010/11/maven-wagon.html As so often with these things I am upgrading Maven at the same time as using a new install on Window7, I have checked that I can scp to the repository. I have added the wagon jar to the MAVEN_HOME/lib directory I am using cgywin on windows7, the actual error is: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 29.056s [INFO] Finished at: Tue Apr 05 17:56:51 BST 2011 [INFO] Final Memory: 21M/534M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5: deploy (default-deploy) on project melati-parent: Failed to deploy artifacts/met adata: No connector available to access repository melati_to (scp://melati.org/d ata/www/maven2/) of type default using the available factories WagonRepositoryCo nnectorFactory - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on proje ct melati-parent: Failed to deploy artifacts/metadata: No connector available to access repository melati_to (scp://melati.org/data/www/maven2/) of type default using the available factories WagonRepositoryConnectorFactory at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) thanks in advance Tim -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Classifier now required by assembly plugin
Just to be clear, it's been a long-standing bug that the assembly id was
NOT required. It's always been the intention to require that element.
That's why we provided the appendAssemblyId/ configuration element, to
give the user control over whether that id is used to form the
coordinate for the resulting artifact.
This snippet from AbstractAssemblyMojo.java seems to indicate the flag
is used correctly. If not, then THAT's the bug, IMO.
http://pastebin.com/YqEju8EM
if ( attach destFile.isFile() )
{
if ( isAssemblyIdAppended() )
{
projectHelper.attachArtifact( project,
format, assembly.getId(), destFile );
}
else if ( classifier != null )
{
projectHelper.attachArtifact( project,
format, classifier, destFile );
}
else if ( !pom.equals( type )
format.equals( type ) )
{
if ( !warnedAboutMainProjectArtifact )
{
final StringBuffer message = new
StringBuffer();
message.append( Configuration options:
'appendAssemblyId' is set to false, and 'classifier' is missing. );
message.append( \nInstead of attaching
the assembly file: )
.append( destFile )
.append( , it will become the
file for main project artifact. );
message.append( \nNOTE: If multiple
descriptors or descriptor-formats are provided for this project, the
value of this file will be non-deterministic! );
getLog().warn( message );
warnedAboutMainProjectArtifact = true;
}
final File existingFile = project.getArtifact()
.getFile();
if ( ( existingFile != null )
existingFile.exists() )
{
getLog().warn( Replacing pre-existing
project main-artifact file: + existingFile
+
\nwith assembly file: + destFile );
}
project.getArtifact()
.setFile( destFile );
}
else
{
projectHelper.attachArtifact( project,
format, null, destFile );
}
On 10/25/10 1:07 PM, Haszlakiewicz, Eric wrote:
-Original Message-
From: Wendy Smoak [mailto:wsm...@gmail.com]
On Thu, Oct 21, 2010 at 1:40 PM, Phillip Hellewellssh...@gmail.com
wrote:
I just found out the hard way that the latest version of the assembly
plugin requires anid tag in the descriptor file, which is used as
the classifier appended to the zip.
I don't want to specify an id here because then means I have to
specify a classifier in the dependency section of my other poms.
Have you tried setting appendAssemblyId to false?
No, that doesn't help, but thanks for the suggestion.
In my opinion, and probably according to what most people would think is
reasonable for *minimal* release between a beta version and a final
version, a huge behaviour change like this shouldn't happen.
I was finally able to test this with the 2.2 release version, and it
fails for me too, so I created a issue in Jira: MASSEMBLY-517.
eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Assembly Plugin 2.2 Released
The Maven team is pleased to announce the release of the Maven Assembly
Plugin, version 2.2
This plugin allows the user to create customized archives based on their
project and its dependencies. For example, the assembly plugin is
commonly used to create distribution archives for projects.
http://maven.apache.org/plugins/maven-assembly-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2/version
/plugin
NOTE: Release Notes are also available at:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126version=12617
Release Notes - Maven 2.x Assembly Plugin - Version 2.2
** Bug
* [MASSEMBLY-94] - moduleSet/binaries doesn't work with
assembly:single bound to the build lifecycle
* [MASSEMBLY-140] - Assembly descriptor docs are incorrect for
dependencySets/dependencySet/excludes
* [MASSEMBLY-150] - Clarify or fix file relative scoping in
assembly descriptor to be module centric or location of mvn execution
* [MASSEMBLY-151] - Documentation for the assembly plugin is
utterly confusing
* [MASSEMBLY-157] - maven assembly plugin, includes/excludes in
moduleSet
* [MASSEMBLY-167] - Property Expansion/Filtering does not always
work for System.properties
* [MASSEMBLY-171] - Fix / speedup integration tests
* [MASSEMBLY-185] - When using different parent and aggregator
poms, the assembly plugin does not package the ModuleSets of the
aggregator modules
* [MASSEMBLY-187] - Incorrect FileSet causes infinite loop
* [MASSEMBLY-202] - Silent failure: outputFileNameMapping
declared with multiple includes
* [MASSEMBLY-206] - Filtering does not work when using in fileSet
inside moduleSet
* [MASSEMBLY-220] - unpacked assemblies render different results
when enumerating dependencies vs. using wildcards
* [MASSEMBLY-228] - UnpackOptions filtered does not work
* [MASSEMBLY-248] - version was null for junit:junit
* [MASSEMBLY-289] - Fix bogus warning about attaching non-regular file
* [MASSEMBLY-299] - assembly does not honnor dependencyManagement
directives
* [MASSEMBLY-332] - MANIFEST.MF is not used when specified in
configuration for a WAR format assembly
* [MASSEMBLY-333] - plugin not correctly interpolating POM
variables like ${settings.localRepository}
* [MASSEMBLY-337] - dependencySet with unpack=true cannot be used
to make file permissions executable
* [MASSEMBLY-346] - DependencySets Includes/Excludes Do Not Work
Correctly And Type Is Ignored
* [MASSEMBLY-360] - When using mulitple Spring dependencies, the
files from META-INF (from the Spring jars) overwrite each other in an
executable jar-with-dependencies.
* [MASSEMBLY-367] - mvn assembly:assembly fails to replace
${parent.parent.version}
* [MASSEMBLY-378] - Property expansion in assembly/component
descriptors does not escape , , , , or '
* [MASSEMBLY-392] - Big slowdown on Linux when upgrading assembly
plugin from 2.2-beta-1 to 2.2-beta-3
* [MASSEMBLY-393] - Cannot Override dependencyManagement
* [MASSEMBLY-403] - No files is added for fileset
* [MASSEMBLY-420] - maven fails when packing parent pom
* [MASSEMBLY-423] - Specified file modes are used for all the
following fileSets
* [MASSEMBLY-424] - poor performance of dependencySet in assembly
descriptor (compared to using maven-dependency-plugin + fileSet)
* [MASSEMBLY-431] - missing files during installing when using goal
assembly
* [MASSEMBLY-432] - assembly misapplies depMgt and selects the
wrong dependency for an archive
* [MASSEMBLY-435] - DependencySet: outputDirectory expression using
${artifact.baseVersion} uses equivalent of ${project.baseVersion}
* [MASSEMBLY-448] - Assembly plugin's dependency resolution for
dependency sets is not inline with maven dependency resolution
* [MASSEMBLY-451] - unpackOptions: Documentation on
maven.apache.org differs from The definitive Guide, the latter is right
* [MASSEMBLY-455] - Incorrect documentation for Pre-defined
Descriptor Files
* [MASSEMBLY-462] - Assembly contains temporary files ending in
*.formatted.
* [MASSEMBLY-464] - assembly descriptor id should be mandatory
* [MASSEMBLY-469] - Version for artifacts in dependencies section
are resolved wrong
* [MASSEMBLY-488] - restrict useStrictFiltering option to
DependencySets
* [MASSEMBLY-490] - Assembly fails with 'Too many files' error when
converting line endings.
* [MASSEMBLY-498] - Unable to get module properties
* [MASSEMBLY-499] - Poor performance in DirectoryArchiver due to
unnecessary native calls
* [MASSEMBLY-507] - 2.2-beta-6-SNAPSHOT component annotations MAY
not work with Maven 2.x
* [MASSEMBLY-509] - Hudson unable to build with version 2.2
** Improvement
* [MASSEMBLY-66] - Ability to index into a nominated dependency JAR
to identify files to
[ANN] Maven Common Artifact Filters 1.3 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters, version 1.3 This shared library provides a set of implementations for the org.apache.maven.artifact.resolver.filter.ArtifactFilter interface, found in maven-artifact. Most notable are the implementations allowing the use of wildcard patterns for including and excluding artifacts. http://maven.apache.org/shared/maven-common-artifact-filters-1.3 To use this library, specify the following dependency in your pom.xml: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.3/version /dependency Release Notes - Maven Common Artifact Filters - Version 1.3 ** Bug * [MSHARED-162] - actTransitively wildcard patterns can fail on pattern-based filters 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 Common Artifact Filters 1.3 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters, version 1.3 This shared library provides a set of implementations for the org.apache.maven.artifact.resolver.filter.ArtifactFilter interface, found in maven-artifact. Most notable are the implementations allowing the use of wildcard patterns for including and excluding artifacts. http://maven.apache.org/shared/maven-common-artifact-filters-1.3 To use this library, specify the following dependency in your pom.xml: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.3/version /dependency Release Notes - Maven Common Artifact Filters - Version 1.3 ** Bug * [MSHARED-162] - actTransitively wildcard patterns can fail on pattern-based filters Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Javadoc Plugin version 2.7 Released
The Maven team is pleased to announce the release of the Maven Javadoc Plugin, version 2.7 This plugin uses the Javadoc tool to generate javadocs for your project. http://maven.apache.org/plugins/maven-javadoc-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.7/version /plugin Release Notes - Maven 2.x Javadoc Plugin - Version 2.7 ** Bug * [MJAVADOC-273] - NullPointerException when setting detectLinks to true * [MJAVADOC-275] - Creation of Javadoc attachments fails in multi-module project where modules have never been installed/deployed * [MJAVADOC-276] - Initial builds of a multi-module project fail ** Improvement * [MJAVADOC-271] - Improve robustness regarding sporadic connection timeouts ** New Feature * [MJAVADOC-277] - Add Swedish translation * [MJAVADOC-280] - Allow creation of aggregated javadocs source bundles from project dependencies ** Task * [MJAVADOC-282] - Switch to JDK 1.5 binaries 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 Resources Plugin 2.4.1 Released
The Maven team is pleased to announce the release of the Maven Resources
Plugin, version 2.4.1
This plugin filters non-Java resource files, replacing expressions with
values from the POM or any of the filtering properties files you choose
to configure.
http://maven.apache.org/plugins/maven-resources-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.1/version
/plugin
Release Notes - Maven 2.x Resources Plugin - Version 2.4.1
** Bug
* [MRESOURCES-105] - Custom Delimiters does not work as expected -
NPE with ${*} and comments in property file does break replacement
* [MRESOURCES-106] - Plugin does not respect escapeWindowsPaths
default-value
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 Repository Plugin 2.3 Released
The Maven team is pleased to announce the release of the Maven Repository Plugin, version 2.3 This plugin assists the user in creating archived bundles that are designed to meet all requirements for upload to the central Maven repository. http://maven.apache.org/plugins/maven-repository-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-repository-plugin/artifactId version2.3/version /plugin Release Notes - Maven 2.x Repository Plugin - Version 2.3 ** Improvement * [MREPOSITORY-19] - Require SCM information to help tooling for project materialization from the repository 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 Verifier 1.2 Released
The Maven team is pleased to announce the release of the Maven Verifier, version 1.2 This is a shared library for use in testing various Maven components. It allows the user to execute Maven builds as part of the testing process, with methods supporting test preparation and assertion of results. http://maven.apache.org/shared/maven-verifier/ To use the verifier, add the following to your POM's dependencies section: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-verifier/artifactId version1.2/version scopetest/scope /dependency Release Notes - Maven Shared Components - Version maven-verifier 1.2 ** Bug * [MSHARED-73] - Verifier doesn't throw VerificationException upon non-zero exit code of mvn.bat on Windows * [MSHARED-76] - Verifier executeGoal method is OS-dependent in case of failure ** Improvement * [MSHARED-72] - Use current local repo for forked Maven invocations by default ** New Feature * [MSHARED-75] - Add convenience method to clean (target) directory 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 Artifact Resolver (Shared Library) 1.0 Released
The Maven team is pleased to announce the release of the Maven Artifact Resolver, version 1.0 This is a shared library that aims to simplify as much as possible the task of resolving dependency artifacts for one or more projects (MavenProject instances) all at once. http://maven.apache.org/shared/maven-artifact-resolver/ To use the resolver library, add the following to your POM's dependencies section: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-artifact-resolver/artifactId version1.0/version /dependency Release Notes - Maven Shared Components - Version maven-artifact-resolver-1.0 ** Improvement * [MSHARED-127] - Consider all projects in the reactor AND projects in the specified collection when dealing with MultipleArtifactsNotFoundException ** New Feature * [MSHARED-126] - Create shared api to resolve project 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 Remote Resources Plugin 1.1 Released
The Maven team is pleased to announce the release of the Maven Remote
Resources Plugin, version 1.1
This plugin uses configurable sets of template files stored in the Maven
repository, combined with project and dependency POM information, to
generate files such as DEPENDENCIES or LICENSE statements that are
specific to your project.
http://maven.apache.org/plugins/maven-remote-resources-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-remote-resources-plugin/artifactId
version1.1/version
/plugin
Release Notes - Maven 2.x Remote Resources Plugin - Version 1.1
** Bug
* [MRRESOURCES-11] - Resource filtering for overridden resources
* [MRRESOURCES-35] - ClassCastException
* [MRRESOURCES-37] - embedded error with
maven-remote-resources-plugin; maven build order?
* [MRRESOURCES-38] - Remove inadvertent dependency on
MavenReportException in maven-reporting-api
* [MRRESOURCES-39] - Unnecessary fondness for inceptionDate
** Improvement
* [MRRESOURCES-31] - Add an alternative apache-jar-resource-bundle
** New Feature
* [MRRESOURCES-36] - ${project.build.sourceEncoding} not honoured.
* [MRRESOURCES-41] - add support for multi-module dependencies
listing and other top-of-tree calculations on sub-modules
* [MRRESOURCES-43] - Add ability to specify artifacts to search for
supplementalModels
** Task
* [MRRESOURCES-42] - Incorporate fix for PLXCOMP-145: problem with
JarResourceLoader.initialize() never being called
* [MRRESOURCES-44] - Document usage of runOnlyAtExecutionRoot and
supplemental model features.
* [MRRESOURCES-45] - Stage releases for dependencies that have changed
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 Filtering 1.0-beta-3 Released
The Maven team is pleased to announce the release of Maven Filtering, version 1.0-beta-3. Maven Filtering is an API that allows plugin developers to filter text-based resources using values supplied by a MavenProject instance, a MavenSession instance, and an arbitrary set of properties files. Filtering based on MavenProject values aims to replicate support for POM-interpolation expressions, while filtering based on the MavenSession aims to support filtering of system properties and command-line properties used to execute Maven. http://maven.apache.org/shared/maven-filtering/ To use this API, you should add the following dependency to your project: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-filtering/artifactId version1.0-beta-3/version /dependency Release Notes - Maven Shared Components - Version maven-filtering-1.0-beta-4 ** Bug * [MSHARED-121] - FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter. ** Improvement * [MSHARED-78] - FilteringUtils escapeWindowsPath() doesn't work on Windows Enjoy, The Maven Team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Resoures Plugin 2.4 Released
The Maven team is pleased to announce the release of the Maven Resources
Plugin, version 2.4.
The Resources Plugin provides support for copying and filtering files in
the standard resource locations in a Maven build (configured using the
project/build/resources and project/build/testResources sections in the
POM).
It also provides similar support for additional, ad-hoc resource
definitions using the copy-resoures mojo.
http://maven.apache.org/plugins/maven-resources-plugin/
You should specify this version in your project's plugin configuration:
plugin
artifactIdmaven-resources-plugin/artifactId
version2.4/version
/plugin
Release Notes - Maven 2.x Resources Plugin - Version 2.4
** Bug
* [MRESOURCES-44] - ${settings.localRepository} is not expanded by
resource filtering
* [MRESOURCES-48] - Failed to copy full contents from
* [MRESOURCES-77] - Filters for copy-resources goal in plugin
configuration section are ignored
* [MRESOURCES-78] - change in @ translation behavior in
maven-resources-plugin 2.3
* [MRESOURCES-79] - resources are filtered by test filters
* [MRESOURCES-81] - 2.3 escapes characters when filtering properties
** New Feature
* [MRESOURCES-60] - delimiter configuration
Enjoy,
The Maven team
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Source-Release Assembly Descriptor 1.0 Released
It appears that the site/repository synchronization is moving slowly, so please be patient and these artifacts and site updates should be showing up before long. I want to make sure I get this announcement out before I forget it, though. --- The Maven team is pleased to announce the release of Apache Source-Release Assembly Descriptor, version 1.0. This is a standardized assembly descriptor for use in the maven-assembly-plugin. Source-release artifacts are archives which contain the full project structure (sources only, no build output) that are the subject of an ASF release vote. http://maven.apache.org/apache-resource-bundles/apache-source-release-assembly-descriptor/ This assembly descriptor should be coming to a parent POM near you, and should eventually be an automatic part of every ASF release. For now, it has been configured into the release process for Maven projects that inherit from maven-parent version 13 (also recently released). If you want to try out the source-release descriptor in the meantime, you can include a configuration like the following: build plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4/version dependencies dependency groupIdorg.apache.apache.resources/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0/version /dependency /dependencies executions execution idsource-release/id phasepackage/phase goals goalsingle/goal /goals configuration descriptorRefs descriptorRefsource-release/descriptorRef /descriptorRefs tarLongFileModegnu/tarLongFileMode runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot /configuration /execution /executions /plugin /plugins /build Enjoy, The Maven Team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Repository Plugin 2.2 Released
The Maven team is pleased to announce the release of the Maven Repository Plugin, version 2.2 This plugin simplifies the task of creating upload bundles for adding artifacts to Maven's central repository. http://maven.apache.org/plugins/maven-repository-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-repository-plugin/artifactId version2.2/version /plugin Release Notes - Maven 2.x Repository Plugin - Version 2.2 ** Improvement * [MREPOSITORY-18] - Repository bundles don't include .asc files or attached artifacts other than sources and javadocs ** New Feature * [MREPOSITORY-3] - Please add support for multi-module projects in repository:bundle-create mojo 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 Repository Plugin 2.2 Released
Re-sending, I used the wrong from address... --- The Maven team is pleased to announce the release of the Maven Repository Plugin, version 2.2 This plugin simplifies the task of creating upload bundles for adding artifacts to Maven's central repository. http://maven.apache.org/plugins/maven-repository-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-repository-plugin/artifactId version2.2/version /plugin Release Notes - Maven 2.x Repository Plugin - Version 2.2 ** Improvement * [MREPOSITORY-18] - Repository bundles don't include .asc files or attached artifacts other than sources and javadocs ** New Feature * [MREPOSITORY-3] - Please add support for multi-module projects in repository:bundle-create mojo Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven 2.2.1 Released
The Maven team is pleased to announce the release of Apache Maven, version 2.2.1 Maven is a project comprehension and build tool, designed to simplify the process of maintaining a healthy development lifecycle for your project. You can read more here: http://maven.apache.org/ Downloads are available here: http://maven.apache.org/download.html Release notes are available at (they are also included below): http://maven.apache.org/release-notes.html --- Release Notes - Maven 2 - Version 2.2.1 ** Bug * [MNG-3265] - maven-model Extension.equals causes NPE when any field is uninitialized * [MNG-3506] - Custom ArtifactHandler not resolved for project when an additional plugin with extensions is defined in parent pom * [MNG-3753] - ArtifactResolverDiagnoser.diagnose() fails with NPE if nested IOException has no detail message * [MNG-4189] - Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository * [MNG-4218] - NPE in AbstractArtifactResolutionException if DefaultArtifactResolver.resolveTransitively is interrupted * [MNG-4228] - [regression] Authorization failed: Not authorized by proxy. * [MNG-4235] - [regression] Maven 2.2.0 produces invalid checksums during deployment to secured HTTP repo * [MNG-4236] - [regression] http wagon uploads files twice with Maven 2.2.0 when preemptive auth is disabled (default setting) * [MNG-4238] - Custom ArtifactHandler provided by build extension isn't used for project artifact * [MNG-4240] - Direct dependencies with scope == provided will not have their transitive dependencies resolved for compiling and testing * [MNG-4270] - ArtifactHandler, LifecycleMapping from plugin dependency is not used when plugin extensions are enabled * [MNG-4275] - [regression] Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689 ** Improvement * [MNG-4254] - Support selection of wagon implementation for a particular protocol * [MNG-4279] - wagon provider selection should fail gracefully and use protocol for roleHint if protocol-provider roleHint isn't available. ** Task * [MNG-4290] - Update guide-http-settings to reflect the fact that sun-based http has been restored as the default for the http/s wagons. Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.1-RC2
I've updated the mavenVersion property on the 2.2.x branch. -john Brett Randall wrote: On Wed, Aug 5, 2009 at 12:21 PM, Brian Fox bri...@infinity.nu wrote: That's an ld bug in the release plugin. It bumps the property to the being released version but doesn't bump it to the next dev version. On Tue, Aug 4, 2009 at 8:41 PM, Brett Randalljavabr...@gmail.com wrote: On Tue, Aug 4, 2009 at 9:49 AM, John Casey jdca...@commonjava.org wrote: Hi again, After Brett sorted out some issues that got lost in the source-control mess on my localhost, and I resolved a couple more stragglers that came up as a result of testing out RC1, I think we're in better shape to attempt a release again. Before we do, I'd like to get as many eyes as possible on this latest release candidate: https://repository.apache.org/content/repositories/maven-staging-008/org/apache/maven/apache-maven/2.2.1-RC2 Please file JIRA issues for anything you come across that still seems broken. The list of issues we've resolved so far for this release is here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=15328 Thanks! -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Hi John, in the post 2.2.1-RC2 [maven-release-plugin] prepare for next development iteration, @800602, it looks like the maven-release-plugin has not bumped properties mavenVersion2.2.1-RC2/mavenVersion ... to RC3-SNAPSHOT. Is this a deploy-regression, or am I missing something? This leaves me unable to build 2.2.1-RC3-SNAPSHOT from a clean repo using Maven 2.2.0, due to missing reactor deps on 2.2.1-RC2 https://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x/pom.xml?r1=800600r2=800602diff_format=h https://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x/pom.xml?revision=800602content-type=text%2Fplain Cheers Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks Brian - I'll bug the current state of the 2.2.x branch then, and see if I can find the release plugin bug you refer to and whether it has regressed or is still open. Cheers BRett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[PLEASE TEST] Maven 2.2.1-RC2
Hi again, After Brett sorted out some issues that got lost in the source-control mess on my localhost, and I resolved a couple more stragglers that came up as a result of testing out RC1, I think we're in better shape to attempt a release again. Before we do, I'd like to get as many eyes as possible on this latest release candidate: https://repository.apache.org/content/repositories/maven-staging-008/org/apache/maven/apache-maven/2.2.1-RC2 Please file JIRA issues for anything you come across that still seems broken. The list of issues we've resolved so far for this release is here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=15328 Thanks! -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.1-RC1
Hi, thanks for testing! It looks like we may have some issues to sort out still with proxies and the new wagon-selector feature...after all, this is still just the first release candidate, and the first time some critical user/testers with behind proxies are looking at the new code. So, we're probably going to have at least one more of these RCs before the final vote goes out (actually one more is pretty optimistic, if recent history is any indicator). We're moving that direction as fast as we can, but we need to allow enough soak time to get as many eyes on this as we can. Cheers, -john j_ri wrote: Hi, I tried to update our Maven installation to the newest version (2.2.0), but got problems while trying to generate the site report with mvn site (see stacktrace below). I didn't find this issue in the issue list, but just tried your mentioned 2.2.1-RC1 version.and it works again;-) When will 2.2.1 final be released? Thanks, Jochen [INFO] Generating Dependency Management report. Downloading: http://localhost/archiva/repository/all_mirrors_of_external/lbank/flatfile/flatfile-connector/[1.1,1.2)/flatfile-connector-[1.1,1.2).pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Invalid uri 'http://localhost/archiva/repository/all_mirrors_of_external/lbank/flatfile/flatfile-connector/[1.1,1.2)/flatfile-connector-[1.1,1.2).pom': escaped absolute path not valid [INFO] [INFO] Trace java.lang.IllegalArgumentException: Invalid uri 'http://localhost/archiva/repository/all_mirrors_of_external/lbank/flatfile/flatfile-connector/[1.1,1.2)/flatfile-connector-[1.1,1.2).pom': escaped absolute path not valid at hidden.org.apache.commons.httpclient.HttpMethodBase.init(HttpMethodBase.java:222) at hidden.org.apache.commons.httpclient.methods.GetMethod.init(GetMethod.java:89) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:547) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:491) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:372) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:327) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:264) at org.apache.maven.report.projectinfo.ProjectInfoReportUtils.getArtifactUrl(ProjectInfoReportUtils.java:171) at org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:209) at org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:197) at org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:144) at org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:137) at org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:123) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:101) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:303) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at
[PLEASE TEST] Maven 2.2.1-RC1
Hi everyone, It looks like we've got some pretty major regressions with Maven 2.2.0, as I'm sure you've noticed. Please give this version a try at: http://bit.ly/4swtGu (https://repository.apache.org/content/repositories/maven-staging-025/org/apache/maven/apache-maven/2.2.1-RC1/) --- I think we have the worst of these problems (the regressions from 2.2.0, and all the problems with the httpclient-based wagons) fixed, or at least contained. Basically, the changes for 2.2.1 will restore the lightweight-http wagons as default, but will introduce a new feature that allows selection of a wagon provider for any given protocol. You can do this with the cli options: mvn -Dmaven.wagon.provider.http=httpclient ... Or, you can use the server entry in the settings.xml: server idfoo/id configuration wagonProviderhttpclient/wagonProvider ... /configuration /server In both of the above configurations, Maven will look for a component with: Role: org.apache.maven.wagon.Wagon Role-Hint: http-httpclient We have redefined the httpclient and lightweight http wagon components using new role-hints: - http-httpclient - https-httpclient - http-lightweight - https-lightweight New wagons can be brought in via extensions and used in this same manner. In all, we've solved 11 issues for this release (so far): http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=15328 As always, please file JIRA issues for anything that comes up broken, at: http://jira.codehaus.org/browse/MNG ...and please, please report the issue numbers in this thread, so we can keep track of what's going on. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Failed to validate an ostensibly valid pom
If you run with -X, it may give you more information about why it's invalid.
Just a thought.
-john
daniel.green wrote:
dgr...@dgreen-desktop:~/redacted_renovation/workspace/dto$ mvn compileb
[WARNING] POM for 'com.redacted:utility:pom:1.0:compile' is invalid. It will
be ignored for artifact resolution. Reason: Failed to validate POM for
project com.redacted:utility at Artifact
[com.redacted:utility:pom:1.0:compile]
Downloading:
http://10.1.102.139:8081/artifactory/repo/org/apache/maven/doxia/doxia-converter/1.1-SNAPSHOT/doxia-converter-1.1-SNAPSHOT.pom
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Fri Jun 26 19:52:22 EDT 2009
[INFO] Final Memory: 8M/16M
[INFO] ---
Notice the warning regarding com.redacted:utility:pom:1.0. However I can
compile com.redacted:utility without any complaints. I can also do a compile
of the parent pom.
dto/pom.xml:
?xml version=1.0 encoding=UTF-8?
project
parent
groupIdcom.redacted/groupId
artifactIdmaven/artifactId
version1.0/version
relativePath../maven/pom.xml/relativePath
/parent
modelVersion4.0.0/modelVersion
artifactIddto/artifactId
name${artifactId}/name
url../../${artifactId}/target/site/url
version1.0/version
descriptionDTO/description
dependencies
dependency
groupIdcom.redacted/groupId
artifactIdutility/artifactId
version1.0/version
/dependency
/dependencies
/project
And the one of utility/pom.xml
?xml version=1.0 encoding=UTF-8?
project
parent
groupIdcom.redacted/groupId
artifactIdmaven/artifactId
version1.0/version
relativePath../maven/pom.xml/relativePath
/parent
modelVersion4.0.0/modelVersion
artifactIdutility/artifactId
name${artifactId}/name
url../../${artifactId}/target/site/url
version1.0/version
descriptionUtility/description
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven 2.2.0
The Maven team is pleased to announce the release of the Maven 2.2.0. Maven is a software project management and comprehension tool. It offers users the ability to build project binaries, generate a project website, and more. http://maven.apache.org/ Release Notes - Maven 2 - Version 2.2.0 ** Sub-task * [MNG-4144] - document escape character for curly braces in clear-text passwords for settings.xml password security * [MNG-4145] - switch to released versions of plexus-sec-dispatcher (and by ext. plexus-cipher) once they're available ** Bug * [MNG-2258] - Wrong execution order of plugins in same phase * [MNG-3401] - Plugin parameters must be specified outside an execution block when they are invoked from the command line * [MNG-3553] - cannot resolve dependency with scope import * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4082] - Encryption is triggered if passwords merely contain curly braces * [MNG-4126] - [regression] Properties defined in profiles.xml of parent are not inherited during multimodule build * [MNG-4137] - NPE in DefaultLIfecycleExecutor when run from within Hudson builds * [MNG-4140] - Properties incorrectly replaced in pom * [MNG-4146] - password security doesn't work with custom password providers * [MNG-4147] - very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header * [MNG-4165] - http session cookies rejected with non-lightweight http wagon (maybe with lightweight one too) * [MNG-4166] - Problem parsing command-line options in release:perform * [MNG-4167] - version-expression transformation interferes with plugins like GPG * [MNG-4168] - String index out of range: 43807 * [MNG-4179] - [regression] Artifact download hangs upon transfer failure * [MNG-4184] - [regression] maven2.1 fails with cyclic dependency in case of extension/dependency for report-plugin to reactor-project * [MNG-4207] - Plugins that use ArtifactResolver with http repositories AND depend on log4j run into ExceptionInInitializerError * [MNG-4213] - preemptive auth in non-lightweight http wagon causes Unauthorized responses from some servers * [MNG-4219] - update plexus-utils to avoid leaking processes in CommandLineUtils.getSystemEnvars() ** Improvement * [MNG-2979] - Cross module dependencies for multi-module site * [MNG-3203] - maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration * [MNG-3834] - Improve error message when dependency with classifier is missing version * [MNG-4210] - Remove log4j configuration warning ** Task * [MNG-4143] - Update Java requirement to 1.5 * [MNG-4169] - Remove invocation of maven-plugin-plugin:updatePluginRegistry from default lifecycle bindings ** Wish * [MNG-4139] - avoid the schema location in generated maven-metadata*.xml 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 Wagon 1.0-beta-6
The Maven team is pleased to announce the release of Maven Wagon, version 1.0-beta-6. Wagon is an API for retrieving files from various types of remote sources, including support for proxies, authentication, and more. http://maven.apache.org/wagon/ Release Notes - Maven Wagon - Version 1.0-beta-6 ** Bug * [WAGON-220] - Wagon HTTP Deadlocks under high load * [WAGON-270] - preemptive auth in non-lightweight http wagon causes Unauthorized responses from some servers ** Improvement * [WAGON-264] - compressed tarball download problems * [WAGON-269] - Allow configuration of httpclient to change cookie policy, other options * [WAGON-271] - Provide configurability of httpclient parameters to allow user to tell Maven to ignore cookies 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 2.2.0 Released
The Maven team is pleased to announce the release of the Maven 2.2.0. Maven is a software project management and comprehension tool. It offers users the ability to build project binaries, generate a project website, and more. http://maven.apache.org/ Release Notes - Maven 2 - Version 2.2.0 ** Sub-task * [MNG-4144] - document escape character for curly braces in clear-text passwords for settings.xml password security * [MNG-4145] - switch to released versions of plexus-sec-dispatcher (and by ext. plexus-cipher) once they're available ** Bug * [MNG-2258] - Wrong execution order of plugins in same phase * [MNG-3401] - Plugin parameters must be specified outside an execution block when they are invoked from the command line * [MNG-3553] - cannot resolve dependency with scope import * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4082] - Encryption is triggered if passwords merely contain curly braces * [MNG-4126] - [regression] Properties defined in profiles.xml of parent are not inherited during multimodule build * [MNG-4137] - NPE in DefaultLIfecycleExecutor when run from within Hudson builds * [MNG-4140] - Properties incorrectly replaced in pom * [MNG-4146] - password security doesn't work with custom password providers * [MNG-4147] - very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header * [MNG-4165] - http session cookies rejected with non-lightweight http wagon (maybe with lightweight one too) * [MNG-4166] - Problem parsing command-line options in release:perform * [MNG-4167] - version-expression transformation interferes with plugins like GPG * [MNG-4168] - String index out of range: 43807 * [MNG-4179] - [regression] Artifact download hangs upon transfer failure * [MNG-4184] - [regression] maven2.1 fails with cyclic dependency in case of extension/dependency for report-plugin to reactor-project * [MNG-4207] - Plugins that use ArtifactResolver with http repositories AND depend on log4j run into ExceptionInInitializerError * [MNG-4213] - preemptive auth in non-lightweight http wagon causes Unauthorized responses from some servers * [MNG-4219] - update plexus-utils to avoid leaking processes in CommandLineUtils.getSystemEnvars() ** Improvement * [MNG-2979] - Cross module dependencies for multi-module site * [MNG-3203] - maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration * [MNG-3834] - Improve error message when dependency with classifier is missing version * [MNG-4210] - Remove log4j configuration warning ** Task * [MNG-4143] - Update Java requirement to 1.5 * [MNG-4169] - Remove invocation of maven-plugin-plugin:updatePluginRegistry from default lifecycle bindings ** Wish * [MNG-4139] - avoid the schema location in generated maven-metadata*.xml Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Wagon 1.0-beta-6 Released
The Maven team is pleased to announce the release of Maven Wagon, version 1.0-beta-6. Wagon is an API for retrieving files from various types of remote sources, including support for proxies, authentication, and more. http://maven.apache.org/wagon/ Release Notes - Maven Wagon - Version 1.0-beta-6 ** Bug * [WAGON-220] - Wagon HTTP Deadlocks under high load * [WAGON-270] - preemptive auth in non-lightweight http wagon causes Unauthorized responses from some servers ** Improvement * [WAGON-264] - compressed tarball download problems * [WAGON-269] - Allow configuration of httpclient to change cookie policy, other options * [WAGON-271] - Provide configurability of httpclient parameters to allow user to tell Maven to ignore cookies Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.0-RC3
As long as everyone is thinking of trying something out, you might as well try the version of Maven 2.2.0 that we're currently voting on: https://repository.apache.org/content/repositories/maven-staging-022/ This version may not be the final solution to Robert's issues with proxying...since I don't know what the issue is there, I can't say. I will say that this version fixes some known issues with plugins that depend on log4j. -john Robert Glover wrote: Ok, I located a DSL line that does not go through the proxy. Tomorrow I'll bring in my personal laptop to work and use it to connect to the maven IRC channel at irc.codehaus.org Meanwhile, wouldn't it be nice if everyone was a good maven citizen and downloaded the maven 2.2 RC3 and tried it out-- which by the way would also be a help to see if anybody currently using maven 2.0.9 behind a firewall will discover their proxy is not being recognized any longer when they upgrade. - Original Message From: Robert Glover robertglove...@yahoo.com To: Maven Users List users@maven.apache.org Sent: Tuesday, June 16, 2009 12:05:53 PM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I'm feeling like a poor relation watching all the happy maven users at the banquet while I stand outside, hungry, peering in. The company I work for is pretty big. My department has started using maven and a following of developers is emerging who are asking us for advice on how to use maven in their projects as well. But maven totally stopped working at this entire company for any version higher than 2.0.9. Wayne and JDCasey have tried to be helpful, but I have not been able to actually interface with JDCasy because of the firewall at work that prevents IRC and the chat tag that is going on for days on google chat.. Can it really be that maven is so brittle that a total failure of the proxy for an entire company occurs for the mere reason that developers upgrade from maven 2.0.9 to a higher version? How can it be that the total failure of the maven proxying happens at this pretty big company and yet no one else is reporting this? This is very disheartening. Robert - Original Message From: Robert Glover robertglove...@yahoo.com To: Maven Users List users@maven.apache.org Sent: Monday, June 15, 2009 9:44:43 AM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I had Friday off, so I logged onto the maven IRC channel at home via ChatZilla, but unfortunately JDCASEY was not logged on when I tried several times. I tried again on Saturday, but again JDCASEY was not online. Today, Monday, I tried from work and found that the corporate firewell blocks IRC. I've been able to use Google IM in the past through the firewall. So, I've opened up gmail and have it on the chat page. JDCASEY, if you see this please consider sending a chat message to my gmail account. My email address there is robertglove...@gmail.com Meanwhile, I'll see I I can build the source code of maven 2.2 RC3 to have log messages to pinpoint the exact line of code causing the proxy problem. --- On Fri, 6/12/09, John Casey jdca...@commonjava.org wrote: From: John Casey jdca...@commonjava.org Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 To: Maven Users List users@maven.apache.org Date: Friday, June 12, 2009, 4:18 PM Do you have the ability to join our IRC channel at irc.codehaus.org (#maven) to talk more about this? If you have a firewall/proxy in the way of an IRC connection, you might also be able to use the CGI client at http://irc.codehaus.org. From looking at your output in the original message on this thread, it seems like Maven doesn't think you're supplying any authentication information... Maybe if we could talk more about this, I could help you look for the reason behind it all. I'm on IRC most days; my nickname is 'jdcasey'. Please come find me if you have the ability, and maybe we can figure this out. Thanks, -john Robert Glover wrote: Below is the message from Wayne I was referring to. Now that I have downloaded and built maven 2.2-RC3, I guess I could put log messages into it to pin-point the exact line of code where the proxy fails. But already as it is, in running maven 2.2-RC3 it already has debug level logging turned on and is showing a lot more information than was being shown when this problem started occuring when I upgraded from maven 2.0.9 to maven 2.1. The sad thing is I have been keeping this maven proxy problem to myself because we have only been using maven for a few months. If I make it be known that it won't work and there is no solution if we upgrade to any version higher than maven 2.0.9, it is likely the managers will ban maven from being used. -- Proxy issues are, by their very nature, almost impossible for an outsider to investigate and resolve. There are literally hundreds (or more) of proxy server software packages in the world
Re: [PLEASE TEST] Maven 2.2.0-RC3
Sorry I missed you previously. It seems like we're just not quite syncing up, but I'll try to stay on gtalk all day today to see if I can catch you. Robert Glover wrote: Ok, I located a DSL line that does not go through the proxy. Tomorrow I'll bring in my personal laptop to work and use it to connect to the maven IRC channel at irc.codehaus.org Meanwhile, wouldn't it be nice if everyone was a good maven citizen and downloaded the maven 2.2 RC3 and tried it out-- which by the way would also be a help to see if anybody currently using maven 2.0.9 behind a firewall will discover their proxy is not being recognized any longer when they upgrade. - Original Message From: Robert Glover robertglove...@yahoo.com To: Maven Users List users@maven.apache.org Sent: Tuesday, June 16, 2009 12:05:53 PM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I'm feeling like a poor relation watching all the happy maven users at the banquet while I stand outside, hungry, peering in. The company I work for is pretty big. My department has started using maven and a following of developers is emerging who are asking us for advice on how to use maven in their projects as well. But maven totally stopped working at this entire company for any version higher than 2.0.9. Wayne and JDCasey have tried to be helpful, but I have not been able to actually interface with JDCasy because of the firewall at work that prevents IRC and the chat tag that is going on for days on google chat.. Can it really be that maven is so brittle that a total failure of the proxy for an entire company occurs for the mere reason that developers upgrade from maven 2.0.9 to a higher version? How can it be that the total failure of the maven proxying happens at this pretty big company and yet no one else is reporting this? This is very disheartening. Robert - Original Message From: Robert Glover robertglove...@yahoo.com To: Maven Users List users@maven.apache.org Sent: Monday, June 15, 2009 9:44:43 AM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I had Friday off, so I logged onto the maven IRC channel at home via ChatZilla, but unfortunately JDCASEY was not logged on when I tried several times. I tried again on Saturday, but again JDCASEY was not online. Today, Monday, I tried from work and found that the corporate firewell blocks IRC. I've been able to use Google IM in the past through the firewall. So, I've opened up gmail and have it on the chat page. JDCASEY, if you see this please consider sending a chat message to my gmail account. My email address there is robertglove...@gmail.com Meanwhile, I'll see I I can build the source code of maven 2.2 RC3 to have log messages to pinpoint the exact line of code causing the proxy problem. --- On Fri, 6/12/09, John Casey jdca...@commonjava.org wrote: From: John Casey jdca...@commonjava.org Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 To: Maven Users List users@maven.apache.org Date: Friday, June 12, 2009, 4:18 PM Do you have the ability to join our IRC channel at irc.codehaus.org (#maven) to talk more about this? If you have a firewall/proxy in the way of an IRC connection, you might also be able to use the CGI client at http://irc.codehaus.org. From looking at your output in the original message on this thread, it seems like Maven doesn't think you're supplying any authentication information... Maybe if we could talk more about this, I could help you look for the reason behind it all. I'm on IRC most days; my nickname is 'jdcasey'. Please come find me if you have the ability, and maybe we can figure this out. Thanks, -john Robert Glover wrote: Below is the message from Wayne I was referring to. Now that I have downloaded and built maven 2.2-RC3, I guess I could put log messages into it to pin-point the exact line of code where the proxy fails. But already as it is, in running maven 2.2-RC3 it already has debug level logging turned on and is showing a lot more information than was being shown when this problem started occuring when I upgraded from maven 2.0.9 to maven 2.1. The sad thing is I have been keeping this maven proxy problem to myself because we have only been using maven for a few months. If I make it be known that it won't work and there is no solution if we upgrade to any version higher than maven 2.0.9, it is likely the managers will ban maven from being used. -- Proxy issues are, by their very nature, almost impossible for an outsider to investigate and resolve. There are literally hundreds (or more) of proxy server software packages in the world, and while they all more or less work for basic web browsing, most have issues with various pieces of software like Maven. I won't claim to know all the changes made to the Maven codebase from 2.0.9 to 2.1.0 (much less the changes in supporting utility libraries) but it would seem
Re: [PLEASE TEST] Maven 2.2.0-RC3
] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Jun 11 18:35:13 EDT 2009 [INFO] Final Memory: 2M/4M [INFO] C:\JavaLibs\aTestMaven220_rc3_a\simple From: John Casey jdca...@commonjava.org mailto:jdca...@commonjava.org To: Maven Users List users@maven.apache.org mailto:users@maven.apache.org Sent: Thursday, June 11, 2009 2:45:17 PM Subject: [PLEASE TEST] Maven 2.2.0-RC3 Hi, I've finally gotten through the assembly plugin release and the mess that is POM transformation, and I think we're ready to test another Maven 2.2.0 release candidate. You can grab this RC here: https://repository.apache.org/content/repositories/maven-staging-011/ The big change here is that POM tranformations have been completely backed out of Maven, pending further design discussion to address the relevant use cases more thoroughly. Along with this, I've added two new pseudo-features for MNG-3203 and MNG-3401. These are documented in: site-trunk/src/site/apt/guides/mini/guide-default-execution-ids.apt Additionally, I've documented the use of Animal Sniffer to ensure 1.4-compatible builds under: site-trunk/src/site/apt/guides/mini/guide-building-jdk14-on-jdk15.apt ...this is a stop-gap solution until the compiler plugin supports toolchains. I haven't published the site with these new documents yet, just in case there are some horrible and unforseen problems with what I've done. :-) Please give this release candidate a try, and let me know if you run into any problems. I'll probably let this sit for a couple of days, and if there aren't any problems I'll call a vote. Before this is a possibility, though, I'm going to need to incorporate the new policies on source-release distributions, so I'm just letting you know now that this isn't done yet. Thanks, and happy building! -john - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.0-RC3
Do you have the ability to join our IRC channel at irc.codehaus.org (#maven) to talk more about this? If you have a firewall/proxy in the way of an IRC connection, you might also be able to use the CGI client at http://irc.codehaus.org. From looking at your output in the original message on this thread, it seems like Maven doesn't think you're supplying any authentication information... Maybe if we could talk more about this, I could help you look for the reason behind it all. I'm on IRC most days; my nickname is 'jdcasey'. Please come find me if you have the ability, and maybe we can figure this out. Thanks, -john Robert Glover wrote: Below is the message from Wayne I was referring to. Now that I have downloaded and built maven 2.2-RC3, I guess I could put log messages into it to pin-point the exact line of code where the proxy fails. But already as it is, in running maven 2.2-RC3 it already has debug level logging turned on and is showing a lot more information than was being shown when this problem started occuring when I upgraded from maven 2.0.9 to maven 2.1. The sad thing is I have been keeping this maven proxy problem to myself because we have only been using maven for a few months. If I make it be known that it won't work and there is no solution if we upgrade to any version higher than maven 2.0.9, it is likely the managers will ban maven from being used. -- Proxy issues are, by their very nature, almost impossible for an outsider to investigate and resolve. There are literally hundreds (or more) of proxy server software packages in the world, and while they all more or less work for basic web browsing, most have issues with various pieces of software like Maven. I won't claim to know all the changes made to the Maven codebase from 2.0.9 to 2.1.0 (much less the changes in supporting utility libraries) but it would seem that some change has caused your proxy to stop working. If you seriously want to see this resolved, it will probably take some effort on your part to get Maven and all its libraries running in a debugger to try to track down what is different. Unless a ton of people start complaining about similar problems or the issue can be tracked to a specific change made in Maven (or a util library), I don't see this being resolved in any well-defined timeframe. So, I'd stick with 2.0.9 for now. Have you tried 2.0.10 yet? Wayne - Original Message From: John Casey jdca...@commonjava.org To: Maven Users List users@maven.apache.org Sent: Friday, June 12, 2009 10:38:30 AM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 Can you tell me what Wayne's explanation was for your proxy problem? Or, if Wayne's around, maybe he can chime in. I'm not familiar with this particular discussion, so I'm not sure how to help. Proxies can be incredibly hard to debug remotely, when I don't have access to probe the running system and find out where things are coming apart. -john Robert Glover wrote: The proxy error using 2.2.0-RC3 (see email below) was using the binary download. Since then, I've built 2.2.0-RC3 from source and am looking at it in Eclipse. It builds cleanly if I set it to not test; however I don't know how to run it (with it pointed to a pom.xml to build), so I'm just looking at the source code). The proxy problem I am having (see email below) is from org.apache.maven.artifact.manager.DefaultWagonManage; I can't pinpoint the exact line of source code. I cannot really take this further myself, with my level of expertise (or lack there-of), other than to have noticed that something similar to my problem is reported in a Jira that was opened around roughly the same time my problem first started happening. That Jira is: https://issues.sonatype.org/browse/NEXUS-515 I sure would be a happy camper if my meager contribution here could motivate someone to figure out how to get my proxy to work. A solution seems so tantalizingly close. For example, if I could compare the source code of the 2.0.9 version of DefaultWagManager to the source code version of it in later versions. From: Robert Glover robertglove...@yahoo.com mailto:robertglove...@yahoo.com To: Maven Users List users@maven.apache.org mailto:users@maven.apache.org Sent: Thursday, June 11, 2009 6:44:06 PM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I downloaded apache-maven-2.2.0-RC3 and tried it out but sadly, I get the same proxy problem I have been getting in all versions of maven subsequent to 2.0.9. Maven 2.0.9 continues to work fine, but if I change to 2.2.0.RC3 and use the same pom.xml file and the same settings.xml file (where the proxy config is) it causes a proxy error and I cannot do a mvn package Wayne has patiently explained to me that there is nothing to be done about this, I'm simply stuck using maven 2.0.9 forever or until by luck a subsequent release of Maven
Re: problem upgrading to Maven 2.1.0
Are you using mirrorOf*/mirrorOf or mirrorOfexternal:*/mirrorOf? If not, Maven may be encountering a different repositoryId that isn't in your list of mirrorOf entries in your settings.xml... -john Tim Andersen wrote: I am currently using Maven 2.0.9. When I upgraded to Maven 2.1.0, it seems to be trying to download dependencies from different repositories. I have doubled checked my settings.xml to make sure it uses the same as my 2.0.9 settings. We use Archiva 1.1.3 mirroring http://repo1.maven.org/maven2 The specific jars I'm having a problem with are howl-1.0.1-1.jar and xerces-2.0.2.jar. Here's where it is trying to get them from: http://servicemix.org/m2-repo/xerces/xerces/2.0.2/xerces-2.0.2.jar http://servicemix.org/m2-repo/org/objectweb/howl/howl/1.0.1-1/howl-1.0.1-1.pom Why is it trying to download these from different locations when they exist in my local mirror that is configured in my settings.xml? This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the originator of the message. This footer also confirms that this e-mail message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Iowa Student Loan. - 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
[PLEASE TEST] Maven 2.2.0-RC3
Hi, I've finally gotten through the assembly plugin release and the mess that is POM transformation, and I think we're ready to test another Maven 2.2.0 release candidate. You can grab this RC here: https://repository.apache.org/content/repositories/maven-staging-011/ The big change here is that POM tranformations have been completely backed out of Maven, pending further design discussion to address the relevant use cases more thoroughly. Along with this, I've added two new pseudo-features for MNG-3203 and MNG-3401. These are documented in: site-trunk/src/site/apt/guides/mini/guide-default-execution-ids.apt Additionally, I've documented the use of Animal Sniffer to ensure 1.4-compatible builds under: site-trunk/src/site/apt/guides/mini/guide-building-jdk14-on-jdk15.apt ...this is a stop-gap solution until the compiler plugin supports toolchains. I haven't published the site with these new documents yet, just in case there are some horrible and unforseen problems with what I've done. :-) Please give this release candidate a try, and let me know if you run into any problems. I'll probably let this sit for a couple of days, and if there aren't any problems I'll call a vote. Before this is a possibility, though, I'm going to need to incorporate the new policies on source-release distributions, so I'm just letting you know now that this isn't done yet. Thanks, and happy building! -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Assembly Plugin 2.2-beta-4 released
The Maven team is pleased to announce the release of the Maven Assembly Plugin, version 2.2-beta-4. This plugin is useful in creating project artifacts that custom layouts. It also includes a set of predefined standard custom artifact types you can choose to create. For more information, see: http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4/version /plugin Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 ** Bug * [MASSEMBLY-238] - Assembly plugin removes file permissions * [MASSEMBLY-379] - Follow-up: file permissions are removed when creating tar.gz assembly * [MASSEMBLY-413] - Assembly plugin uses absolute paths from project instance after interpolation * [MASSEMBLY-414] - Allow regular expressions in include/exclude patterns for filesets * [MASSEMBLY-416] - outputDirectory default value in fileSet seems changed; now seems to use directory name of fileSet sourcedir * [MASSEMBLY-417] - regex in/exclusion patterns can fail on Windows due to file-separator replacement. * [MASSEMBLY-418] - Broken link to assembly-1.1.0-SNAPSHOT.xsd * [MASSEMBLY-419] - All module directories are included with complete system path ** Improvement * [MASSEMBLY-421] - Maven repository layout like directory structure using dependencySet 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 Assembly Plugin 2.2-beta-4 released
The Maven team is pleased to announce the release of the Maven Assembly Plugin, version 2.2-beta-4. This plugin is useful in creating project artifacts that custom layouts. It also includes a set of predefined standard custom artifact types you can choose to create. For more information, see: http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4/version /plugin Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 ** Bug * [MASSEMBLY-238] - Assembly plugin removes file permissions * [MASSEMBLY-379] - Follow-up: file permissions are removed when creating tar.gz assembly * [MASSEMBLY-413] - Assembly plugin uses absolute paths from project instance after interpolation * [MASSEMBLY-414] - Allow regular expressions in include/exclude patterns for filesets * [MASSEMBLY-416] - outputDirectory default value in fileSet seems changed; now seems to use directory name of fileSet sourcedir * [MASSEMBLY-417] - regex in/exclusion patterns can fail on Windows due to file-separator replacement. * [MASSEMBLY-418] - Broken link to assembly-1.1.0-SNAPSHOT.xsd * [MASSEMBLY-419] - All module directories are included with complete system path ** Improvement * [MASSEMBLY-421] - Maven repository layout like directory structure using dependencySet Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.0-RC2
) at org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecut or.java:186) ... 26 more rgds, Markku John Casey wrote: Hi again, After finding and cleaning up some code that seems to be tainted during some of our efforts at generifying the codebase, we've respun a new release candidate. If you have time, please give it a whirl: https://repository.apache.org/content/repositories/maven-staging-010/org/apache/maven/apache-maven/2.2.0-RC2/ Remember, if you have any problems, report them to: http://jira.codehaus.org/browse/MNG with Affects-Version: 2.2.0 ...then, please reply to this thread to let me know about the issue! :-) Thanks for testing! -john - 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
Re: [PLEASE TEST] Maven 2.2.0-RC2
I just grepped the uberjar file listing in RC2 for 'ightweight' and came up with nothing. Are you sure the lightweight wagon is present in the copy you have? Arnaud HERITIER wrote: I thought the wagon-lightweight was always here.It's with the 2.2.0-RC you delivered. Arnaud On Mon, May 18, 2009 at 5:35 PM, John Casey jdca...@commonjava.org wrote: Arnaud, are you saying that you see something like: May 6, 2009 1:58:26 PM hidden.org.apache.commons.httpclient.HttpMethodBase processCookieHeaders WARNING: Cookie rejected: $Version=0; JSESSIONID=E545E65FB5E46552ED8473D17DF1DC80; $Path=/servlets. Illegal path attribute /servlets. Path of origin: /nonav/repository//com.google.collections/jars/google-collections-0.9.jar even when using the lightweight http wagon? Is that using 2.1.0, or did you roll your own Maven 2.2.0-* with wagon-lightweight reintroduced? -john Arnaud HERITIER wrote: With the lightweight http wagon I have the issue NEXUS-1967 (rejected cookies) also for downloads. Arnaud On Fri, May 15, 2009 at 8:47 AM, Markku Saarela markku.saar...@iki.fi wrote: Hi, Our release failed. There are two problems. Command line: mvn -Psome -Denv=some-dev release:perform -X 1. Command line -Psome profile activation is not working, at least prepare perform and rollback goals. [WARNING] Profile with id: 'some' has not been activated. 2. release:perform failed for some weird -f option [INFO] Failed to re-parse additional arguments for Maven invocation. Unrecognized option: -f [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to re-parse additional arguments for Maven invocation. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor .java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycl eExecutor.java:553) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor. java:523) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL ifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE xecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse additional arguments f or Maven invocation. at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor .java:678) ... 16 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed to re-parse additional arguments for Maven invocation. at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase .java:89) at org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.j ava:67) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java: 336) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java: 282) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java: 262) at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129) ... 18 more Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Failed to re-parse additiona l arguments for Maven invocation. at org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecut or.java:335) at org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut or.java:377) at org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecut or.java:413) at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute
[PLEASE TEST] Maven 2.2.0-RC2
Hi again, After finding and cleaning up some code that seems to be tainted during some of our efforts at generifying the codebase, we've respun a new release candidate. If you have time, please give it a whirl: https://repository.apache.org/content/repositories/maven-staging-010/org/apache/maven/apache-maven/2.2.0-RC2/ Remember, if you have any problems, report them to: http://jira.codehaus.org/browse/MNG with Affects-Version: 2.2.0 ...then, please reply to this thread to let me know about the issue! :-) Thanks for testing! -john - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[PLEASE TEST] Maven 2.2.0-RC1
Hi everyone, It's that time again. For the 2.2.0 release of Maven, we're trying to keep the number of issues fairly limited to regressions, issues with quite a few votes that are low-hanging fruit, and some sort of strategic issues. We're moving Maven to JDK 1.5 with this release, though the entire API has not yet been generified. We've resolved 15 issues (one is still open, waiting for me to finalize the associated site docs). The full listing is at the bottom of this message, and the link to the release notes is: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=15103 You can find the RC1 staging artifacts here: https://repository.apache.org/content/repositories/maven-staging-008/ ...and the binary/source distribution archives here: https://repository.apache.org/content/repositories/maven-staging-008/org/apache/maven/apache-maven/2.2.0-RC1/ Please note that Maven 2.2.0 will require JDK 1.5 to run, so take this into consideration when testing. If you come across any problems, please file an issue in: http://jira.codehaus.org/browse/MNG and set Affects-Version == 2.2.0. Thanks! -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp What we have to learn to do, we learn by doing. -Aristotle Release Notes: --- Release Notes - Maven 2 - Version 2.2.0 ** Sub-task * [MNG-4144] - document escape character for curly braces in clear-text passwords for settings.xml password security * [MNG-4145] - switch to released versions of plexus-sec-dispatcher (and by ext. plexus-cipher) once they're available ** Bug * [MNG-3553] - cannot resolve dependency with scope import * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4082] - Encryption is triggered if passwords merely contain curly braces * [MNG-4126] - [regression] Properties defined in profiles.xml of parent are not inherited during multimodule build * [MNG-4137] - NPE in DefaultLIfecycleExecutor when run from within Hudson builds * [MNG-4140] - Properties incorrectly replaced in pom * [MNG-4146] - password security doesn't work with custom password providers * [MNG-4147] - very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header ** Improvement * [MNG-2979] - Cross module dependencies for multi-module site * [MNG-3834] - Improve error message when dependency with classifier is missing version ** Task * [MNG-4143] - Update Java requirement to 1.5 ** Wish * [MNG-4139] - avoid the schema location in generated maven-metadata*.xml - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 2.1.0 not passing on system properties to java virtual machine
Another couple things to consider: 1. in Surefire, you should probably use the systemProperties to pass on system properties explicitly. Just a suggestion. 2. For actual system properties, it might be wiser to set them in MAVEN_OPTS instead of the mvn -D option. This is because Maven has deprecated the propagation of -D options into system properties, in order to make it a little friendlier for people trying to run multiple maven instances in a single JVM (without getting cross-pollution of sysprops). Using MAVEN_OPTS (which IIRC you can set in Hudson), you can still specify '-Dsystem.property=foo' and have it work fine. -john edward eric pedersson wrote: yes you are right. It seems 2.4.3 of the plugin is broken but 2.4.2 works just fine. will lock down the version is the pom. thanks for your help 2009/4/20 Stephen Connolly stephen.alan.conno...@gmail.com: Have you locked down the version of surefire you are using in your pom? if you have not locked it down, then you will be picking up a newer version of surefire with 2.1.0. AFAIK, a newer version of surefire has issues passing system properties to the forked process. in any case you should always lock down the versions of plugins that you are using or else your build is not fully reproducible -Stephen 2009/4/20 edward eric pedersson cpsmadn...@googlemail.com: Hi We use the command line to pass on system properties to the java virtual machine when running our Hudson builds on a Linux box. It used to work quite well in 2.0.9 by since we upgraded to 2.1.0 it has stopped working altogether. The system properties just never make it to the java virtual machine. I have created a small test project and indeed it does not work at all. I have attached it in case you want to give it a go. [it got blocked so sending without attachment] This should work just fine with maven 2.0.9 mvn2.0.9 -Dsystem.test.property=test test But this will fail mvn2.1 -Dsystem.test.property=test test The java code simply does this assertTrue( System.getProperty(system.test.property) != null); Any thoughts -- -- e - 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
Re: maven 2.1.0 not passing on system properties to java virtual machine
Well, if you want, go ahead and file a JIRA for it in
http://jira.codehaus.org/browse/MNG and we can at least take a look to
make sure there isn't a better way.
FWIW, if you put the systemProperties entry in place with a value of
'${system.property}', then use -Dsystem.property=foo in the mvn command
line, that will probably work. It's at least something to try.
-john
edward eric pedersson wrote:
I need to pass the options on the command line so using
systemProperties might not work for me unless I misunderstand what you
mean.
How do you pass the -DpropertyName using the MAVEN_OPTS ? I m pretty
sure that was the first thing I tried before adding them as system
properties properly as described in my email earlier.
I did search for documentation but it was kind of sparse.
2009/4/20 John Casey jdca...@commonjava.org:
Another couple things to consider:
1. in Surefire, you should probably use the systemProperties to pass on
system properties explicitly. Just a suggestion.
2. For actual system properties, it might be wiser to set them in MAVEN_OPTS
instead of the mvn -D option. This is because Maven has deprecated the
propagation of -D options into system properties, in order to make it a
little friendlier for people trying to run multiple maven instances in a
single JVM (without getting cross-pollution of sysprops).
Using MAVEN_OPTS (which IIRC you can set in Hudson), you can still specify
'-Dsystem.property=foo' and have it work fine.
-john
edward eric pedersson wrote:
yes you are right.
It seems 2.4.3 of the plugin is broken but 2.4.2 works just fine.
will lock down the version is the pom.
thanks for your help
2009/4/20 Stephen Connolly stephen.alan.conno...@gmail.com:
Have you locked down the version of surefire you are using in your pom?
if you have not locked it down, then you will be picking up a newer
version of surefire with 2.1.0.
AFAIK, a newer version of surefire has issues passing system
properties to the forked process.
in any case you should always lock down the versions of plugins that
you are using or else your build is not fully reproducible
-Stephen
2009/4/20 edward eric pedersson cpsmadn...@googlemail.com:
Hi
We use the command line to pass on system properties to the java
virtual machine when running our Hudson builds on a Linux box. It used
to work quite well in 2.0.9 by since we upgraded to 2.1.0 it has
stopped working altogether. The system properties just never make it
to the java virtual machine.
I have created a small test project and indeed it does not work at
all. I have attached it in case you want to give it a go. [it got
blocked so sending without attachment]
This should work just fine with maven 2.0.9
mvn2.0.9 -Dsystem.test.property=test test
But this will fail
mvn2.1 -Dsystem.test.property=test test
The java code simply does this
assertTrue( System.getProperty(system.test.property) != null);
Any thoughts
--
-- e
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 2.1.0 not passing on system properties to java virtual machine
Should just be a matter of registering a new username for yourself, then clicking the Create Issue link in the top menu at http://jira.codehaus.org/browse/MNG Let me know if that doesn't work for you. -john edward eric pedersson wrote: Will do once I work out how to submit issues in your Jira 2009/4/20 Brian Fox bri...@infinity.nu: Please file a jira for this and use 2.1.0 as the affects version so we can get it fixed in 2.1.1 edward eric pedersson wrote: Hi We use the command line to pass on system properties to the java virtual machine when running our Hudson builds on a Linux box. It used to work quite well in 2.0.9 by since we upgraded to 2.1.0 it has stopped working altogether. The system properties just never make it to the java virtual machine. I have created a small test project and indeed it does not work at all. I have attached it in case you want to give it a go. [it got blocked so sending without attachment] This should work just fine with maven 2.0.9 mvn2.0.9 -Dsystem.test.property=test test But this will fail mvn2.1 -Dsystem.test.property=test test The java code simply does this assertTrue( System.getProperty(system.test.property) != null); Any thoughts - 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] Maven 2.1.0 Released
The Maven team is pleased to announce the release of Maven 2.1.0. Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. You can download the new version at: http://maven.apache.org/download.html You can find release notes for this version below, or at: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14587 Enjoy, -The Maven team --- Release Notes - Maven 2.1.0 ** Sub-task * [MNG-4025] - Prominently document opt-out setting for parallel artifact resolution for users * [MNG-4042] - Use plexus-sec-dispatcher 1.0 in Maven core when it is released ** Bug * [MNG-1349] - openssl checksums are not accepted by maven * [MNG-1585] - debug logging from wagon not shown in debug mode * [MNG-1992] - CLI -D should override properties in settings.xml * [MNG-1999] - Reporting inheritance does not work properly * [MNG-2432] - Apache and Mojo plugins take precendence over plugins in the pom. * [MNG-2433] - Maven looks for snapshots in offline mode * [MNG-2605] - Profiles in profiles.xml are active by default * [MNG-2668] - Plugin dependencies should be considered when the reactor creates the build order list * [MNG-2690] - DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly * [MNG-2695] - -o makes build fail for snapshot plugins * [MNG-2720] - Multiproject dependencies not accurate for project.compileClasspathElements when run from root project * [MNG-3023] - Reactor projects should be included in dependency resolution * [MNG-3057] - properties not expanded in generated POMs when building A/B/C nested projects * [MNG-3139] - The skin does not exist: Unable to determine the release version * [MNG-3217] - a plugin's dependencies can influence other plugins in a build * [MNG-3228] - Maven profile activation does not work when profile is defined in inherited 'parent' pom * [MNG-3271] - excludeDefaults does not seem to work * [MNG-3284] - Cached plugins are used, even when the specifically declared * [MNG-3314] - offline build not running, when having SNAPSHOT dependencies * [MNG-3621] - site url inheritance broken for UNC paths * [MNG-3628] - When running offline, snapshot artifcats cannot be resolved even if they have previously be dowloaded from a repository * [MNG-3641] - Lack of error checks on profiles * [MNG-3645] - Maven doesn't do strict model validation for POMs in the current reactor * [MNG-3719] - [regression] plugin execution ordering no longer POM ordered in 2.0.9 * [MNG-3757] - Setting M2_HOME to nothing and running ant delets contents of the current folder * [MNG-3769] - [regression] Excluding relocated transitive dependencies does not work * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-3808] - Execution order of report plugins is arbitrary if inheritance is involved * [MNG-3810] - [regression] Null Pointer Exception when Activation Profile Property is Empty * [MNG-3811] - Report plugins don't inherit configuration * [MNG-3899] - Inheritance does not merge extensions with same gid and aid * [MNG-3906] - Project-level plugin dependencies are in random order after merging * [MNG-3920] - Problem using velocity component * [MNG-3930] - mvn.bat doesn't handle ampersand in Windows user name properly * [MNG-3933] - Profiles.xml does not pickup OS family * [MNG-3940] - Interpolation of environment variables is not case-insensitive on Windows * [MNG-3948] - Remote repos defined by profiles outside of settings.xml are not used to resolve parent POMs * [MNG-3974] - New mirror syntax is not stopping on first match * [MNG-4016] - Properties with the prefix project/pom are not interpolated from the properties section * [MNG-4023] - Profiles from parent POM are injected multiple times if parent is part of reactor build * [MNG-4026] - [regression] Order of project class path does not match POM order during reactor build * [MNG-4032] - Test jar dependency not available for for main classes in multi module builds * [MNG-4043] - Resolve or rollback WebDAV wagon deployment issue where hostname is improperly extracted from URL * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4079] - Duplicate error messages * [MNG-4084] - Unnecessary Warning for an activate profile in child project * [MNG-4086] - [regression] Explicitly using plugin metaversions crashes plugin manager * [MNG-4087] - Percent encoded characters in file URLs are not decoded upon deployment ** Improvement * [MNG-1830] - add a 'compiled on timestamp' label when maven 2 is invoked with --version option * [MNG-1957] - jdk/jdk
[ANN] Maven Plugin Tools 2.5 Released
The Maven team is pleased to announce the release of version 2.5 of Maven Plugin Tools, including the Maven Plugin Plugin. These libraries are used to generate plugin descriptors, documentation, and the implicit help mojo (as in: 'mvn installer:help'). http://maven.apache.org/plugin-tools http://maven.apache.org/plugins/maven-plugin-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId version2.5/version /plugin If you're creating a plugin that uses Ant-based mojos, you should also include the Ant tools library: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId version2.5/version dependencies dependency groupIdorg.apache.maven.plugin-tools/groupId artifactIdmaven-plugin-tools-ant/artifactId version2.5/version /dependency /dependencies /plugin Release Notes - Maven 2.x Plugin Tools - Version 2.5 ** Bug * [MPLUGIN-106] - remove no mojo deprecation warning and throw an exception * [MPLUGIN-109] - Misleading warning when creating a Maven plugin defining a custom packaging * [MPLUGIN-135] - Deprecated info in parameter table of goal page contains garbage * [MPLUGIN-136] - maven-plugin-tools-api requires relative script root paths * [MPLUGIN-137] - PluginDescriptorGenerator doesn't write plugin name * [MPLUGIN-140] - Plugin report states wrong JDK requirement ** Improvement * [MPLUGIN-100] - Allow customization of file encoding used for generated help goal * [MPLUGIN-101] - Allow customization of file encoding used for mojo extraction * [MPLUGIN-111] - Warn about usage of platform encoding * [MPLUGIN-138] - Suppress bogus warning in case goalPrefix has been set to default goal prefix * [MPLUGIN-141] - Output warning for deprecated component expressions * [MPLUGIN-145] - Improve Ant-Mojo support to provide parity with antrun plugin ** Task * [MPLUGIN-110] - Make easier to pass parameters into MojoDescriptorExtractors 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 Assembly Plugin 2.2-beta-3 Released
The Maven team is pleased to announce the release of the Maven Assembly
Plugin, version 2.2-beta-3
This plugin is used to create custom archives using the build output,
dependencies, and other files owned by a Maven project. You can find
more information, including instructions and examples, at:
http://maven.apache.org/plugins/maven-assembly-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-3/version
/plugin
Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-3
** Sub-task
* [MASSEMBLY-361] - Fix MASSEMBLY-285 default behaviour to be the
correct behaviour
** Bug
* [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file
mode nor uid/gid
* [MASSEMBLY-165] - Test error on Windows XP + Cygwin
* [MASSEMBLY-190] - Problem with dependency conflict resolution on
multi-module project
* [MASSEMBLY-196] - use of repository assembly is no longer working
* [MASSEMBLY-201] - classifier not included in name of dependency set
* [MASSEMBLY-211] - assembly plugin and jar plugin disagree about
whether to use uniqueVersion snapshot names
* [MASSEMBLY-213] - jar-with-dependencies and signed jars issue again
* [MASSEMBLY-217] - outputFileNameMapping needs to report collision.
* [MASSEMBLY-230] - fileset not filtering resources, but files
does filter
* [MASSEMBLY-236] - assembly:assembly resolves excluded artifacts
* [MASSEMBLY-237] - lineEnding ignored in a child project
* [MASSEMBLY-238] - Assembly plugin removes file permissions
* [MASSEMBLY-241] - Multiple includes in dependencySet
* [MASSEMBLY-242] - transitive dependencies do not get included
* [MASSEMBLY-245] - Manifest Section configuration does not work
properly
* [MASSEMBLY-251] - NullPointer wehn using scope system in a
dependencySet
* [MASSEMBLY-256] - Regression: pom properties are no longer
expanded in descriptor.
* [MASSEMBLY-264] - Filtering in Assembly Generates Blank Files in
the Archive
* [MASSEMBLY-270] - Assembly does not resolved managed dependencies
correctly
* [MASSEMBLY-280] - Regression: Dependency resolution for
dependencySets does broken things
* [MASSEMBLY-284] - regression: line ending setting is not honoured
* [MASSEMBLY-285] - regression: duplicate files added to the assembly
* [MASSEMBLY-287] - Unable to pass -DskipAssembly=true through the
command line to skip the assembly plugin.
* [MASSEMBLY-291] - attach the resulting assembly not working as
expected
* [MASSEMBLY-293] - fileSets not filtered in multimodule build,
but files are
* [MASSEMBLY-294] - Regression - dependency is skipped?
* [MASSEMBLY-297] - Assembly broke on GNU/Linux - NullPointerException
* [MASSEMBLY-298] - Includes/Excludes within unpackOptions are
ignored
* [MASSEMBLY-300] - Regression: outputFileNameMapping variable
resolution
* [MASSEMBLY-301] - assembly:attach wrongly renames/overwrites
assemblies to the primary artifact
* [MASSEMBLY-302] - Maven assembly plugin should use
plexus-archiver version
* [MASSEMBLY-306] - Dependency resolution fails with an NPE for a
provided dependency with a fixed version
* [MASSEMBLY-308] - Syntax Problem in Example Doco
* [MASSEMBLY-309] - outputFileNameMapping fails and includes
parent's name
* [MASSEMBLY-312] - outputFileNameMapping not respected when the
unpack=true
* [MASSEMBLY-314] - Multiple inclusion of dependencies in binary
assembly
* [MASSEMBLY-318] - Example to attach assembly to package incorrect
* [MASSEMBLY-319] - Cannot bind to lifecycle with multiple modules
* [MASSEMBLY-322] - Filtering in filesets in multimodule build does
not work
* [MASSEMBLY-328] - When assembly is attached to pom with
appendAssemblyId disabled, it won't be installed or deployed
* [MASSEMBLY-331] - assembly descriptor doesn't seem to property
substitute properties
* [MASSEMBLY-340] - Filtering doesn't work for multimodule assembly
builds
* [MASSEMBLY-341] - Fat JAR assemblies may result in JARs with
duplicate files
* [MASSEMBLY-342] - NPE when filtering fileSet
* [MASSEMBLY-345] - appxml attribute is required error when
making ears with the assembly plugin
* [MASSEMBLY-351] - ${project.} is not interpolated in the
descriptor
* [MASSEMBLY-354] - useTransitiveFiltering does NOT include
artifacts whose dependency trail matches one of the include patterns
when it has wildcards
* [MASSEMBLY-355] - I get duplicate files in my
-jar-with-dependencies.jar
* [MASSEMBLY-375] - Leading slash in Windows when including one
file in archive.
** Improvement
* [MASSEMBLY-76] - [assembly plugin] improve or clarify
inheriting/reusing descriptors
* [MASSEMBLY-159] - Add FAQ about building multi-module assemblies
from the top using Maven 2.0
*
[ANN] Maven Common Artifact Filters 1.1 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters shared component, version 1.1. This component is used to filter a list of Artifact instances based on various configurable criteria. You can find more information at: http://maven.apache.org/shared/maven-common-artifact-filters/ To use this component in your own project, you'll need to add the following dependency entry: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.1/version /dependency Unfortunately, this component did not have a separate list of issues, and therefore doesn't have an independent section of Release Notes. All filtering issues were included in the release of maven-assembly-plugin version 2.2-beta-3 (http://jira.codehaus.org/browse/MASSEMBLY/fixforversion/13507). Future releases will include a separate list of issues for this component. 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 Archiver 2.4 Released
The Maven team is pleased to announce the release of the Maven Archiver shared component, version 2.4. This component is used to create custom archives that are configured from the POM. You can find more information at: http://maven.apache.org/shared/maven-archiver/ To use this component in your own project, you'll need to add the following dependency entry: dependency groupIdorg.apache.maven/groupId artifactIdmaven-archiver/artifactId version2.4/version /dependency Release Notes - Maven Shared Components - Version maven-archiver-2.4 ** Bug * [MSHARED-36] - Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots * [MSHARED-50] - Manifest sections are only added to the manifest when the archive is created ** New Feature * [MSHARED-32] - Customization of jar-name pattern of classpath-entries inside MANIFEST.MF 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 2.1.0-M1 Released
The Maven team is pleased to announce the release of the Maven 2.1.0-M1.
This release signals the beginning of a new direction in the development
of Maven. Recently, Maven's development efforts were split into three
major goals. First, the Maven 2.0.x code line will be minimally
maintained for regression fixes; the 2.0.x series should be entering
end-of-life mode soon now that 2.1.0-M1 is out.
Next, the 2.x series aims to accomplish a relatively conservative series
of new features, improved implementations, and other changes that bring
with them too much risk to be appropriate for a revision release on the
2.0.x version series. Each of these releases - 2.1, 2.2, and so on -
will be preceded by a formal release plan.
Finally, the 3.x series is the home of Maven's more aggressive
improvements, including wholesale reimplementation of subsystems and the
introduction of major new features.
This means that all discussions in the past that referred to Maven 2.1
now apply mainly to Maven 3.x, currently under development. We will
backport some of the smaller features to the 2.x version series,
provided we can contain the risk of these features and provide a smooth
transition from one version to the next for the user.
You can download Maven here:
http://maven.apache.org/download.html
Release Notes - Maven 2 - Version 2.1.0-M1
** Bug
* [MNG-2068] - Multiple inheritance fails to find grand parent in
../../pom.xml when the groupIds differ (Test Case Attached)
* [MNG-2318] - When a project has modules and its parent is not
preinstalled the build fails
* [MNG-2695] - -o makes build fail for snapshot plugins
* [MNG-2739] - Repository entries are not validated and NPE will occur
* [MNG-2873] - Unable to find transitive dependencies when they
have been relocated.
* [MNG-3052] - Transitive Dependency not found when repo is not listed
* [MNG-3070] - ${x} properties no longer expanded in /version tag
after 2.0.3
* [MNG-3106] - Multiple profile activation conditions broken
* [MNG-3368] - Printing version (-v argument) should not stop
lifecycle execution
* [MNG-3380] - MavenMetadataSource retrieves ResolutionGroup
without consulting ManagedVersionMap, is problem when relocation
* [MNG-3475] - Some directories are not basedir aligned
* [MNG-3482] - merging managed dependencies happens before
managed-dependency versions are interpolated
* [MNG-3497] - rar, par and ejb3 archives should not be added to
classpath
* [MNG-3498] - StringIndexOutOfBounds -1 during path translation
while reading pom.xml
* [MNG-3527] - profile deactivation has no affect
* [MNG-3530] - Regression: Properties get resolved before the
LifeCycle is Forked.
* [MNG-3535] - Valid properties which look self referential fail to
resolve
* [MNG-3536] - REGRESSION: pom.build.sourceDirectory in Maven
2.0.9: it doesn't work anymore
* [MNG-3545] - Option -P-profile overridden if profile is
activebyDefault
* [MNG-3581] - stage:copy ClassCastException with maven 2.0.9
* [MNG-3584] - possible new memory leak in Maven 2.0.9
* [MNG-3585] - nonProxyHosts separator is wrong in the default
settings.xml
* [MNG-3599] - webdav does not set http-proxy correctly
* [MNG-3622] - upgrade to wagon 1.0-beta-4
* [MNG-3639] - Ant 1.7.0 Task not found after upgrading from Maven
2.0.8 to 2.0.9
* [MNG-3642] - back-propagation of resources doesn't handle
multiple resources with the same directory
* [MNG-3645] - Maven doesn't do strict model validation for POMs in
the current reactor
* [MNG-3651] - mvn.bat returns an incorrect error code
* [MNG-3654] - [regression] unable to build ServiceMix 3 -
IndexOutOfBoundsException in mergeDeterministicBuildElements
* [MNG-3667] - Dependencies resolution is wrong in some cases
(xfire-core:1.2.6 for example)
* [MNG-3671] - plugin-level dependencies in POMs are not
interpolated at correct time
* [MNG-3679] - executionid${some.custom.var}/id ... broke
* [MNG-3680] - POM validation fails on projects in central repo
starting with 2.0.10 RCs
* [MNG-3684] - Injection of Build instance as report parameter
results in uninterpolated values for build.directory, etc.
* [MNG-3693] - Updating project POM via project.setFile(..) changes
project basedir, and project classpath when used as a dependency in a
reactor
* [MNG-3694] - plugin parameters injecting
${project.compileSourceRoots} get uninterpolated source directories
* [MNG-3697] - NPE at DefaultPluginManager line 700 (from Hudson CI)
* [MNG-3701] - ClassCastException when building settings.xml with
profiles that have activeByDefault set
* [MNG-3703] - ExecutionProject contains relative paths in
compileSourceRoots
* [MNG-3704] - NPE in DefaultLIfecycleExecutor when run from within
Hudson builds
* [MNG-3705] - Expression: ${executedProject} doesn't work in reports
* [MNG-3710] -
Re: [PLEASE TEST] Maven 2.1.0-M1-RC17
Yeah, originalModel looks like it's saved off after inheritance occurs, so the only thing I was able to do this go around was to keep it from getting polluted by plugin information that's discovered by the plugin manager during build execution...so, if you don't have a plugin version legitimately from your POM or one of its parents, it won't ever appear in the originalModel. Stephen Connolly wrote: BTW, I think we're still getting the project.getOriginalModel().getBuild().getPluginManagement() containing the super-pom (but as that is 2.0.9 behaviour it's not a regression form 2.0.9... perhaps from previous versions but not from 2.0.9) On Thu, Sep 11, 2008 at 12:50 PM, Stephen Connolly [EMAIL PROTECTED] wrote: Seems fine here too On Thu, Sep 11, 2008 at 12:29 PM, Peter Horlock [EMAIL PROTECTED] wrote: RC17 runs smooth and nicely here too... Thanks, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Flatten dependencySet includes (assembly plugin)
there's an open issue related to mappers in http://jira.codehaus.org/browse/MASSEMBLY That issue covers this functionality, and hasn't been completed yet. sverhagen wrote: Hi. Using the assembly plugin. Is there a way to get stuff that's in a certain folder X of a dependency end up in my assembly's folder Y. Given the following assembly.xml: dependencySets dependencySet outputDirectory/sql/outputDirectory unpacktrue/unpack unpackOptions includes includeetc/sql/*.sql/include /includes /unpackOptions /dependencySet /dependencySets I was hoping for *.sql to be assembled into /sql. Now it's ending up in /sql/etc/sql :-( Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.1.0-M1-RC17
Hi, I've fixed MNG-3748, where illegal elements in the settings.xml were not triggering build failure. Anyway, this release candidate includes a fix for that issue: http://people.apache.org/~jdcasey/stage/current-maven-RC/ Enjoy, and let me know if you have problems. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.1.0-M1-RC15
Hi everyone, I've fixed a bug in RC13 (yes, it took two tries, thus the RC15 version of this post). You can find the new release candidate here: http://people.apache.org/~jdcasey/stage/current-maven-RC As a matter of fact, I'll just start updating this URL with the latest RC when I roll a new one, to make it easier to type/remember/etc. For what it's worth, I'm still working on one known issue which will necessitate an RC16: http://jira.codehaus.org/browse/MNG-3746 However, this last issue (MNG-3743) was so ugly I didn't want to wait to get something out to you all that you could test. Please let me know if you find any [other] issues. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.1.0-M1-RC16
Hi again, I've fixed two more issues that came up in RC13 and the intervening release candidates: - http://jira.codehaus.org/browse/MNG-3746 - http://jira.codehaus.org/browse/MNG-3747 Here's the URL for the RC16 release candidate: http://people.apache.org/~jdcasey/stage/current-maven-RC/ Please give it a shot and let me know if you find any more issues. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: my maven plugin .IllegalStateException
If this is a custom plugin, make sure your plugin's POM contains: packagingmaven-plugin/packaging cody zhang wrote: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-checksnapshot-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-checksnapshot-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:317) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:207) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:171) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1257) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1221) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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) [INFO] [INFO] Total time: 1 second -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.1.0-M1-RC13
I've replicated this problem in some of my own projects. It seems that
the key is to have the compiler plugin configured in the
pluginManagement section of the POM, and then to enable a report like
the javadoc reports that will cause the lifecycle to fork and compile
sources. At that point, it seems to lose the pluginManagement section,
but I haven't gotten into it far enough to know why yet.
The JIRA issue is: http://jira.codehaus.org/browse/MNG-3743
Christian Schulte wrote:
Martin Höller wrote:
Hi!
On Thursday 04 September 2008 John Casey wrote:
On the last go around, we had one issue pop up with maven plugin builds
(though it might also apply to build extensions in the reactor as well).
I've fixed it, and now here's the lucky 13th release candidate:
http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC13/org/ap
ache/maven/apache-maven/2.1.0-M1-RC13/
Please give it a spin (especially you, Arnaud! :) ), and let me know if
you have any trouble.
Building (compiling, testing, packaging, installing) our multimodule
projects works without problems in 2.0.9 and 2.1.*.
However, I found one problem with site generation: when executing
'mvn site' I get the following error:
[INFO] [compiler:compile]
[INFO] Compiling 6 source files to
/home/martin/svndir/emcs/emcs-common/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/martin/svndir/emcs/emcs-common/src/main/java/at/co/xss/emcs/util/Pair.java:[33,17]
generics are not supported in -source 1.3
(try -source 1.5 to enable generics)
public class PairA, B
I configured the maven compiler plugin in the parent's pluginManagement
section as follows:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source1.5/source
target1.5/target
encoding${fileEncoding}/encoding
/configuration
/plugin
Compilation works fine when executing 'mvn compile'. Mith maven 2.0.9
'mvn site' also works with no problems but not with 2.1.0-M1-RC13.
I'm using maven-site-plugin version 2.0-beta-7.
Any ideas?
- martin
Hi,
similar problem here. mvn install works, mvn site gives compile error.
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
...src/test/java/SerializableUtility.java:[53,19] ';' expected
...src/test/java/SerializableUtility.java:[53,19] ';' expected
That line reads:
assert args.length == 1;
As it seems, the site plugin cannot compile assertions with
2.1.0-M1-RC13 anymore. Generating the site with maven 2.0.9 works.
mvn help:effective-pom shows
plugin
artifactIdmaven-site-plugin/artifactId
versionRELEASE/version
configuration
outputEncodingUTF-8/outputEncoding
inputEncodingUTF-8/inputEncoding
localesen/locales
/configuration
/plugin
for both, 2.0.9 and 2.1.0-M1-RC13.
I can work around the compile error by first compiling by using e.g. mvn
install before doing a mvn site since that way, the site plugin does not
need to compile anything. Doing mvn clean followed by mvn site leads to
the compile error, however.
--
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.1.0-M1-RC13
Hi again everyone, On the last go around, we had one issue pop up with maven plugin builds (though it might also apply to build extensions in the reactor as well). I've fixed it, and now here's the lucky 13th release candidate: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC13/org/apache/maven/apache-maven/2.1.0-M1-RC13/ Please give it a spin (especially you, Arnaud! :) ), and let me know if you have any trouble. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
If you can't reproduce this problem using version 2.0.9, but can reproduce it (a couple times) using RC11, please file a jira issue: http://jira.codehaus.org/browse/MNG I'll need you to re-run the build using RC11 and the -X command-line option, to produce debug output, then capture that output to a file and attach the file to the JIRA issue. This sort of command should work for capturing: mvn blah console.txt Also, if you have a sample project (a mock project, not a real one from your work unless it's open source), this could be critical to allowing me to reproduce the problem in the minimum amount of time. I work on OS X, so it'll be difficult enough to debug this issue using a remote Windows VM instance, and the test project could be a real blessing. This looks like a file-locking or permissions issue in Windows, but I really can't tell for sure one way or the other without more information. If you'd like this issue solved, I'm happy to go to the effort to debug and fix it, but I need your help to give me a starting point. Thanks, -john Geoffrey Wiseman wrote: On Mon, Aug 25, 2008 at 4:15 PM, John Casey [EMAIL PROTECTED] wrote: Hi again, One bug was identified in 2.0.10-RC10 last Friday night. This release candidate addresses that issue. You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Please give this a spin when you get a chance, and let us know if you find any problems. We'll file any issues in JIRA against version 2.0.10 for tracking purposes, and to give us a JIRA # to use when writing the integration test to verify the fix. Don't know the cause of this, but with RC-11, I get this error on invocation of the shade plugin [INFO] Replacing C:\dev\work\X-multiproject\console\target\X-console-2.2-SNAPSHOT.jar with C:\dev\work\X-multiproject\console\target\X-console-2.2-SNAPSHOT-shaded.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar. Embedded error: C:\dev\work\X-multiproject\console\target\dependency-reduced-pom.xml (Access is denied) This isn't true on 2.0.9. - Geoffrey -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] 2.1.0-M1-RC12 of Maven (was: Maven 2.0.10-RC*)
Hi everyone, Sorry if the subject of this message is a little confusing, but we're in the process of relabeling the code in this release candidate to be part of a new version, a departure from the 2.0.x codebase. This release candidate contains some large modifications, even though it's meant to be backward compatible, and the risk that entails makes the relabeling appropriate. In any case, I'm anticipating one of a set of possible results from this relabeling discussion, and calling this RC 2.1.0-M1-RC12 (since it needs *some* name). You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC12/org/apache/maven/apache-maven/2.1.0-M1-RC12/ Please give it a try when you have time. I think you'll find this the most stable of all our attempts so far, and possibly even the one we'll promote for a final release, whatever version it winds up having. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
Are you running this build in hudson, or in some sort of modified maven environment? Ravi Luthra wrote: I don't know what this means: [WARNING] WARNING This Maven runtime contains a LifecycleExecutor component with an incomplete configuration. LifecycleExecutor class: org.apache.maven.lifecycle.LifecycleExecutorInterceptor Missing component requirement: org.apache.maven.project.MavenProjectBuilder [WARNING] WARNING This Maven runtime contains a LifecycleExecutor component with an incomplete configuration. LifecycleExecutor class: org.apache.maven.lifecycle.LifecycleExecutorInterceptor Missing component requirement: org.apache.maven.project.interpolation.ModelInterpolator But I get that on all my builds. Is there some POM problem this could indicate? On Mon, Aug 25, 2008 at 1:15 PM, John Casey [EMAIL PROTECTED] wrote: Hi again, One bug was identified in 2.0.10-RC10 last Friday night. This release candidate addresses that issue. You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Please give this a spin when you get a chance, and let us know if you find any problems. We'll file any issues in JIRA against version 2.0.10 for tracking purposes, and to give us a JIRA # to use when writing the integration test to verify the fix. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
Hudson is actually the use case for which I wrote that warning. The problem is, the DefaultLifecycleExecutor component was modified in the latest round of development, and now has a couple new component dependencies, or requirements. Since Hudson extends this component implementation directly instead of providing its own, its component definition is out of date now, and leads to weird errors when using the latest release candidates. I've compensated for such use cases in the new Maven code, but I wanted to make it clear that the Hudson extension to this component needs to be adjusted. I'll clean up the message to make it clear that the implementor needs to adjust, not the user. -john Ravi Luthra wrote: Yes it was inside Hudson. I just tested in Netbeans using external Maven, and the warnings are not there. On Thu, Aug 28, 2008 at 7:37 AM, John Casey [EMAIL PROTECTED] wrote: Are you running this build in hudson, or in some sort of modified maven environment? Ravi Luthra wrote: I don't know what this means: [WARNING] WARNING This Maven runtime contains a LifecycleExecutor component with an incomplete configuration. LifecycleExecutor class: org.apache.maven.lifecycle.LifecycleExecutorInterceptor Missing component requirement: org.apache.maven.project.MavenProjectBuilder [WARNING] WARNING This Maven runtime contains a LifecycleExecutor component with an incomplete configuration. LifecycleExecutor class: org.apache.maven.lifecycle.LifecycleExecutorInterceptor Missing component requirement: org.apache.maven.project.interpolation.ModelInterpolator But I get that on all my builds. Is there some POM problem this could indicate? On Mon, Aug 25, 2008 at 1:15 PM, John Casey [EMAIL PROTECTED] wrote: Hi again, One bug was identified in 2.0.10-RC10 last Friday night. This release candidate addresses that issue. You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Please give this a spin when you get a chance, and let us know if you find any problems. We'll file any issues in JIRA against version 2.0.10 for tracking purposes, and to give us a JIRA # to use when writing the integration test to verify the fix. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
Great to hear. Thanks for checking.
-john
Peter Horlock wrote:
Well, my issue concerning the compiler seems to have been solved with RC11 -
the entire build is working now.
Maybe it had something to do with the fact that I am setting the compiler
version by using a property:
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
source${javaVersion}/source
target${javaVersion}/target
/configuration
/plugin
Cheers,
Peter
2008/8/25 John Casey [EMAIL PROTECTED]
Well, looks like I lost track of a few issues that came up with RC10. I'll
work on addressing those issues, and probably follow up with an RC12 if we
find bugs.
-john
John Casey wrote:
Hi again,
One bug was identified in 2.0.10-RC10 last Friday night. This release
candidate addresses that issue. You can find it here:
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/
Please give this a spin when you get a chance, and let us know if you find
any problems. We'll file any issues in JIRA against version 2.0.10 for
tracking purposes, and to give us a JIRA # to use when writing the
integration test to verify the fix.
Thanks,
-john
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.0.10-RC11
Hi again, One bug was identified in 2.0.10-RC10 last Friday night. This release candidate addresses that issue. You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Please give this a spin when you get a chance, and let us know if you find any problems. We'll file any issues in JIRA against version 2.0.10 for tracking purposes, and to give us a JIRA # to use when writing the integration test to verify the fix. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC10
What's your target and source set to in the compiler plugin configuration? Are you certain the exact same POM is working in 2.0.9? -john Peter Horlock wrote: Using RC10, the following fails, which was working with 2.0.9: (seems like it doesn't like enums?!) mvn clean tomcat:deploy -o [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'tomcat'. [INFO] [INFO] Building webclient [INFO]task-segment: [clean, tomcat:deploy] [INFO] [INFO] [clean:clean] [INFO] Deleting directory target [INFO] Preparing tomcat:deploy [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 57 source files to target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure MyClass.java:[22,1] annotations are not supported in -source 1.3 (try -source 1.5 to enable annotations) @SuppressWarnings(nls) *MyEnum.java:[17,7] 'class' or 'interface' expected* [...other, similar errors...] [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:338) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682) ... 20 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Mon Aug 25 13:32:46 CEST 2008 [INFO] Final Memory: 11M/20M [INFO] - -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC10
Can you provide a failing test case we could use as a basis for an integration test? Something that would help us debug your specific use case would be very helpful. Thanks, -john Peter Horlock wrote: It seems that you don't have the maven-compiler-plugin configured correctly. You must set the source as 1.5 to use Enums. See [1] for more information. [1]http://maven.apache.org/general.html#Compiling-J2SE-5 Nope, I have that configured - and as I said, it's working with Maven 2.09... Peter -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC11
Well, looks like I lost track of a few issues that came up with RC10. I'll work on addressing those issues, and probably follow up with an RC12 if we find bugs. -john John Casey wrote: Hi again, One bug was identified in 2.0.10-RC10 last Friday night. This release candidate addresses that issue. You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Please give this a spin when you get a chance, and let us know if you find any problems. We'll file any issues in JIRA against version 2.0.10 for tracking purposes, and to give us a JIRA # to use when writing the integration test to verify the fix. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC10
Please file a JIRA issue in http://jira.codehaus.org/browse/MNG and
attach a failing test project, if possible, that we could use to verify
the problem. The information below is far too little to diagnose the
problem.
Thanks,
-john
TM wrote:
Multi-module project fails with NPE on assembly:assembly (assembly plugin
used 2.2-beta-1; command used was mvn clean install assembly:assembly
eclipse:eclipse). Same configuration works with Maven 2.0.9. Below you will
find relevant excerpt from the build trace.
Best regards,
Thorsten
[INFO]
[INFO] Building OSIRIS Next
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building OSIRIS Next
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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)
[INFO]
[INFO] Total time: 55 minutes 18 seconds
[INFO] Finished at: Mon Aug 25 17:18:11 CEST 2008
[INFO] Final Memory: 36M/126M
[INFO]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC9
Just to follow up on the list, this was a small bug in the way maven was
being built. It's fixed, but in RC9 this will affect plugins that use
jackrabbit, commons-codec, or slf4j. The fix will be included in the
next RC.
-john
nicolas de loof wrote:
http://jira.codehaus.org/browse/MNG-3722 created for this, with a simple
demo project.
2008/8/19 nicolas de loof [EMAIL PROTECTED]
I get an issue with 2.0.10 RC9 and CXF plugin -this works with 2.0.9 :
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
19 ao¹t 2008 11:08:16 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading plugin
jar:file:/D:/platina/repository/org/apache/cxf/cxf-tools-wsdlto-databinding-jaxb/2.0.8/cxf-tools-ws
dlto-databinding-jaxb-2.0.8.jar!/META-INF/tools-plugin.xml
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Found 1 databindings in jaxb plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading jaxb databinding from jaxb plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading plugin
jar:file:/D:/platina/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/2.0.8/cxf-tools-wsdl
to-frontend-jaxws-2.0.8.jar!/META-INF/tools-plugin.xml
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Found 1 frontends in jaxws plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading jaxws frontend from jaxws plugin.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] trace
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: trace
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:697)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:54
2)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:373)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:334)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:185)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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)
Caused by: org.apache.maven.plugin.MojoExecutionException: trace
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:334)
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:228)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:672)
... 16 more
Caused by: java.lang.NoSuchMethodError: trace
at org.apache.commons.logging.impl.SLF4JLog.trace(SLF4JLog.java:96)
at
org.springframework.core.CollectionFactory.createConcurrentMapIfPossible(CollectionFactory.java:187)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.init(DefaultSingletonBeanRegistry.ja
va:82)
The CXF plugin seems to use my project dependencies (as I'm using slf4j)
for classpath during jaxb code generation
I ran the build with -X to compare dependency resolution trees but did not
found any change...
Maybe this is cause by some classloader conflict ?
What could I do to investigate more ?
2008/8/19 Martin Höller [EMAIL PROTECTED]
On Monday 18 August 2008 John Casey wrote:
Please, if you have the time, take 2.0.10-RC9 for a spin and tell us
what you think!
Works without any problems here.
- martin
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL
[PLEASE TEST] Maven 2.0.10-RC10
Hi again everyone, I wanted to announce the availability of the latest release candidate, 2.0.10-RC10. You can grab it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC10/org/apache/maven/apache-maven/2.0.10-RC10 I've closed the few issues that came out of RC9, and improved performance a great deal, so please give it a spin and let me know what you think. Also, while I know we've been talking on the dev list about releasing this code as Maven 2.1.0 (with the current trunk code now pushing toward a 3.0 release), I'm just going to keep referring to this as 2.0.10-RCxx until we finalize the direction with a vote. Everyone knows about this release candidate series by now, so it's as much to reduce possible confusion as anything else. Happy testing! -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC9
envars are definitely supposed to be prefixed by env. at all times. I
suspect you were exploiting a bug in the interpolator prior to this.
-john
Anders Hammar wrote:
Hi,
Turns out that it works if I use the (correct) notation of env.JBOSS_HOME.
I'm not sure if you still want to investigate? If so, I could fila a jira
for you.
In any case, below is the non-working pom if you want to check it out:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdjira/groupId
artifactIdjira/artifactId
version1.0-SNAPSHOT/version
packagingpom/packaging
namejira/name
properties
jboss.server.confdefault/jboss.server.conf
/properties
build
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
waitfalse/wait
container
containerIdjboss4x/containerId
home${JBOSS_HOME}/home
/container
configuration
typeexisting/type
home${JBOSS_HOME}/server/${jboss.server.conf}/home
properties
cargo.jboss.configuration${jboss.server.conf}/cargo.jboss.configuration
/properties
/configuration
/configuration
executions
execution
idstart-jboss/id
phasepre-integration-test/phase
goals
goalstart/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
Thanks,
/Anders
John Casey-5 wrote:
I'll look into it, but do you happen to have a full-scale test project
you could use to file a JIRA issue? It would be simplest if I have
something that's supposed to just work that I can run in the debugger
to figure out where it's coming up with the null.
I'll see what I can do with this information in any case.
Thanks,
-john
Anders Hammar wrote:
Also tried the 1.0-alpha-5 version of the cargo maven2 plugin (with mvn
2.0.10-RC9). Same problem.
/Anders
Anders Hammar wrote:
Hi,
I've run into a problem with this rc. When using the
org.codehaus.cargo:cargo-maven2-plugin:0.3.1 plugin (the start goal), it
can't retrieve my JBOSS_HOME env. It works with mvn 2.0.8 and 2.0.9, but
with 2.0.10-RC9 the plugin gets 'null' for some reason.
Here's my plugin configuration from my pom:
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
waitfalse/wait
container
containerIdjboss4x/containerId
home${JBOSS_HOME}/home
/container
configuration
typeexisting/type
home${JBOSS_HOME}/server/${jboss.server.conf}/home !-- this
doesn't work! --
properties
cargo.jboss.configuration${jboss.server.conf}/cargo.jboss.configuration
/properties
/configuration
/configuration
executions
execution
idstart-jboss/id
phasepre-integration-test/phase
goals
goalstart/goal
/goals
/execution
/executions
/plugin
/Anders
John Casey-5 wrote:
Hi everyone,
As you're probably aware, we've been working for some time to stabilize
Maven for the 2.0.10 release. After quite a bit of testing in the
development community - and 8 release candidates - it looks like we
finally have a candidate that is free of regressions and stable. You
can
download it here:
http://people.apache.org/~jdcasey/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9
While it does seem that all of our builds are happy with the new
release
candidate, we'd like to get your feedback on it before we finalize
things. This will help us respond to any regressions or critical issues
we may have missed BEFORE we do the release, instead of having to put
up
with major flaws for another release cycle.
Please, if you have the time, take 2.0.10-RC9 for a spin and tell us
what you think!
Thanks
Re: [PLEASE TEST] Maven 2.0.10-RC9
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9/ The first attempt at typing that link apparently wound up wrong. Apologies for that. -john Peter Horlock wrote: John, were can I download the latest RC? The link you provided doesn't seem to be working... Thanks, Peter -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC9
I'll look into it, but do you happen to have a full-scale test project
you could use to file a JIRA issue? It would be simplest if I have
something that's supposed to just work that I can run in the debugger
to figure out where it's coming up with the null.
I'll see what I can do with this information in any case.
Thanks,
-john
Anders Hammar wrote:
Also tried the 1.0-alpha-5 version of the cargo maven2 plugin (with mvn
2.0.10-RC9). Same problem.
/Anders
Anders Hammar wrote:
Hi,
I've run into a problem with this rc. When using the
org.codehaus.cargo:cargo-maven2-plugin:0.3.1 plugin (the start goal), it
can't retrieve my JBOSS_HOME env. It works with mvn 2.0.8 and 2.0.9, but
with 2.0.10-RC9 the plugin gets 'null' for some reason.
Here's my plugin configuration from my pom:
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
waitfalse/wait
container
containerIdjboss4x/containerId
home${JBOSS_HOME}/home
/container
configuration
typeexisting/type
home${JBOSS_HOME}/server/${jboss.server.conf}/home !-- this
doesn't work! --
properties
cargo.jboss.configuration${jboss.server.conf}/cargo.jboss.configuration
/properties
/configuration
/configuration
executions
execution
idstart-jboss/id
phasepre-integration-test/phase
goals
goalstart/goal
/goals
/execution
/executions
/plugin
/Anders
John Casey-5 wrote:
Hi everyone,
As you're probably aware, we've been working for some time to stabilize
Maven for the 2.0.10 release. After quite a bit of testing in the
development community - and 8 release candidates - it looks like we
finally have a candidate that is free of regressions and stable. You can
download it here:
http://people.apache.org/~jdcasey/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9
While it does seem that all of our builds are happy with the new release
candidate, we'd like to get your feedback on it before we finalize
things. This will help us respond to any regressions or critical issues
we may have missed BEFORE we do the release, instead of having to put up
with major flaws for another release cycle.
Please, if you have the time, take 2.0.10-RC9 for a spin and tell us
what you think!
Thanks,
-john
P.S. To see the list of issues that were closed for this release (so
far), check out:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven and logback
] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC9
Actually, probably the best thing you could do is boil the problem down
to the simplest build you can think of that expresses the problem, and
file a JIRA ticket with the project attached. Then, let me know what the
JIRA # is, and I'll have a look. I can put it up on the debugger to see
why the paths are getting crossed up, if that's what's going on.
Unfortunately, I don't really know enough about how the CXF plugin works
to do much in the way of debugging remotely.
Thanks,
-john
nicolas de loof wrote:
I get an issue with 2.0.10 RC9 and CXF plugin -this works with 2.0.9 :
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
19 ao¹t 2008 11:08:16 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading plugin
jar:file:/D:/platina/repository/org/apache/cxf/cxf-tools-wsdlto-databinding-jaxb/2.0.8/cxf-tools-ws
dlto-databinding-jaxb-2.0.8.jar!/META-INF/tools-plugin.xml
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Found 1 databindings in jaxb plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading jaxb databinding from jaxb plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading plugin
jar:file:/D:/platina/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/2.0.8/cxf-tools-wsdl
to-frontend-jaxws-2.0.8.jar!/META-INF/tools-plugin.xml
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Found 1 frontends in jaxws plugin.
19 ao¹t 2008 11:08:17 org.apache.cxf.tools.wsdlto.core.PluginLoader
loadPlugin
INFO: Loading jaxws frontend from jaxws plugin.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] trace
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: trace
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:697)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:54
2)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:373)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:334)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:185)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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)
Caused by: org.apache.maven.plugin.MojoExecutionException: trace
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:334)
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:228)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:672)
... 16 more
Caused by: java.lang.NoSuchMethodError: trace
at org.apache.commons.logging.impl.SLF4JLog.trace(SLF4JLog.java:96)
at
org.springframework.core.CollectionFactory.createConcurrentMapIfPossible(CollectionFactory.java:187)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.init(DefaultSingletonBeanRegistry.ja
va:82)
The CXF plugin seems to use my project dependencies (as I'm using slf4j) for
classpath during jaxb code generation
I ran the build with -X to compare dependency resolution trees but did not
found any change...
Maybe this is cause by some classloader conflict ?
What could I do to investigate more ?
2008/8/19 Martin Höller [EMAIL PROTECTED]
On Monday 18 August 2008 John Casey wrote:
Please, if you have the time, take 2.0.10-RC9 for a spin and tell us
what you think!
Works without any problems here.
- martin
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http
[PLEASE TEST] Maven 2.0.10-RC9
Hi everyone, As you're probably aware, we've been working for some time to stabilize Maven for the 2.0.10 release. After quite a bit of testing in the development community - and 8 release candidates - it looks like we finally have a candidate that is free of regressions and stable. You can download it here: http://people.apache.org/~jdcasey/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9 While it does seem that all of our builds are happy with the new release candidate, we'd like to get your feedback on it before we finalize things. This will help us respond to any regressions or critical issues we may have missed BEFORE we do the release, instead of having to put up with major flaws for another release cycle. Please, if you have the time, take 2.0.10-RC9 for a spin and tell us what you think! Thanks, -john P.S. To see the list of issues that were closed for this release (so far), check out: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Launching a Java application from Maven (vs. Ant)
Maven does make the development process simpler in many ways, but it's a
mistake to think that every possible activity in that process will be
simpler. Obviously, the power Maven brings in terms of dependency
handling, standardized lifecycles and lifecycle vocabulary, etc. will be
completely irrelevant for this use case.
-john
Trevor Harmon wrote:
Hi all,
I'm an experienced Ant user but new to Maven, and I'm a little shocked
at how verbose Maven is, even compared to Ant, which is notorious for
its verbosity. For example, if I want to launch a Java application in
Ant, I do this:
target name=run
java classname=foo.Bar classpath=${my.classpath}
sysproperty key=mykey value=myvalue/
arg value=-h/
/java
/target
These six lines of Ant explode into 27 lines when ported to Maven:
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
goals
goaljava/goal
/goals
/execution
/executions
configuration
mainClassfoo.Bar/mainClass
arguments
argument-h/argument
/arguments
systemProperties
systemProperty
keymykey/key
valuemyvalue/value
/systemProperty
/systemProperties
/configuration
/plugin
/plugins
/build
Plus, when I want to run the Ant task, I only have to type this:
# ant run
But in Maven I have to type all this:
# mvn org.codehaus.mojo:exec-maven-plugin:java
Everything about Maven seems more complex, more verbose, and more
difficult, at least for this example. Am I missing something? I thought
Maven was supposed to make things simpler...
Trevor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Launching a Java application from Maven (vs. Ant)
BTW, unless I'm misataken, the following invocation should also work:
mvn exec:java
-j
Trevor Harmon wrote:
Hi all,
I'm an experienced Ant user but new to Maven, and I'm a little shocked
at how verbose Maven is, even compared to Ant, which is notorious for
its verbosity. For example, if I want to launch a Java application in
Ant, I do this:
target name=run
java classname=foo.Bar classpath=${my.classpath}
sysproperty key=mykey value=myvalue/
arg value=-h/
/java
/target
These six lines of Ant explode into 27 lines when ported to Maven:
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
goals
goaljava/goal
/goals
/execution
/executions
configuration
mainClassfoo.Bar/mainClass
arguments
argument-h/argument
/arguments
systemProperties
systemProperty
keymykey/key
valuemyvalue/value
/systemProperty
/systemProperties
/configuration
/plugin
/plugins
/build
Plus, when I want to run the Ant task, I only have to type this:
# ant run
But in Maven I have to type all this:
# mvn org.codehaus.mojo:exec-maven-plugin:java
Everything about Maven seems more complex, more verbose, and more
difficult, at least for this example. Am I missing something? I thought
Maven was supposed to make things simpler...
Trevor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC9
DOH! Wrong URL. Here's the right one: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9/ That's what I get for trying to type it in cold instead of looking it up in FF and copying... :-( Sorry for the confusion, -john Aaron Metzger wrote: John Casey wrote: Hi everyone, As you're probably aware, we've been working for some time to stabilize Maven for the 2.0.10 release. After quite a bit of testing in the development community - and 8 release candidates - it looks like we finally have a candidate that is free of regressions and stable. You can download it here: http://people.apache.org/~jdcasey/apache-maven/2.0.10-RC9/org/apache/maven/apache-maven/2.0.10-RC9 When will that URL be valid? Is the snapshot under maven-drops the same thing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.0.10-RC4
Hi everyone, Awhile ago, I mentioned that we were starting the process of putting together the 2.0.10 release of Maven. We've already been through a series of three release candidates that gave us the opportunity to iron out the worst wrinkles, and now I believe we have a release candidate that's ready for some more abuse. Please, if you have time, take 2.0.10-RC4 for a spin on your own builds, and let us know if anything comes up broken compared to, say, 2.0.9. We're filing any and all bugs we find in these release candidates in JIRA (http://jira.codehaus.org/browse/MNG) and closing them against the 2.0.10 release as we get them fixed. You can download the binaries here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC4/org/apache/maven/apache-maven/2.0.10-RC4 Also, you can see the release notes (so far) for 2.0.10 here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112 Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.0.10-RC4
Hi again, Please disregard this message. It was sent prematurely, before I'd seen that some regressions have been found. We'll try this again once we can be more certain that the regressions are cleared. Thanks for your patience, -john John Casey wrote: Hi everyone, Awhile ago, I mentioned that we were starting the process of putting together the 2.0.10 release of Maven. We've already been through a series of three release candidates that gave us the opportunity to iron out the worst wrinkles, and now I believe we have a release candidate that's ready for some more abuse. Please, if you have time, take 2.0.10-RC4 for a spin on your own builds, and let us know if anything comes up broken compared to, say, 2.0.9. We're filing any and all bugs we find in these release candidates in JIRA (http://jira.codehaus.org/browse/MNG) and closing them against the 2.0.10 release as we get them fixed. You can download the binaries here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC4/org/apache/maven/apache-maven/2.0.10-RC4 Also, you can see the release notes (so far) for 2.0.10 here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112 Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
COMING SOON: Maven 2.0.10 Release Candidate
Hi everyone, I just wanted to send a short message to say that we're going to start the release process for Maven 2.0.10 today. The list of issues we've corrected for this release are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14112 Once we've reached a level of stability that we're comfortable among Maven developers, we'll announce that release candidate on this list. At this point, we'll be more comfortable saying this is what we intend to release, barring any new regressions found in the wider test. When it seems that everyone is happy and all builds are stabilized, we'll call the vote and keep things moving along. Hopefully this process won't take too long, as I've been throwing nearly every scenario at this version of Maven and feel pretty good about its stability even now. Thanks for hanging in there, and hopefully we'll have a new version ready for release in the near future! -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Iterating through the build based on activated profiles
You could always use multiple executions of the surefire plugin, one per test type, such that when more than one test profile is active the executions are additive, and cause the surefire plugin to execute more than once. Then, you could setup your database configuration using execution-level configuration blocks that pass in system properties via surefire. There may be a more elegant solution out there, but this should work relatively well... HTH, -john Balasubramanian, Ravi Shankar wrote: Hi all, I sent this earlier and can someone please tell me if there is any way to do this ? Thanks, Ravi Hi all, I am facing a situation where i need to iterate through (or build ) the same maven projects depending upon the list of active profiles. To be precise, we run some tests (testNG through the maven surefire plugin) against a database and i need a way to run the tests against different databases based on the list of active profiles or through some other mechanism. I tried having a seperate maven profile for each database type and pointing to a different properties file in each profile. But i still could not get to the point where i can iterate through the build (or run the tests) depending upon the list of active profiles. Precisely, i want to have a setup similar to the following: mvn -Pmysql test mvn -Poracle test - should run the tests against a mysql database and an oracle database respectively(which i could do ) mvn -Pmysql,oracle test - This should run the tests against both mysql and oracle for which i need a solution. Can somebody suggest something for this ? PS: I dont want to change the number of mvn commands that i issue. The build machine always runs mvn test once and we provide a list of active profiles depending on the requirement. Regards, Ravi -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Odd warning in assembly plugin
Nothing to be too concerned about. It's a warning more intended for plugin developers, meaning they passed in a jar artifact instead of a pom artifact, and the project-builder is constructing a pom artifact to build the project instance from instead. I just need to modify the assembly plugin to make sure it's passing in pom artifacts, but this shouldn't affect your assembly in any way. -john On Mon, Jun 30, 2008 at 5:17 PM, Kathryn Huxtable [EMAIL PROTECTED] wrote: I'm making an assembly for a project and one of its runtime dependencies is something called grouper. I'm getting the following warning: [WARNING] Attempting to build MavenProject instance for Artifact (edu.internet2.middleware.grouper:grouper:1.3.0) of type: jar; constructing POM artifact instead. Where should I be looking to fix this? I have control over the grouper pom. It is a jar. -K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: Odd warning in assembly plugin
You're saying that you only get that warning for one dependency out of a group of them you're working with, within the assembly process? -j On Mon, Jun 30, 2008 at 5:52 PM, Kathryn Huxtable [EMAIL PROTECTED] wrote: Great, but I don't get that warning for the other dependencies. Why not, I wonder? -K On Jun 30, 2008, at 4:21 PM, John Casey wrote: Nothing to be too concerned about. It's a warning more intended for plugin developers, meaning they passed in a jar artifact instead of a pom artifact, and the project-builder is constructing a pom artifact to build the project instance from instead. I just need to modify the assembly plugin to make sure it's passing in pom artifacts, but this shouldn't affect your assembly in any way. -john On Mon, Jun 30, 2008 at 5:17 PM, Kathryn Huxtable [EMAIL PROTECTED] wrote: I'm making an assembly for a project and one of its runtime dependencies is something called grouper. I'm getting the following warning: [WARNING] Attempting to build MavenProject instance for Artifact (edu.internet2.middleware.grouper:grouper:1.3.0) of type: jar; constructing POM artifact instead. Where should I be looking to fix this? I have control over the grouper pom. It is a jar. -K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: maven assembly bug MASSEMBLY-74
Please open a new issue in http://jira.codehaus.org/browse/MASSEMBLY and
attach a failing test project that I can use to verify the problem, and
I'll take a look.
Thanks,
-john
Julien Simon wrote:
Hi,
I'm having a problem when I try to create an assembly with a specified
MANIFEST.MF. I use the following configuration;
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
archive
manifestFile${basedir}/src/main/resources/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
The problem is that the file I specified is not used. It's exactly the
problem as described in this issue;
http://jira.codehaus.org/browse/MASSEMBLY-74.
When I'm using the fix version specified in the JIRA issue (2.1) everything
works fine. But when I'm using the latest version of the plugin (2.2-beta-2)
it does not work. I was wondering since 2.2-beta-2 is a higher version than
2.1 why the bug seems to remain?
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I compile my first maven project
It sounds like Maven is having a hard time accessing the network to download the plugins it needs to perform your build. Maybe you have a proxy that needs to be configured? If so, you might check out this page: http://maven.apache.org/guides/mini/guide-proxies.html Good luck, -john xserge wrote: I've created first maven project using next command mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app SUCCESSFULLY Now I'm trying to compile this project from folder my-app using command mvn compile and I received BUILD ERROR The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found Hello could anybody help me, that's wrong ? -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I run an Ant target in Maven?
You should be able to simply call the hibernatetool without a target.
IIRC, the antrun plugin may not support targets.
-john
youhaodeyi wrote:
I use Maven runant plugin to execute ant task, see below:
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
configuration
tasks
property name=output
value=target/classes /
taskdef name=hibernatetool
classname=org.hibernate.tool.ant.HibernateToolTask
/
target name=schema-recreate
hibernatetool
destdir=${output}
configuration
configurationfile=${output}/hibernate.cfg.xml /
hbm2ddl drop=true create=true
export=true update=false /
/hibernatetool
/target
/tasks
/configuration
/plugin
/plugins
/build
How can I run the target schema-recreate? I don't want o attach this into
any Maven lifecycle.
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly plugin with several descriptors
This is a fairly involved use case, but I'd suggest taking a slightly
different approach. First, split your plugin configuration into two
execution sections, instead of one...one per assembly descriptor. This
should allow you to set the finalName for your distro ZIP, but not the
plugin ZIP. Next, make sure the plugin assembly is built first, maybe by
specifying it as the first execution/ of the assembly plugin in your
POM (this should work), or by attaching it via phasetest/phase (if
it doesn't work).
So, when you build your plugin zip, it'll have a filename other than
what you want in your distro...like maybe myproduct-version-plugin.zip
or something. You can actually put this under a different name inside
your distro zip by adjusting the outputFileNameMapping (in
dependencySet/) or destName (in file/). When your distro assembly
descriptor executes, direct it to include the plugin's alternative
filename instead of the one you specified in the finalName.
As for the warning you're seeing in the log files, I'd need a little
more context from the log output to understand what's going on
there...I'd probably have to go look back at the source code to see
where it was coming from, if the logs didn't shed more light on it.
HTH,
-john
Dobri Kitipov wrote:
Hi all,
currently I am trying to execute an assembly that makes use of two
descriptors. I want to package a given artifact as a ZIP (i.e. my product
eclipse plugin) and then include it in an artifact (i.e. my product
distribution) that has a DIR and ZIP format set. The problem is that in the
first descriptor (D1) have ZIP format, but I have the same format into the
second descriptor (D2). As these two descriptors are specified to one given
assembly plugin they share one common finalName specified:
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
configuration
finalNamemyproduct-${myproduct.version}/finalName
appendAssemblyIdfalse/appendAssemblyId
descriptors
descriptortools/eclipse/D1.xml/descriptor
descriptorassembly/D2.xml/descriptor
/descriptors
/configuration
/plugin
This causes a problem because when the first artifact (A1) is crearted it
has the name myproduct-${myproduct.version}.zip, then this artifact is
overridden by the second artifact (A2) created by D2 execution that need to
include the A1.
So, my question is is it possible to use different names for A1 and A1 when
their descriptors are executed toggether?
Additionally I can read into the assembly log the following note:
NOTE: If multiple descriptors or descriptor-formats are provided for this
project, the value of this file will be non-deterministic!
What does it mean? Does it mean that the order of the invocation/execution
of the descriptors is non-deterministic? or what?
Thank you in advance
Dobri
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven-assembly-plugin
To change the format for the dependency artifacts, add something like the
following to the dependencySet:
outputFileNameMapping${artifact.artifactId}.${artifact.extension}/outputFileNameMapping
For other options to fine-tune your assembly configuration, see:
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html
-john
On Wed, Apr 16, 2008 at 10:32 AM, Krishnamurthi, Venkat
[EMAIL PROTECTED] wrote:
Hi,
I used the following assembly descriptor to create an assembly directory
with my project's jar and all the jars that are it's dependencies:
assembly
iddistribution/id
formats
formatdir/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directorytarget/directory
outputDirectory/outputDirectory
includes
include*.jar/include
/includes
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/lib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
However, all the jars that are copied inside lib/ had the version
numbers attached to them. Is there a way to filter out these version
numbers and just have the jars.
Also, if I want to create this assembly directory at a location outside
this projects's target directory, where do I specify that path.
Thanks and Regards,
Venkat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
Re: assembly:assembly failure
You need to specify idassembly-name/id inside your assembly
descriptors.
-john
On Apr 10, 2008, at 8:34 AM, Harper, Brad wrote:
Anyone have thoughts on what's behind the following error?
...
[ERROR] BUILD FAILURE
[INFO] --
[INFO] The assembly id null is used more than once.
...
I see this error when testing a garden-variety assembly from the
command
line
% mvn assembly:assembly -Ddescriptor=src/main/assembly/release.xml
-Ddocument.version=2.4.15
The assembly descriptor names only two files: the project's war
artifact
and a document, which references the property ${document.version}
to get
the correct file.
Brad Harper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: assembly:assembly failure
Yeah, it looks like we need to improve the validation of descriptors. None
of the assembly mojos should really work without an assembly id.
Would you mind filing an issue at:
http://jira.codehaus.org/browse/MASSEMBLY? That way, you can
watch/vote for the issue, and see when it gets
corrected.
Also, if you're binding the assembly plugin into your build lifecycle for a
project, you might want to consider using assembly:single, since it doesn't
force a forked execution of the project's build. It will be a little more
performant for you most likely.
-john
On Fri, Apr 11, 2008 at 12:44 PM, Harper, Brad [EMAIL PROTECTED]
wrote:
Ah, thanks.
I've since found that mvn assembly:attached works, both from the
command line and when run as part of a maven build lifecycle [with the
same assembly descriptor.]
Is the assembly id being inferred or derived from the project then, when
running the 'attached' goal?
I suggest that the error message be improved for this use case, at the
least. Since I've clearly not supplied an assembly id, it seems that
the message refers to multiple [internal] uses of the assembly id and
relates more to implementation of the plugin and less to something that
the user has knowledge of [and can control].
Thanks again.
Brad
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 10:36 AM
To: Maven Users List
Subject: Re: assembly:assembly failure
You need to specify idassembly-name/id inside your
assembly descriptors.
-john
On Apr 10, 2008, at 8:34 AM, Harper, Brad wrote:
Anyone have thoughts on what's behind the following error?
...
[ERROR] BUILD FAILURE
[INFO] --
[INFO] The assembly id null is used more than once.
...
I see this error when testing a garden-variety assembly from the
command line
% mvn assembly:assembly -Ddescriptor=src/main/assembly/release.xml
-Ddocument.version=2.4.15
The assembly descriptor names only two files: the project's war
artifact and a document, which references the property
${document.version} to get the correct file.
Brad Harper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
Re: [2.0.9 RC7] Release Candidate testing
switching to 2.0.9. This can happen because we started locking down versions in 2.0.9. This is so if you haven't specified a version in your poms, it won't change on you going forward. This means that you will get upgraded to the latest site plugin (2.0-beta-6) just like you would if you did mvn -U on your build. If you have trouble with site after using 2.0.9, try specifying maven-site-plugin 2.0-beta-5 in your pom (we recommend locking your versions anyway). This is preferable to locking 2.0.9 to beta-5 for everyone and potentially forcing some people's versions backwards. In the future, only the most stable versions will be locked in the super pom and usually this will not be the most recent release. Since 2.0.9 was the first time we did this, we had to go with the current versions as the baseline. RC7 is available for download here: http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/ Thank you for your assistance in testing the RCs. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- + Kaizer H. Sogiawala + - 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] -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: SV: [2.0.9 RC6] Release Candidate testing
: http://www.nabble.com/-Pre-Vote--release-maven-2.0.9- td16124759s177.html http://www.nabble.com/-pre-vote-take-3--2.0.9-RC3-td16314473s177.html http://www.nabble.com/-2.0.9-RC4--td16344067s177.html http://www.nabble.com/-2.0.9-RC5--td16365465s177.html#a16365465 [2] Creating a Core IT: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration +Test [3] http://jira.codehaus.org/browse/MNG Thanks, The Maven Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: TextMate Maven Bundle.
Cool, you don't by any chance support auto-completion of sections of the
pom, do you? I was thinking of something like the behavior of the '(' and
'{' characters, for things like plugin and execution (these are the ones
that I always mess up the end tags on, since they're
singular-followed-by-plural...like /execution\n/executions)
Nice to see someone working on this, though. I'm a big fan of TextMate. :-)
-john
On Mon, Mar 3, 2008 at 7:45 PM, Luke Daley [EMAIL PROTECTED] wrote:
Hi all,
A Maven bundle for the popular Mac OS text editor TextMate http://
macromates.com/ is now available from the central bundle repository
http://macromates.com/svn/Bundles/trunk/Bundles/Maven.tmbundle.
This bundle allows you to invoke Maven from within TextMate with a
few simple keystrokes. It also colorises mvn's output (one example
being the highlighting of test failure notices) which is surprisingly
handy. It also scopes key pom sections to allow you to navigate your
poms with ease.
I also have an APT bundle in the works http://macromates.com/svn/
Bundles/trunk/Review/Bundles/Almost%20Plain%20Text%20(APT).tmbundle
that makes writing APT documents significantly easier. If this
interests you, please be sure to give it a try and let me know of
issues and missing features.
Cheers,
LD.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
Re: add predefined descriptor for assembly plugin.
The best approach I've found for this is to create a new jar project that contains only the assembly descriptor in the directory: src/main/resources/assemblies/your-descriptor.xml Then, build/install this project so you have access to use the jar as a plugin-level dependency, like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version dependencies dependency groupIdsome.group.id/groupId artifactIdyour-assembly-descriptors/artifactId version1.0/version /dependency /dependencies executions execution idyour-assembly/id phasepackage/phase goals goalsingle/goal !-- more friendly to multimodule builds than assembly:assembly or assembly:attached -- /goals configuration descriptorRefs descriptorRefyour-descriptor/descriptorRef /descriptorRefs /configuration /execution /executions /plugin This will allow your assembly descriptor to be available for use in multiple project builds, as above. HTH, -john On Feb 28, 2008, at 3:18 PM, Benoit Decherf wrote: Hi, Some of our projects need to create a tgz with the same structure. I'd like to not have to copy the assembly descriptor on all projects. Is there a way to add a new predefined descriptor ? Or how should I do that ? Benoit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
