using jelly:util failure
Hi all, I have a little problem. I'm using jenkins for CI, and trying to send emails using email-ext-plugin by writing jelly script. I'm kind of new in jelly, so i'm stack for a day (!!!) because of an error in jelly:util tag, and have no idea how to progress from here. please help!!! I'm trying to check if some image-uri exist, and if so - add it to email: a short version of what i tried: j:jelly xmlns:j=jelly:core xmlns:st=jelly:stapler xmlns:d=jelly:define xmlns:util=jelly:util util:available uri=some-uri some-uri /util:available the email i get: JellyException: Could not parse Jelly script : null. What am i doing wrong? Thanks in advance, Odi -- View this message in context: http://maven.40175.n5.nabble.com/using-jelly-util-failure-tp5645947p5645947.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Question about Maven Assembly Plugin
Hi.
I am writing a little tutorial in my company about the use of the Maven
Assembly Plugin to build a executable jar, with all dependencies inside it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this warning:
[WARNING] Cannot include project artifact: com.company.class; it doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it has, but
no code of mine is added in the jar, and I get this output in command line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial ---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/maven/org.apache.httpcomponents/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/commons/ already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] Building jar:
D:\projetos\tutorial\target\tutorial-1.0-SNAPSHOT-jar-with-dependencies.jar
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/maven/org.apache.httpcomponents/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO]
Re: using jelly:util failure
Hi, I have a little problem. I'm using jenkins for CI, and trying to send emails using email-ext-plugin by writing jelly script. I'm kind of new in jelly, so i'm stack for a day (!!!) because of an error in jelly:util tag, and have no idea how to progress from here. please help!!! You'd better ask your questions on the Jenkins mailing lists: http://jenkins-ci.org/content/mailing-lists Regards Thorsten
Re: Question about Maven Assembly Plugin
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the Maven
Assembly Plugin to build a executable jar, with all dependencies inside it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this warning:
[WARNING] Cannot include project artifact: com.company.class; it doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it has, but
no code of mine is added in the jar, and I get this output in command line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial ---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/maven/org.apache.httpcomponents/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/commons/ already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] Building jar:
D:\projetos\tutorial\target\tutorial-1.0-SNAPSHOT-jar-with-dependencies.jar
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/
Selective Parallel Builds with maven 3
Greetings Everyone, I'm trying to build my project in parallel using Maven 3, so I can reduce the time taken (Currently it takes around better half of a day to completely build it). May be this sounds stupid, but the way I want to do is to build some of the modules in project serially while others in parallel. So ideally, when I do a 'mvn clean install', I want maven to parallel build parts of the project that are marked/configured for that and others sequentially. Is this possibe with current capabilities of maven 3? Thanks in advance, - Ramith Jayasinghe - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
What good is checkModificationExcludeList for release:prepare?
I'm using the release plugin for tagging and branching on CVS projects. Certain user-specific property files should not be taggeg nor branched, so I defined checkModificationExcludeList for the release plugin. This passes the first modification check well, but when it comes to tagging by scm plugin, maven produces an error Provider message: The cvs tag command failed. Command output: cvs tag: developer.properties is locally modified cvs [tag aborted]: correct the above errors first! at org.apache.maven.lifecycle.internal.MojoExecutor.execute( MojoExecutor.java:213) So am I doing anything wrong or ist the ignore-option useless in combination with tagging/branching? Can anyone explain the sense of this option? Kind regards Frank
org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact - when using mvn 3.0.4 (works with mvn 3.0.3!)
Hello, With some multi-module maven project we'r having the following exception when using maven 3.0.4: [ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:1.3.2.google:resources (default) on project genericapi: Execution default of goal org.codehaus.mojo:gwt-maven-plugin:1.3.2.google:resources failed: Plugin org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its dependencies could not be resolved: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:1.3.2.google:resources (default) on project genericapi: Execution default of goal org.codehaus.mojo:gwt-maven-plugin:1.3.2.google:resources failed: Plugin org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its dependencies could not be resolved: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:gwt-maven-plugin:1.3.2.google:resources failed: Plugin org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its dependencies could not be resolved: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:82) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginResolutionException: Plugin org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its dependencies could not be resolved: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:215) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.createPluginRealm(DefaultMavenPluginManager.java:353) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupPluginRealm(DefaultMavenPluginManager.java:321) at org.apache.maven.plugin.DefaultBuildPluginManager.getPluginRealm(DefaultBuildPluginManager.java:175) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:78) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:358) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:207) ... 24 more Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact dom4j:dom4j:jar:1.6.1 in gwt-plugin-repo (http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven) at
The Maven Way
Hi list, a simple question with (hopefully) a simple answer: Is there some coherent documentation of the Maven way? I'm *not* looking for: * documentation of the Maven syntax * documentation of Maven plugins * Maven reference documentation * Use the Source, Luke! style of advice What I'm looking for is: * a collection of patterns / anti-patterns in the use of Maven, * documentation on the Do's and Dont's when using Maven, * documentation of the best practices implemented by Maven, * documentation of basic assumptions in Maven. I'm being bitten by gotcha's that spring up at inconvenient times and *then* being told that I've strayed from The Way; I'd rather follow some road signs upfront than find myself confronted with scathing dogs in some lonely backyard that I happen to stumble into. Something along the lines of Chapter 3.6 of Maven: The Complete Reference, which sets out to ... distill some of this knowledge to help you adopt best practices from the start without having to wade through years of discussions ... but then, unfortunately, only covers two (Dependency Grouping and Multi-module vs. Inheritance). Similar to this, just much more complete and with some background/rationale thrown in, if possible. Pointers anyone? Pretty please? Regards, Wolf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Hi, I recommend two books from Sonatype, Maven by Example 1) and Maven Cookbook 2) 1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example 2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook Markku On 17.4.2012 16:55, Wolf Geldmacher wrote: Hi list, a simple question with (hopefully) a simple answer: Is there some coherent documentation of the Maven way? I'm *not* looking for: * documentation of the Maven syntax * documentation of Maven plugins * Maven reference documentation * Use the Source, Luke! style of advice What I'm looking for is: * a collection of patterns / anti-patterns in the use of Maven, * documentation on the Do's and Dont's when using Maven, * documentation of the best practices implemented by Maven, * documentation of basic assumptions in Maven. I'm being bitten by gotcha's that spring up at inconvenient times and *then* being told that I've strayed from The Way; I'd rather follow some road signs upfront than find myself confronted with scathing dogs in some lonely backyard that I happen to stumble into. Something along the lines of Chapter 3.6 of Maven: The Complete Reference, which sets out to ... distill some of this knowledge to help you adopt best practices from the start without having to wade through years of discussions ... but then, unfortunately, only covers two (Dependency Grouping and Multi-module vs. Inheritance). Similar to this, just much more complete and with some background/rationale thrown in, if possible. Pointers anyone? Pretty please? Regards, Wolf - 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
jarsigner plugin - An API incompatibility was encountered while executing org.apache.maven.plugins:maven-jarsigner-plugi
I'm not able to create signed jar files using jarsigner:1.2 plugin. I'm getting the below exception [INFO] BUILD FAILURE [INFO] [INFO] Total time: 13.788s [INFO] Finished at: Tue Apr 17 15:52:27 CEST 2012 [INFO] Final Memory: 11M/460M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (sign) on project sampleArtifact: Execution sign of goal org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.setWorkingDirectory(Ljava/io/File;)V - realm =pluginorg.apache.maven.plugins:maven-jarsigner-plugin:1.2 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy urls[0] = file:/home/xx/.m2/repository/org/apache/maven/plugins/maven-jarsigner-plugin/1.2/maven-jarsigner-plugin-1.2.jar urls[1] = file:/home/xx/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar Number of foreign imports: 4 import: Entry[import org.codehaus.plexus.util.xml.pull.XmlSerializer from realm ClassRealm[plexus.core, parent: null]] import: Entry[import org.codehaus.plexus.util.xml.pull.XmlPullParserException from realm ClassRealm[plexus.core, parent: null]] import: Entry[import org.codehaus.plexus.util.xml.pull.XmlPullParser from realm ClassRealm[plexus.core, parent: null]] import: Entry[import org.codehaus.plexus.util.xml.Xpp3Dom from realm ClassRealm[plexus.core, parent: null]] Number of parent imports: 20 import: Entry[import org.codehaus.plexus.personality from realm null] import: Entry[import org.codehaus.plexus.logging from realm null] import: Entry[import org.codehaus.plexus.lifecycle from realm null] import: Entry[import org.codehaus.plexus.context from realm null] import: Entry[import org.codehaus.plexus.container from realm null] import: Entry[import org.codehaus.plexus.configuration from realm null] import: Entry[import org.codehaus.plexus.component from realm null] import: Entry[import org.codehaus.plexus.classworlds from realm null] import: Entry[import org.codehaus.plexus.PlexusContainerException from realm null] import: Entry[import org.codehaus.plexus.PlexusContainer from realm null] import: Entry[import org.codehaus.plexus.PlexusConstants from realm null] import: Entry[import org.codehaus.plexus.MutablePlexusContainer from realm null] import: Entry[import org.codehaus.plexus.DuplicateChildContainerException from realm null] import: Entry[import org.codehaus.plexus.DefaultPlexusContainer from realm null] import: Entry[import org.codehaus.plexus.DefaultContainerConfiguration from realm null] import: Entry[import org.codehaus.plexus.DefaultComponentRegistry from realm null] import: Entry[import org.codehaus.plexus.ContainerConfiguration from realm null] import: Entry[import org.codehaus.plexus.ComponentRegistry from realm null] import: Entry[import org.codehaus.classworlds from realm null] import: Entry[import org.apache.maven from realm null] realm =plexus.core strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy urls[0] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/maven-core-3.0-SNAPSHOT.jar urls[1] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/maven-compat-3.0-SNAPSHOT.jar urls[2] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/xbean-reflect-3.4.jar urls[3] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/maven-settings-3.0-SNAPSHOT.jar urls[4] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/wagon-file-1.0-beta-6.jar urls[5] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/log4j-1.2.12.jar urls[6] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/wagon-http-jetty-client-1.0-SNAPSHOT.jar urls[7] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/plexus-sec-dispatcher-1.3.jar urls[8] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/jetty-util-7.0.0.v20091005.jar urls[9] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/wagon-provider-api-1.0-beta-6.jar urls[10] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/maven-model-3.0-SNAPSHOT.jar urls[11] = file:/home/x/eclipse/plugins/org.maven.ide.eclipse.maven_embedder_0.10.2.20100623-1649/jars/plexus-component-annotations-1.5.4.jar urls[12] =
Re: The Maven Way
I also recommend taking the Sonatype training courses - especially if you are a software architect. There is a lot to be said when you can ask question as the instructor is going over the material. However, you are right, if someone were to write a book called the The Maven Way in the style you suggest, I would certainly be interested in buying a copy. Cheers, Eric On 2012-04-17 7:00 AM, Markku Saarela wrote: Hi, I recommend two books from Sonatype, Maven by Example 1) and Maven Cookbook 2) 1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example 2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook Markku On 17.4.2012 16:55, Wolf Geldmacher wrote: Hi list, a simple question with (hopefully) a simple answer: Is there some coherent documentation of the Maven way? I'm *not* looking for: * documentation of the Maven syntax * documentation of Maven plugins * Maven reference documentation * Use the Source, Luke! style of advice What I'm looking for is: * a collection of patterns / anti-patterns in the use of Maven, * documentation on the Do's and Dont's when using Maven, * documentation of the best practices implemented by Maven, * documentation of basic assumptions in Maven. I'm being bitten by gotcha's that spring up at inconvenient times and *then* being told that I've strayed from The Way; I'd rather follow some road signs upfront than find myself confronted with scathing dogs in some lonely backyard that I happen to stumble into. Something along the lines of Chapter 3.6 of Maven: The Complete Reference, which sets out to ... distill some of this knowledge to help you adopt best practices from the start without having to wade through years of discussions ... but then, unfortunately, only covers two (Dependency Grouping and Multi-module vs. Inheritance). Similar to this, just much more complete and with some background/rationale thrown in, if possible. Pointers anyone? Pretty please? Regards, Wolf - 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: Selective Parallel Builds with maven 3
Wow! Half a day sounds like a huge code base! Anyways, yes you can do this in Maven 3 but maven takes the call on how the modules get build. You can enforce a build order among modules using dependencies (if A depends on B, maven will build B before A) but I'm not aware of any other ways to enforce the order. Another notable point is to check if your plugins are compatible with parallel builds - either check their documentation or simply build with -T N option and watch for warnings (N is the number of threads to build in parallel). Regards, Srinath. On Tue, Apr 17, 2012 at 5:04 PM, Ramith Jayasinghe ramithro...@yahoo.comwrote: Greetings Everyone, I'm trying to build my project in parallel using Maven 3, so I can reduce the time taken (Currently it takes around better half of a day to completely build it). May be this sounds stupid, but the way I want to do is to build some of the modules in project serially while others in parallel. So ideally, when I do a 'mvn clean install', I want maven to parallel build parts of the project that are marked/configured for that and others sequentially. Is this possibe with current capabilities of maven 3? Thanks in advance, - Ramith Jayasinghe - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Selective Parallel Builds with maven 3
Out of interest... How many modules is that? How many java files? Any code generation happening like XMLBeans etc? Also does that half day include or exclude test execution time? I worked somewhere, where the build was 3 hours not including tests, by simply upgrading from maven 2.x to 3 and splitting some of the code into smaller modules I managed to drop the build to 20 minutes. Compiling 10 modules each with 200 java files is much quicker than compiling 2,000 java files at once. On 17 April 2012 15:24, Srinath C srinat...@gmail.com wrote: Wow! Half a day sounds like a huge code base! Anyways, yes you can do this in Maven 3 but maven takes the call on how the modules get build. You can enforce a build order among modules using dependencies (if A depends on B, maven will build B before A) but I'm not aware of any other ways to enforce the order. Another notable point is to check if your plugins are compatible with parallel builds - either check their documentation or simply build with -T N option and watch for warnings (N is the number of threads to build in parallel). Regards, Srinath. On Tue, Apr 17, 2012 at 5:04 PM, Ramith Jayasinghe ramithro...@yahoo.comwrote: Greetings Everyone, I'm trying to build my project in parallel using Maven 3, so I can reduce the time taken (Currently it takes around better half of a day to completely build it). May be this sounds stupid, but the way I want to do is to build some of the modules in project serially while others in parallel. So ideally, when I do a 'mvn clean install', I want maven to parallel build parts of the project that are marked/configured for that and others sequentially. Is this possibe with current capabilities of maven 3? Thanks in advance, - Ramith Jayasinghe - 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
mvn release:perform java.lang.OutOfMemoryError: Java heap space
Team : We are facing the following error during the mvn release:perform process. Please help me in this. [INFO] [ERROR] Java heap space - [Help 1] [INFO] java.lang.OutOfMemoryError: Java heap space [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) [INFO] at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) [INFO] at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163) [INFO] at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:825) [INFO] at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:465) [INFO] at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:278) [INFO] at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215) [INFO] at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:480) [INFO] at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) [INFO] at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:156) [INFO] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Thanks PurnachandraRao. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
RE: JRE as mavne artifact
Our build has a dependency on the JRE. In order to build our final distribution artifact, we need a JRE. To me, this means that the JRE should be managed as a maven artifact in nexus. Otherwise, I don't understand the use case. Please describe it in more detail. My installer is more for our people to build appliance boxes that contain our technological solution. So, we are actually trying to install the whole thing. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-nar-plugin -- building libraries for both 32 64 Linux
Ping... :-)
Any help with this would be greatly appreciated and prevent me from having to
revert to using Ant.
Thanks in advance!!!
Dave Wolf
-Original Message-
From: Dave Wolf
Sent: Mon 4/16/2012 2:41 PM
To: users@maven.apache.org
Subject: maven-nar-plugin -- building libraries for both 32 64 Linux
Hi,
From reading the documentation, I'm not quite following how to tell the
maven-nar-plugin to generate both 32 64 versions of my project's artifacts.
I'm running on a 64 bit Linux system, so it is successfully generating
amd64.Linux.g++ artifacts. How can I cause it to build for not only the
current build platform, but also i386-Linux-g++?
One of pom files looks like this:
?xml version=1.0 encoding=UTF-8?
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;
modelVersion4.0.0/modelVersion
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-api/artifactId
packagingnar/packaging
parent
groupIdcom.mycompany/groupId
artifactIdsecurityservices-cpp/artifactId
version${component.version}/version
/parent
dependencies
dependency
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-validator/artifactId
version${component.version}/version
typenar/type
/dependency
/dependencies
build
plugins
plugin
groupIdnet.mjahn/groupId
artifactIdmaven-nar-plugin/artifactId
version${maven-nar-plugin.version}/version
extensionstrue/extensions
configuration
libraries
library
typeshared/type
/library
/libraries
/configuration
/plugin
/plugins
/build
/project
Thanks in advance!
Dave Wolf
This electronic communication and any attachments may contain confidential and
proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient, or an
agent or employee
responsible for delivering this communication to the intended recipient, or if
you have received
this communication in error, please do not print, copy, retransmit, disseminate
or
otherwise use the information. Please indicate to the sender that you have
received this
communication in error, and delete the copy you received. DigitalGlobe reserves
the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
Re: maven-nar-plugin -- building libraries for both 32 64 Linux
From reading the documentation, I'm not quite following how to tell the maven-nar-plugin to generate both 32 64 versions of my project's As far as I know, this plugin is not published by Apache but rather supported by the FreeHEP team or possibly Sonatype (??): http://java.freehep.org/freehep-nar-plugin/mail-lists.html https://issues.sonatype.org/browse/NAR plugin groupIdnet.mjahn/groupId artifactIdmaven-nar-plugin/artifactId Looks like you are running Mirko's fork of the plugin. Perhaps you should ask him for support? :) https://github.com/mirkojahn/maven-nar-plugin Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote: I also recommend taking the Sonatype training courses - especially if you are a software architect. There is a lot to be said when you can ask question as the instructor is going over the material. However, you are right, if someone were to write a book called the The Maven Way in the style you suggest, I would certainly be interested in buying a copy. You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu What is obvious to A may be not so obvious to B and downright ridiculous to C. -- Asimov pgpJVZfMzjjAu.pgp Description: PGP signature
RE: maven-nar-plugin -- building libraries for both 32 64 Linux
Will do. Thanks, I thought the GroupId was odd for a Sonotype plugin. I must have followed the wrong Google link somewhere along the way. Dave Wolf Java Architect Gorilla Logic M: 303-956-9106 DG GL Room: x4545 -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Tue 4/17/2012 10:04 AM To: Maven Users List Subject: Re: maven-nar-plugin -- building libraries for both 32 64 Linux From reading the documentation, I'm not quite following how to tell the maven-nar-plugin to generate both 32 64 versions of my project's As far as I know, this plugin is not published by Apache but rather supported by the FreeHEP team or possibly Sonatype (??): http://java.freehep.org/freehep-nar-plugin/mail-lists.html https://issues.sonatype.org/browse/NAR plugin groupIdnet.mjahn/groupId artifactIdmaven-nar-plugin/artifactId Looks like you are running Mirko's fork of the plugin. Perhaps you should ask him for support? :) https://github.com/mirkojahn/maven-nar-plugin Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives.
Re: mvn release:perform java.lang.OutOfMemoryError: Java heap space
Hi PurnachandraRao, [INFO] [ERROR] Java heap space - [Help 1] [INFO] java.lang.OutOfMemoryError: Java heap space Did you try increasing max heap size with the MAVEN_OPTS environment variable? Something like: export MAVEN_OPTS=-Xmx1536m Regards, Curtis On Tue, Apr 17, 2012 at 10:03 AM, Bobbepalli, Purnachandrarao purnachandrarao.bobbepa...@chase.com wrote: Team : We are facing the following error during the mvn release:perform process. Please help me in this. [INFO] [ERROR] Java heap space - [Help 1] [INFO] java.lang.OutOfMemoryError: Java heap space [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) [INFO] at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) [INFO] at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163) [INFO] at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:825) [INFO] at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:465) [INFO] at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:278) [INFO] at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215) [INFO] at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:480) [INFO] at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) [INFO] at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:156) [INFO] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) [INFO] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) [INFO] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) [INFO] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Thanks PurnachandraRao. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: Parameterizing the SCM settings...
You've hit https://jira.codehaus.org/browse/MRELEASE-128
It has been fixed and will be part of the next release.
Robert
Op Mon, 16 Apr 2012 23:31:11 +0200 schreef Jeff predato...@gmail.com:
I'm trying to share the SCM settings, primarly the SCM root URL, but
when I
perform a release, the parameters are changed to explicit values,
defeating
the purpose. Is there any way to make it not do that?
For example, during the release process, the following:
scm
connectionscm:svn:${scm.root}/${project.artifactId}/connection
developerConnectionscm:svn:${scm.root}/${project.artifactId}/developerConnection
url${scm.root}/${project.artifactId}/url
/scm
Changes into:
scm
connectionscm:svn:http://svn:8083/MyTeam/ParentPom/connection
developerConnectionscm:svn:http://svn:8083/MyTeam/ParentPom
/developerConnection
urlhttp://svn:8083/MyTeam/ParentPom/url
/scm
If it didn't change, then I could keep the parameterized version in the
ParentPOM and all children would work. But out of the box, this won't
work.
Can the SCM section be parameterized/shared?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven in an unconventional way. After all, the beauty of convention over configuration is that you *can* configure and override behavior as needed. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? I think one major difficulty is that as Maven develops, there is an evolving vision and understanding of what works well and what doesn't. And that is OK, and will continue to be the case. That said, someone could probably make some good money writing a book about the current vision and understanding, as well as updating it with new editions over time. :-) Regards, Curtis On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood mw...@iupui.edu wrote: On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote: I also recommend taking the Sonatype training courses - especially if you are a software architect. There is a lot to be said when you can ask question as the instructor is going over the material. However, you are right, if someone were to write a book called the The Maven Way in the style you suggest, I would certainly be interested in buying a copy. You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu What is obvious to A may be not so obvious to B and downright ridiculous to C. -- Asimov
Re: The Maven Way
On 17 April 2012 09:48, Curtis Rueden ctrue...@wisc.edu wrote: Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven in an unconventional way. After all, the beauty of convention over configuration is that you *can* configure and override behavior as needed. Hear, hear! Thank you Curtis, I've been meaning to respond to one of those Don't Fight Maven statements for a long time. I completely agree with you. The world isn't black-and-white, there's lots of grey ... and, *shudder*, even colour! ;-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What good is checkModificationExcludeList for release:prepare?
Hi, How did you define checkModificationExcludeList? -Robert Op Tue, 17 Apr 2012 15:18:09 +0200 schreef frank.ja...@tolina.de: I'm using the release plugin for tagging and branching on CVS projects. Certain user-specific property files should not be taggeg nor branched, so I defined checkModificationExcludeList for the release plugin. This passes the first modification check well, but when it comes to tagging by scm plugin, maven produces an error Provider message: The cvs tag command failed. Command output: cvs tag: developer.properties is locally modified cvs [tag aborted]: correct the above errors first! at org.apache.maven.lifecycle.internal.MojoExecutor.execute( MojoExecutor.java:213) So am I doing anything wrong or ist the ignore-option useless in combination with tagging/branching? Can anyone explain the sense of this option? Kind regards Frank - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The Maven Way
You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? Interestingly, I just wrote a detailed blog entry about the irony of a CoC tool with a body of documentation that documents the configuration rather than the conventions. It's kind of darkly humorous if you think about it. The configuration is the way to get in trouble with maven, but it's the only thing documented. In case you're interested: http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but-maven-docs-do.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The Maven Way
Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds I would have to disagree here. For instance, writing your own plugins is a horrible idea unless you are very, very, very wise maven user. The problem is that the docs talk a lot about how it's a plugin architecture and how you can write your own mojo's. I've just dealt with a project where they wrote their own mojo's for a bunch of stuff that was already provided by other existing plugins. The documentation should emphasize the existing body of plugins and provide a guide to the most useful of those and BURY the concept of writing your own. I think the whole notion of configuring or customizing maven in any way is a very tricky issue. It's front page on the docs, but it's the kind of thing that would best be put in Chapter 19 of a long book that covered all of the standard stuff before even broaching the topic. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The Maven Way
Good read. Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone. The guys at Sonatype have done a good job of posting various blogs. If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc. I think it says something that it has not been done yet. While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen. It is more of a very nice to have than a hard and fast requirement. -Original Message- From: chad.da...@emc.com [mailto:chad.da...@emc.com] Sent: Tuesday, April 17, 2012 2:32 PM To: users@maven.apache.org Subject: RE: The Maven Way You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? Interestingly, I just wrote a detailed blog entry about the irony of a CoC tool with a body of documentation that documents the configuration rather than the conventions. It's kind of darkly humorous if you think about it. The configuration is the way to get in trouble with maven, but it's the only thing documented. In case you're interested: http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but- maven-docs-do.html - 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: The Maven Way
Good read. Thanks. I think it says something that it has not been done yet. While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen. It is more of a very nice to have than a hard and fast requirement. I'm tackling the topic on my blog in upcoming weeks. The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
As the most frequent author of the 2 comments mentioned below, I will agree and disagree with Curtis' observations. He is right that Maven is very powerful and flexible. It is possible to make it do all kinds of interesting and useful things. However, it is also very easy when starting with Maven, to get into patterns based on experience with previous build tools, that make simple tasks much more difficult. It frequently appears from the person's statement that they are just starting with Maven and from the brief description of their problem that they are building a fairly common type of application that can be built very easily by Maven with a relatively simple POM and project structure. However, they have gotten off on the wrong foot and are trying to bend Maven to their will or as Curtis might say exploit the full power and flexibility of Maven. I usually quote the offending phrases around fighting Maven and profiles are evil in an attempt to get them to reexamine their strategy and see if their project does follow one of the more common patterns (webapp, standalone executable, etc.) that Maven can handle very simply. I will admit that I am not often the source of detailed technical information in these cases since I do not usually know how to do what they are doing and I am also pretty suspicious that the help that they want is not in their best interest. One of the dangers in this forum is that there are bunch of guys here who are very, very smart and very knowledgeable about Maven and can patch up a really bad Maven approach into something that will work. If you ask the wrong question, you may get the right answer which will help you get further out of your depth. One of the problems with documentation is that it often describes everything that you can do without pointing out that some of these things should only be used in rare circumstances and should only be considered after you have exhausted the normal features and patterns. Sometimes the examples demonstrate the power of the feature rather than the most common use which is considered to be too simple to be worth showing and does not show the full elegnce of the feature. Another problem that new users face is the reluctance to make big changes in their project structures or development methodology until they are sure that Maven is the way to go. This is understandable and my goal is to get them to understand that a little up front investment in conforming to convention may generate a short-term return when compared to trying to get a build process in place that follows their existing practice. I hope that my comments also give a sense of optimism that what they want to do is possible with Maven and that the forum is here to help them. Ron On 17/04/2012 12:48 PM, Curtis Rueden wrote: Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven in an unconventional way. After all, the beauty of convention over configuration is that you *can* configure and override behavior as needed. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? I think one major difficulty is that as Maven develops, there is an evolving vision
RE: The Maven Way
I'm tackling the topic on my blog in upcoming weeks. The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc. Good stuff sir. I tip my hat to you. I am wondering if it would be useful to put your work on a more official central maven location? Blogs are great but they tend to reflect the views of a single individual. We almost need some kind of official maven wiki where we can add things and have a few volunteers that could vet. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On 17/04/2012 2:37 PM, chad.da...@emc.com wrote: Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds I would have to disagree here. For instance, writing your own plugins is a horrible idea unless you are very, very, very wise maven user. The problem is that the docs talk a lot about how it's a plugin architecture and how you can write your own mojo's. I've just dealt with a project where they wrote their own mojo's for a bunch of stuff that was already provided by other existing plugins. The documentation should emphasize the existing body of plugins and provide a guide to the most useful of those and BURY the concept of writing your own. I think the whole notion of configuring or customizing maven in any way is a very tricky issue. It's front page on the docs, but it's the kind of thing that would best be put in Chapter 19 of a long book that covered all of the standard stuff before even broaching the topic. Very well put. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On 17/04/2012 2:47 PM, chad.da...@emc.com wrote: Good read. Thanks. I think it says something that it has not been done yet. While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen. It is more of a very nice to have than a hard and fast requirement. I'm tackling the topic on my blog in upcoming weeks. The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc. This would be good to add to the Maven site. It is the kind of information that is lacking. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-nar-plugin -- building libraries for both 32 64 Linux
Hi Dave,
From reading the documentation, I'm not quite following how to tell the
maven-nar-plugin to generate both 32 64 versions of my project's
artifacts.
The ImageJ2 project uses the maven-nar-plugin to build a cross-platform
launcher for our Java application.
We use gcc to build on Windows, Mac OS X and Linux, in 32-bit and 64-bit
modes.
Here is our POM:
https://github.com/imagej/imagej/blob/master/core/launcher/pom.xml
We use the duns version of the plugin, forked to the scijava organization:
https://github.com/scijava/maven-nar-plugin
Since the plugin is not deployed to any other public repository (that I
know of), we have deployed the snapshot version at:
http://maven.imagej.net/content/repositories/snapshots/org/apache/maven/plugins/maven-nar-plugin/
We have also made an interim release of the plugin and deployed it to:
http://maven.imagej.net/content/repositories/thirdparty/org/apache/maven/plugins/maven-nar-plugin/
We use Jenkins to do the build, with a separate profile for each
architecture. You can read a detailed description of how to configure
things here:
http://trac.imagej.net/ticket/832#comment:11
You are welcome to use either of these versions if they suit your needs.
Also feel free to pilfer from the POM if it helps your project!
Isn't open source grand? :-)
Regards,
Curtis
On Mon, Apr 16, 2012 at 3:41 PM, Dave Wolf dw...@digitalglobe.com wrote:
Hi,
From reading the documentation, I'm not quite following how to tell the
maven-nar-plugin to generate both 32 64 versions of my project's
artifacts. I'm running on a 64 bit Linux system, so it is successfully
generating amd64.Linux.g++ artifacts. How can I cause it to build for not
only the current build platform, but also i386-Linux-g++?
One of pom files looks like this:
?xml version=1.0 encoding=UTF-8?
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;
modelVersion4.0.0/modelVersion
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-api/artifactId
packagingnar/packaging
parent
groupIdcom.mycompany/groupId
artifactIdsecurityservices-cpp/artifactId
version${component.version}/version
/parent
dependencies
dependency
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-validator/artifactId
version${component.version}/version
typenar/type
/dependency
/dependencies
build
plugins
plugin
groupIdnet.mjahn/groupId
artifactIdmaven-nar-plugin/artifactId
version${maven-nar-plugin.version}/version
extensionstrue/extensions
configuration
libraries
library
typeshared/type
/library
/libraries
/configuration
/plugin
/plugins
/build
/project
Thanks in advance!
Dave Wolf
This electronic communication and any attachments may contain confidential
and proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient,
or an agent or employee
responsible for delivering this communication to the intended recipient,
or if you have received
this communication in error, please do not print, copy, retransmit,
disseminate or
otherwise use the information. Please indicate to the sender that you have
received this
communication in error, and delete the copy you received. DigitalGlobe
reserves the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
Directory/filename substitution for consecutive property names
Hello, I am experiencing problems while using substitution feature while generating archetypes. Generally it works correctly except a case below: - ABC__param1param2__/__param3__ second and third param are not substituted. Instead, Maven complains that property '/' was not provided Thanks in advance for any hint. According to my investigation there are no special cases and it should work like this but apparently it doesn't. I'm using Archetype Plugin 2.2 and Maven 2.2.1 Martin -- View this message in context: http://maven.40175.n5.nabble.com/Directory-filename-substitution-for-consecutive-property-names-tp5647331p5647331.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[Archetype plugin] Using requiredProperty in module name, id
Hello,
My archetype-metadata.xml looks like this:
requiredProperties
requiredProperty key=aSystemType/
requiredProperty key=SystemType/
requiredProperty key=Entity/
requiredProperty key=Task/
/requiredProperties
fileSets
fileSet filtered=true encoding=UTF-8
directoryimpl/task/directory
includes
include**/*.project/include
/includes
/fileSet
...
/fileSets
modules
module id=ad${aSystemType}-bw
dir=impl/adapter/__aSystemType__/ad__aSystemType__-bw
name=ad${aSystemType}-bw
fileSets
fileSet encoding=UTF-8 filtered=true
directoryImpl/directory
includes
include**/*.folder/include
/includes
/fileSet
...
/module
I've found two issues:
- First, properties are not substituted in module id and name. I've seen
examples with ${rootArtfiactId} but in my case I need to interactively
provide module id and name.
- Second, dir/filename substitution doesn't work for modules. Only works
for resources in parent project, that are not part of any module.
I am using Maven 2.2.1 and Archetype plugin 2.2
Thanks for reply,
Martin
--
View this message in context:
http://maven.40175.n5.nabble.com/Archetype-plugin-Using-requiredProperty-in-module-name-id-tp5647367p5647367.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Need to pass munge directives to 'mvn site:site'
On 4/14/12 6:07 AM, Dennis Lundberg wrote:
Perhaps mvn site:site is having a problem because it is invoking mvn
compiler:compile rather than mvn compile? (mvn -X site:site seems to
suggest so).
mvn site:site invokes a goal on the site plugin
mvn site invokes a lifecycle phase
Try the latter and see if it works for you.
Read more about phases and goals here:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
Hi Dennis,
Thanks for your reply. After reading the above and experimenting, I
found that I could do mvn compile site, and this works, even though
mvn site fails. The former succeeds because, it seems to me, that the
compile phase overrides the default compiler:compile plugin/goal pair
('mvn compiler:compile' fails, as I mentioned above).
Is there a way to make a given phase like 'site' depend on another
phrase, like 'compile'? That would allow me to just type 'mvn site'
rather than 'mvn compile site'.
-Eugene
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-nar-plugin -- building libraries for both 32 64 Linux
Curtis,
Thank you! That solution works great! We're off and running now. Yes, open
source communities are grand.
Cheers,
Dave Wolf
Java Architect
Gorilla Logic
-Original Message-
From: ctrueden.w...@gmail.com on behalf of Curtis Rueden
Sent: Tue 4/17/2012 12:57 PM
To: Maven Users List
Subject: Re: maven-nar-plugin -- building libraries for both 32 64 Linux
Hi Dave,
From reading the documentation, I'm not quite following how to tell the
maven-nar-plugin to generate both 32 64 versions of my project's
artifacts.
The ImageJ2 project uses the maven-nar-plugin to build a cross-platform
launcher for our Java application.
We use gcc to build on Windows, Mac OS X and Linux, in 32-bit and 64-bit
modes.
Here is our POM:
https://github.com/imagej/imagej/blob/master/core/launcher/pom.xml
We use the duns version of the plugin, forked to the scijava organization:
https://github.com/scijava/maven-nar-plugin
Since the plugin is not deployed to any other public repository (that I
know of), we have deployed the snapshot version at:
http://maven.imagej.net/content/repositories/snapshots/org/apache/maven/plugins/maven-nar-plugin/
We have also made an interim release of the plugin and deployed it to:
http://maven.imagej.net/content/repositories/thirdparty/org/apache/maven/plugins/maven-nar-plugin/
We use Jenkins to do the build, with a separate profile for each
architecture. You can read a detailed description of how to configure
things here:
http://trac.imagej.net/ticket/832#comment:11
You are welcome to use either of these versions if they suit your needs.
Also feel free to pilfer from the POM if it helps your project!
Isn't open source grand? :-)
Regards,
Curtis
On Mon, Apr 16, 2012 at 3:41 PM, Dave Wolf dw...@digitalglobe.com wrote:
Hi,
From reading the documentation, I'm not quite following how to tell the
maven-nar-plugin to generate both 32 64 versions of my project's
artifacts. I'm running on a 64 bit Linux system, so it is successfully
generating amd64.Linux.g++ artifacts. How can I cause it to build for not
only the current build platform, but also i386-Linux-g++?
One of pom files looks like this:
?xml version=1.0 encoding=UTF-8?
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;
modelVersion4.0.0/modelVersion
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-api/artifactId
packagingnar/packaging
parent
groupIdcom.mycompany/groupId
artifactIdsecurityservices-cpp/artifactId
version${component.version}/version
/parent
dependencies
dependency
groupIdcom.mycompany/groupId
artifactIdcomponent-cpp-validator/artifactId
version${component.version}/version
typenar/type
/dependency
/dependencies
build
plugins
plugin
groupIdnet.mjahn/groupId
artifactIdmaven-nar-plugin/artifactId
version${maven-nar-plugin.version}/version
extensionstrue/extensions
configuration
libraries
library
typeshared/type
/library
/libraries
/configuration
/plugin
/plugins
/build
/project
Thanks in advance!
Dave Wolf
This electronic communication and any attachments may contain confidential
and proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient,
or an agent or employee
responsible for delivering this communication to the intended recipient,
or if you have received
this communication in error, please do not print, copy, retransmit,
disseminate or
otherwise use the information. Please indicate to the sender that you have
received this
communication in error, and delete the copy you received. DigitalGlobe
reserves the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
This electronic communication and any attachments may contain confidential and
proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient, or an
agent or employee
responsible for delivering this communication to the intended recipient, or if
you have received
this communication in error, please do not print, copy, retransmit, disseminate
or
otherwise use the information. Please indicate to the sender that you have
received this
communication in error, and delete the copy you received. DigitalGlobe reserves
the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
Re: release:prepare and :perform on separate computers
For the record, I ended recreating mvn release:perform with a shell script that accepts commandline parameters instead of the release.properties that Maven looks for. Regards, Daniel Serodio Daniel Serodio wrote: We have a Jenkins instance that I'd like to use to make releases, but because of our company's security policy, it can't access GitHub (our main git repo). We also have a git.intranet repo that pulls every commit from GitHub via a post-receive hook, and Jenkins pulls from git.intranet. What I'd like to do it run release:prepare from my computer (which can access GitHub normally), and release:perform from Jenkins. Is this feasible? Would you suggest a different setup? Thanks in advance, Daniel Serodio - 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
Assembly plugin plugin
I have written a ContainerDescriptorHandler plugin for the Maven assembly plugin. It works when the module that uses it is built 'standalone'. When the module is built as part of a large multi-module project I see either [INFO] : org.apache.maven.plugin.assembly.model.Assembly@13579e0 Assembly is incorrectly configured: null Assembly: null is not configured correctly: Cannot find ContainerDescriptorHandler with hint: instructions Or, even worse, [INFO] Trace java.lang.OutOfMemoryError: Java heap space at java.lang.String.substring(String.java:1770) at org.codehaus.plexus.interpolation.util.StringUtils.capitalizeFirstLetter(StringUtils.java:119) at org.codehaus.plexus.interpolation.reflection.ReflectionValueExtractor.evaluate(ReflectionValueExtractor.java:90) at org.codehaus.plexus.interpolation.ObjectBasedValueSource.getValue(ObjectBasedValueSource.java:59) at org.codehaus.plexus.interpolation.PrefixedValueSourceWrapper.getValue(PrefixedValueSourceWrapper.java:134) at org.codehaus.plexus.interpolation.AbstractDelegatingValueSource.getValue(AbstractDelegatingValueSource.java:44) at org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:196) at org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:124) at org.apache.maven.project.interpolation.AbstractStringBasedModelInterpolator.interpolateInternal(AbstractStringBasedModelInterpolator.java:315) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.traverseObjectWithParents(StringSearchModelInterpolator.java:185) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:135) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolateObject(StringSearchModelInterpolator.java:80) at org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolate(StringSearchModelInterpolator.java:62) at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:990) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:255) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:163) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedArtifact(MavenMetadataSource.java:94) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:387) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) I have boosted the memory settings to ridiculously high values with no effect, which leads me to believe I have created some kind of infinite dependency loop, because many of the other modules also use the assembly plugin (although without my ContainerDescriptorHandler). Does Maven have a switch to log the workings of the dependency mechanism as it does its job?
Shouldn't release:prepare check for distributionManagement
release:perform will fail if distributionManagement is not set. Shouldn't release:prepare check for this field and fail it it's not set? Regards, Daniel Serodio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Assembly plugin plugin
Robert Egan wrote: I have written a ContainerDescriptorHandler plugin for the Maven assembly plugin. It works when the module that uses it is built 'standalone'. When the module is built as part of a large multi-module project I see either [INFO] : org.apache.maven.plugin.assembly.model.Assembly@13579e0 Assembly is incorrectly configured: null Assembly: null is not configured correctly: Cannot find ContainerDescriptorHandler with hint: instructions Or, even worse, [INFO] Trace java.lang.OutOfMemoryError: Java heap space at java.lang.String.substring(String.java:1770) at org.codehaus.plexus.interpolation.util.StringUtils.capitalizeFirstLetter(StringUtils.java:119) at org.codehaus.plexus.interpolation.reflection.ReflectionValueExtractor.evaluate(ReflectionValueExtractor.java:90) at org.codehaus.plexus.interpolation.ObjectBasedValueSource.getValue(ObjectBasedValueSource.java:59) at org.codehaus.plexus.interpolation.PrefixedValueSourceWrapper.getValue(PrefixedValueSourceWrapper.java:134) at org.codehaus.plexus.interpolation.AbstractDelegatingValueSource.getValue(AbstractDelegatingValueSource.java:44) at org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:196) at org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:124) at org.apache.maven.project.interpolation.AbstractStringBasedModelInterpolator.interpolateInternal(AbstractStringBasedModelInterpolator.java:315) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.traverseObjectWithParents(StringSearchModelInterpolator.java:185) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:135) at org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolateObject(StringSearchModelInterpolator.java:80) at org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolate(StringSearchModelInterpolator.java:62) at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:990) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:255) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:163) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedArtifact(MavenMetadataSource.java:94) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:387) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) I have boosted the memory settings to ridiculously high values with no effect, which leads me to believe I have created some kind of infinite dependency loop, because many of the other modules also use the assembly plugin (although without my ContainerDescriptorHandler). Does Maven have a switch to log the workings of the dependency mechanism as it does its job? M2 or M3? For M2 the first error is normal, since every plugin is loaded once and once only. If the first usage of the assembly plugin does not contain your handler as
Re: Question about Maven Assembly Plugin
Hi, Anders; thank you for your answer! I tried using useProjectArtifact
false, but it did not work.
Could you please supply me with an example of a executable
jar-with-dependencies?
Kind regards,
QL
On Tue, Apr 17, 2012 at 8:06 AM, Anders Hammar and...@hammar.net wrote:
I think the solution is to set useProjectArtifact to false in the
assembly descriptor.
/Anders
On Tue, Apr 17, 2012 at 11:44, QL 983 fraterql...@gmail.com wrote:
Hi.
I am writing a little tutorial in my company about the use of the Maven
Assembly Plugin to build a executable jar, with all dependencies inside
it.
When I was using Maven 2.2.1, the following would done the job:
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
source1.5/source
target1.5/target
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
/plugin
...
/plugins
/build
...
This time, however, I am using Maven 3.0.4, and I am getting this
warning:
[WARNING] Cannot include project artifact: com.company.class; it doesn't
have an associated file or directory.
I read the plugin's documentation, but could not figure what is the
problem.
Here is the complete pom I am using now:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company/groupId
artifactIdtutorial/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
namesomeName/name
urlhttp://maven.apache.org/url
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
compileSource1.6/compileSource
/properties
build
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${compileSource}/source
target${compileSource}/target
/configuration
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
configuration
archive
manifest
mainClasscom.company.classX/mainClass
/manifest
/archive
descriptorRefs
descriptorRefjar-with-dependencies/descriptorRef
/descriptorRefs
/configuration
executions
execution
idmake-assembly/id !-- this is used for inheritance
merges
--
phasepackage/phase !-- bind to the packaging phase --
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.httpcomponents/groupId
artifactIdhttpclient/artifactId
version4.1.3/version
/dependency
/dependencies
/project
The resulting jar contains httpclient and all the dependencies it has,
but
no code of mine is added in the jar, and I get this output in command
line:
D:\projetos\tutorialmvn assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building tutorial 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.3:single (default-cli) @ tutorial ---
*[WARNING] Cannot include project artifact:
com.company:tutorial:jar:1.0-SNAPSHOT; it doesn't have an associated file
or directory.*
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/http/ already added, skipping
[INFO] org/apache/http/impl/ already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/maven/org.apache.httpcomponents/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[INFO] org/ already added, skipping
[INFO] org/apache/ already added, skipping
[INFO] org/apache/commons/ already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/maven/ already added, skipping
[INFO] Building jar:
Re: Assembly plugin plugin
M2. I suppose I will have to figure out a way to make sure mine gets loaded first. Are there any tricks out there for fooling the reactor? On Tue, Apr 17, 2012 at 5:58 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Robert Egan wrote: I have written a ContainerDescriptorHandler plugin for the Maven assembly plugin. It works when the module that uses it is built 'standalone'. When the module is built as part of a large multi-module project I see either Does Maven have a switch to log the workings of the dependency mechanism as it does its job? M2 or M3? For M2 the first error is normal, since every plugin is loaded once and once only. If the first usage of the assembly plugin does not contain your handler as part of its classpath, it will not be available anywhere else in the multi-project build. M3 should instantiate the plugin again with the proper CP. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
module question
I have a POM hat works correctly when it is the 'root' POM but fails to resolve a dependency when it is invoked as a module from another POM. How does one go about resolving an issue like this?
Re: The Maven Way
On 2012-04-17 9:12 AM, Mark H. Wood wrote: On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote: I also recommend taking the Sonatype training courses - especially if you are a software architect. There is a lot to be said when you can ask question as the instructor is going over the material. However, you are right, if someone were to write a book called the The Maven Way in the style you suggest, I would certainly be interested in buying a copy. You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. THAT IS SO TRUE People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? I think it has something to do with Dawinism - if you can't adapt to Maven you die ;-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: module question
Hello Robert, My guess is that the other pom defines a repository which cannot be accessed (e.g. due to security constraints). Having failing build output, not to mention pom files themselves, would help a lot to better diagnose root cause. Regards, Stevo. On Apr 18, 2012 1:17 AM, Robert Egan robert.e...@aciworldwide.com wrote: I have a POM hat works correctly when it is the 'root' POM but fails to resolve a dependency when it is invoked as a module from another POM. How does one go about resolving an issue like this?
Re: The Maven Way
On 2012-04-17 9:48 AM, Curtis Rueden wrote: Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. I think the comment if you don't do things Maven's way, Maven will fight you and Maven will win. is humor - not fact. Keeping your sense of humor is always good advice when working with Maven. IMHO - the most valuable single bit of advice one can give a new Maven user is: don't try to master it on your own - ask for help - there are thousands of people with great experience, knowledge and advice who are willing to share it. The Sonatype training has enormous ROI. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven in an unconventional way. After all, the beauty of convention over configuration is that you *can* configure and override behavior as needed. I do not see anyone criticizing someone who tries to use Maven in an unconventional way - rather we are saying - if you are using Maven and you don't want to hurt yourself... My many years of experience tells me that far too much technology is too configurable with too many options and choices - and ultimately that causes more trouble than it is worth. Maven is more than adequately configurable, but collectively we still have a lot to learn about respecting and utilizing convention over configuration and adapting to the common vision that is Maven. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? I think one major difficulty is that as Maven develops, there is an evolving vision and understanding of what works well and what doesn't. And that is OK, and will continue to be the case. That said, someone could probably make some good money writing a book about the current vision and understanding, as well as updating it with new editions over time. :-) This is very true. Very much of Maven is tribal knowledge and a tribal vision. Fortunately the tribe is strong and friendly :-) Regards, Curtis On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Woodmw...@iupui.edu wrote: On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote: I also recommend taking the Sonatype training courses - especially if you are a software architect. There is a lot to be said when you can ask question as the instructor is going over the material. However, you are right, if someone were to write a book called the The Maven Way in the style you suggest, I would certainly be interested in buying a copy. You are not alone in that. Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. People extol the virtues of convention over configuration, but where is the compact definitive specification of The Conventions? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu What is obvious to A may be not so obvious to B and downright ridiculous to C. -- Asimov - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The Maven Way
On 2012-04-17 11:53 AM, Ron Wheeler wrote: As the most frequent author of the 2 comments mentioned below, I will agree and disagree with Curtis' observations. He is right that Maven is very powerful and flexible. It is possible to make it do all kinds of interesting and useful things. However, it is also very easy when starting with Maven, to get into patterns based on experience with previous build tools, that make simple tasks much more difficult. That last sentence should be in bold face. It frequently appears from the person's statement that they are just starting with Maven and from the brief description of their problem that they are building a fairly common type of application that can be built very easily by Maven with a relatively simple POM and project structure. However, they have gotten off on the wrong foot and are trying to bend Maven to their will or as Curtis might say exploit the full power and flexibility of Maven. Often the wrong foot is simply not knowing how much Maven does for your for free - because it is not obvious - especially when compared to tools like Ant. When the free stuff is not obvious, we naively start trying to solve problems we do not have to. I usually quote the offending phrases around fighting Maven and profiles are evil in an attempt to get them to reexamine their strategy and see if their project does follow one of the more common patterns (webapp, standalone executable, etc.) that Maven can handle very simply. I will admit that I am not often the source of detailed technical information in these cases since I do not usually know how to do what they are doing and I am also pretty suspicious that the help that they want is not in their best interest. One of the dangers in this forum is that there are bunch of guys here who are very, very smart and very knowledgeable about Maven and can patch up a really bad Maven approach into something that will work. If you ask the wrong question, you may get the right answer which will help you get further out of your depth. One of the problems with documentation is that it often describes everything that you can do without pointing out that some of these things should only be used in rare circumstances and should only be considered after you have exhausted the normal features and patterns. Sometimes the examples demonstrate the power of the feature rather than the most common use which is considered to be too simple to be worth showing and does not show the full elegnce of the feature. Another problem that new users face is the reluctance to make big changes in their project structures or development methodology until they are sure that Maven is the way to go. This is understandable and my goal is to get them to understand that a little up front investment in conforming to convention may generate a short-term return when compared to trying to get a build process in place that follows their existing practice. I hope that my comments also give a sense of optimism that what they want to do is possible with Maven and that the forum is here to help them. Ron On 17/04/2012 12:48 PM, Curtis Rueden wrote: Hi everyone, Especially since the most valuable single bit of advice one can give a new Maven user is: if you don't do things Maven's way, Maven will fight you and Maven will win. I disagree that it is the most valuable single bit of advice. It is repeated far too frequently, often in cases where there *is* a reasonable technical answer to the question being asked. Maven is much more flexible than many give it credit for. You can write your own plugins to do nearly anything, or invoke Ant with AntRun if you have existing Ant-based builds. Even conventions like one project = one JAR are not universally true—the assembly plugin lets you do all kinds of nifty stuff including building multiple artifacts as part of the same project. People complain about the nested src/main/java directory structure but you don't even need that; it is actually really easy to override the source and resource directories in the great majority of cases. People complain about profiles being evil but they are an extremely powerful tool, and like any powerful tool are only as good or evil as their use. I think it is great to caution people against anti-patterns, etc., pointing out how they could make their lives easier by structuring things differently. But if we are not careful, such advice can degenerate into nonconstructive criticism, as illustrated by the unfortunate saying: Don't fight against Maven, you'll loose [sic]. This attitude causes real problems within the developer community: at least one of the teams with which I collaborate dislikes Maven due to its our way or the highway attitude. Maven is an extremely powerful set of building blocks, and I think we should be focusing on promoting that power and flexibility, rather than criticizing anyone who tries to use Maven
Re: module question
Thanks The real answer is that in the multi-module project, someone calls the 'standard' assembly plugin before I do (there are many other EARs, WARs and JARs in the build). So it is the one in memory when the module that needs mine is invoked. I need to find a way to insure that my assembly plugin is loaded first, and therefore loads the required dependency. On Tue, Apr 17, 2012 at 7:25 PM, Stevo Slavić ssla...@gmail.com wrote: Hello Robert, My guess is that the other pom defines a repository which cannot be accessed (e.g. due to security constraints). Having failing build output, not to mention pom files themselves, would help a lot to better diagnose root cause. Regards, Stevo. On Apr 18, 2012 1:17 AM, Robert Egan robert.e...@aciworldwide.com wrote: I have a POM hat works correctly when it is the 'root' POM but fails to resolve a dependency when it is invoked as a module from another POM. How does one go about resolving an issue like this?
Re: The Maven Way
On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote: Often the wrong foot is simply not knowing how much Maven does for your for free - because it is not obvious - especially when compared to tools like Ant. When the free stuff is not obvious, we naively start trying to solve problems we do not have to. The way I describe this is by getting people to ask the right question: Wrong question: How do I do X? Right question: Does does maven do X? Maven already knows how to do stuff. Find out how maven does it, and let maven get on with the job. As soon as you want maven to work your way, and not maven's way, expect to have loads of your time wasted, and the time of everyone after you too. The next thing is that maven isn't an alternative to ant, rather maven is an alternative to ant's build.xml file. Or to put it another way, maven does what build.xml does. build.xml gets written, rewritten and rewritten again for every single ant project, but there is only one maven. I have to care how your build.xml is different to my build.xml, I have to document how your build.xml is different to my build.xml, but if we both used maven, all this becomes unnecessary, because there is only one maven. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: module question
The real answer is that in the multi-module project, someone calls the 'standard' assembly plugin before I do (there are many other EARs, WARs and JARs in the build). So it is the one in memory when the module that needs mine is invoked. I need to find a way to insure that my assembly plugin is loaded first, and therefore loads the required dependency. Or you could just move to Maven3 where this bug in M2 was resolved... assuming that I understand what you are saying. Otherwise if you are on M3, you need to adjust your dependencies and declare things in such a way that Maven can properly calculate the build path. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: module question
Thanks But that's not my decision to make. On Tue, Apr 17, 2012 at 9:38 PM, Wayne Fay wayne...@gmail.com wrote: The real answer is that in the multi-module project, someone calls the 'standard' assembly plugin before I do (there are many other EARs, WARs and JARs in the build). So it is the one in memory when the module that needs mine is invoked. I need to find a way to insure that my assembly plugin is loaded first, and therefore loads the required dependency. Or you could just move to Maven3 where this bug in M2 was resolved... assuming that I understand what you are saying. Otherwise if you are on M3, you need to adjust your dependencies and declare things in such a way that Maven can properly calculate the build path. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Assembly plugin plugin
I suppose I will have to figure out a way to make sure mine gets loaded first. Are there any tricks out there for fooling the reactor? I know of no tricks. You should talk to the owner of the other module(s) using the assembly plugin and convince them to add your handler into their plugindependencies or even better get the owner of the top parent to add a pluginManagement section and specify it there (then it will be inherited down to all the other poms). Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: module question
But that's not my decision to make. M3 is vastly superior and almost completely backwards compatible. This shouldn't be a very hard sell considering the variety of bug fixes (such as this one) from M2. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
I want to exclude the /resources folder from the release so it doesn't get compiled into my .jar If you can't sort out how to do this, you can always make another project, depend on the output of this one, then unpack the assembly, set your excludes there, and repack the assembly minus the files you don't want. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude folders during mvn assembly
On Wed, Apr 18, 2012 at 2:20 PM, Wayne Fay wayne...@gmail.com wrote: I want to exclude the /resources folder from the release so it doesn't get compiled into my .jar If you can't sort out how to do this, you can always make another project, depend on the output of this one, then unpack the assembly, set your excludes there, and repack the assembly minus the files you don't want. Also, why are you putting things in src/main/resources if you dont want them in your jar? Just put them somewhere else and they wont be included. If they are needed for testing it should be src/test/resources. If they are configuration files I put them in src/main/config and then you can tell the assembly plugin to include them in the zip it builds. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Selective Parallel Builds with maven 3
HI John and Srinath, Thanks for the reply. We have 2 code bases which I would like to build in parallel. They are [1], [2]. [1] https://svn.wso2.org/repos/wso2/carbon/kernel/trunk/ - Number of Java files : 4700+ (this is with out any generated code) - Modules: Entire build is structured into multiple modules (Hierarchy goes several levels deep) [2] https://svn.wso2.org/repos/wso2/carbon/platform/trunk/ - Number of Java files : around 25000 (without generated code) - Modules: Same as [1] To explain the situation further, I tried building the code bases (in parallel) at the root but didn't work (due to various reasons). However, I figured out parts/modules can be built like this without any modification to the setup. So my idea is to rather than trying parallelize everything in one attempt ( which I don't see realistic, considering size of the code base and complexity of the setup etc), I like to enable parallel builds to parts/modules it will work for certain. On second thoughts, it takes more than half a day to build it (includes tests). So, has anyone tried something like this before? (or is there a better approach) Thanks, - Ramith Jayasinghe On Tue, Apr 17, 2012 at 8:03 PM, John Patrick nhoj.patr...@gmail.comwrote: Out of interest... How many modules is that? How many java files? Any code generation happening like XMLBeans etc? Also does that half day include or exclude test execution time? I worked somewhere, where the build was 3 hours not including tests, by simply upgrading from maven 2.x to 3 and splitting some of the code into smaller modules I managed to drop the build to 20 minutes. Compiling 10 modules each with 200 java files is much quicker than compiling 2,000 java files at once. On 17 April 2012 15:24, Srinath C srinat...@gmail.com wrote: Wow! Half a day sounds like a huge code base! Anyways, yes you can do this in Maven 3 but maven takes the call on how the modules get build. You can enforce a build order among modules using dependencies (if A depends on B, maven will build B before A) but I'm not aware of any other ways to enforce the order. Another notable point is to check if your plugins are compatible with parallel builds - either check their documentation or simply build with -T N option and watch for warnings (N is the number of threads to build in parallel). Regards, Srinath. On Tue, Apr 17, 2012 at 5:04 PM, Ramith Jayasinghe ramithro...@yahoo.comwrote: Greetings Everyone, I'm trying to build my project in parallel using Maven 3, so I can reduce the time taken (Currently it takes around better half of a day to completely build it). May be this sounds stupid, but the way I want to do is to build some of the modules in project serially while others in parallel. So ideally, when I do a 'mvn clean install', I want maven to parallel build parts of the project that are marked/configured for that and others sequentially. Is this possibe with current capabilities of maven 3? Thanks in advance, - Ramith Jayasinghe - 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: Selective Parallel Builds with maven 3
Thanks for the info Ramith. Was wondering why building them in parallel at the root did not work but if its too much of details to mention about, its ok. But I have never built a subset of the modules in parallel. Building the entire set of modules in parallel is what I have tried successfully. Regards, Srinath. On Wed, Apr 18, 2012 at 11:08 AM, Ramith Jayasinghe rami...@opensource.lkwrote: HI John and Srinath, Thanks for the reply. We have 2 code bases which I would like to build in parallel. They are [1], [2]. [1] https://svn.wso2.org/repos/wso2/carbon/kernel/trunk/ - Number of Java files : 4700+ (this is with out any generated code) - Modules: Entire build is structured into multiple modules (Hierarchy goes several levels deep) [2] https://svn.wso2.org/repos/wso2/carbon/platform/trunk/ - Number of Java files : around 25000 (without generated code) - Modules: Same as [1] To explain the situation further, I tried building the code bases (in parallel) at the root but didn't work (due to various reasons). However, I figured out parts/modules can be built like this without any modification to the setup. So my idea is to rather than trying parallelize everything in one attempt ( which I don't see realistic, considering size of the code base and complexity of the setup etc), I like to enable parallel builds to parts/modules it will work for certain. On second thoughts, it takes more than half a day to build it (includes tests). So, has anyone tried something like this before? (or is there a better approach) Thanks, - Ramith Jayasinghe On Tue, Apr 17, 2012 at 8:03 PM, John Patrick nhoj.patr...@gmail.com wrote: Out of interest... How many modules is that? How many java files? Any code generation happening like XMLBeans etc? Also does that half day include or exclude test execution time? I worked somewhere, where the build was 3 hours not including tests, by simply upgrading from maven 2.x to 3 and splitting some of the code into smaller modules I managed to drop the build to 20 minutes. Compiling 10 modules each with 200 java files is much quicker than compiling 2,000 java files at once. On 17 April 2012 15:24, Srinath C srinat...@gmail.com wrote: Wow! Half a day sounds like a huge code base! Anyways, yes you can do this in Maven 3 but maven takes the call on how the modules get build. You can enforce a build order among modules using dependencies (if A depends on B, maven will build B before A) but I'm not aware of any other ways to enforce the order. Another notable point is to check if your plugins are compatible with parallel builds - either check their documentation or simply build with -T N option and watch for warnings (N is the number of threads to build in parallel). Regards, Srinath. On Tue, Apr 17, 2012 at 5:04 PM, Ramith Jayasinghe ramithro...@yahoo.comwrote: Greetings Everyone, I'm trying to build my project in parallel using Maven 3, so I can reduce the time taken (Currently it takes around better half of a day to completely build it). May be this sounds stupid, but the way I want to do is to build some of the modules in project serially while others in parallel. So ideally, when I do a 'mvn clean install', I want maven to parallel build parts of the project that are marked/configured for that and others sequentially. Is this possibe with current capabilities of maven 3? Thanks in advance, - Ramith Jayasinghe - 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
