Re: Strange warning with m-enforcer-p
Hi,
for unknown reasons I have seen Konrad's answer to my original post only
on the list archive @ lists.apache.org; it didn't arrive in my mailbox...
Anyway. My project is a standalone project, i.e. it doesn't inherit from
some other project, and instead only uses (OSS) dependencies.
As suggested by Konrad I tried "mvn help:effective-pom", but the
mentioned legacy parameter isn't contained at all in the output. WRT to
m-enforcer-p the output of that command is the same as the snippet in my
original mail (apart from the omitted groupId) and appears at each module...
Regards
Thorsten
Am 08.08.24 um 09:57 schrieb Thorsten Heit:
Hi,
in a multi-module build I have added the enforcer plugin in the top-
level pom.xml using the following configuration:
org.apache.maven.plugins
maven-enforcer-plugin
3.5.0
enforce-versions
enforce
3.9.4
[21,)
When I execute "mvn clean verify" I see the following warning message in
the console on each module that is being built:
[WARNING] Cannot find a Mojo parameter 'commandLineRules' to read for
Mojo org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce
{execution: enforce-versions}. This parameter should be ignored.
I don't use "commandLineRules" (that is deprecated according to the
enforce mojo documentation), and the above snippet is similar to the
example shown in the usage documentation ([1]). So why is this printed
at all? Is this intentionally? Or a bug^H^H^Hfeature?
Environment (if that matters):
- Maven 3.9.8
- Java 22.0.2 (from adoptium.net)
- Windows 11
[1] https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html
Regards
Thorsten
Strange warning with m-enforcer-p
Hi,
in a multi-module build I have added the enforcer plugin in the
top-level pom.xml using the following configuration:
org.apache.maven.plugins
maven-enforcer-plugin
3.5.0
enforce-versions
enforce
3.9.4
[21,)
When I execute "mvn clean verify" I see the following warning message in
the console on each module that is being built:
[WARNING] Cannot find a Mojo parameter 'commandLineRules' to read for
Mojo org.apache.maven.plugins:maven-enforcer-plugin:3.5.0:enforce
{execution: enforce-versions}. This parameter should be ignored.
I don't use "commandLineRules" (that is deprecated according to the
enforce mojo documentation), and the above snippet is similar to the
example shown in the usage documentation ([1]). So why is this printed
at all? Is this intentionally? Or a bug^H^H^Hfeature?
Environment (if that matters):
- Maven 3.9.8
- Java 22.0.2 (from adoptium.net)
- Windows 11
[1] https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html
Regards
Thorsten
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: a question about the Maven Resolver Ant Tasks uber JAR
Hi, For reasons that I may no longer believe, I tried to make a JAR that included the Maven Resolver Ant Tasks uber JAR plus some extra stuff. I figured I could do that by resolving the Maven Resolver Ant Tasks and including all those artifacts in my JAR. But that did not work. The resulting JAR fails because of a class not found: org/apache/commons/logging/LogFactory [called from http AbstractVerifier]. What seems odd is that the POM for maven-resolver-transport-http *explicitly excludes commons-logging*. The stated explanation is that jcl-over-slf4j is used instead. But obviously, there is some need for commons-logging, and the MRAT uber JAR includes commons-logging. Is commons-logging added to the MRAT uber JAR as a special case? As long as *jcl-over-slf4j* itself is included, that explains the presence of commons-logging stuff: % jar tf ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar | sort META-INF/ (...) org/ org/apache/ org/apache/commons/ org/apache/commons/logging/ org/apache/commons/logging/Log.class org/apache/commons/logging/LogConfigurationException.class org/apache/commons/logging/LogFactory.class org/apache/commons/logging/impl/ org/apache/commons/logging/impl/NoOpLog.class org/apache/commons/logging/impl/SLF4JLocationAwareLog.class org/apache/commons/logging/impl/SLF4JLog.class org/apache/commons/logging/impl/SLF4JLogFactory.class org/apache/commons/logging/impl/SimpleLog.class Regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
Hi Joseph, +. 8 Xalan-J's next release should be Maven-based. But we wanted to put out one Java 8-compatible-but-deprecated build before moving to Java 17. I guess you're mixing a few things here: Maven 3 (or 4, doesn't matter) needing Java >= version X only means that you need that version X to *execute* Maven itself. Projects that you *build* with Maven can for sure be compiled for other and/or older Java versions (*); this is up to the compiler plugin and its configuration. (*) As long as the JDK you're using supports that. Java 17 for example dropped support in javac for Java 6, and since Java 20 javac only compiles for Java >=8. Regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
+1 (although I'd prefer to directly require Java 21 :-)) Regards Thorsten Am 28.02.24 um 08:30 schrieb Benjamin Marwell: Hi Maven Devs/Users/Committers and PMC members! After several discussions on the mailing lists, I would like to start a vote in favour of setting the minimal Java bytecode target of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. This is a procedural majority vote [1*]: You can also vote with fractions and negative votes are not vetoes. Please also notice: * Maven 3 will stay at Java 8 no matter what. * We may raise Maven 4 to JDK 21 later if we feel like it (depending on the release date). This is not part of this vote. * The linked PR is not part of this vote (this is not a code vote). But you may take a look at it to understand the intended change. PR: https://github.com/apache/maven/pull/1430 Maven-Parent will not be raised with this vote, the other PR is not part of this vote. Please refrain from starting discussions in this thread, but do include a reasoning on downvotes and feel free to start a new discussion on the mailing list, or comment on the existing ones. --- Vote open for 72 hours: [ ] +1 (set JDK17 min version for Maven 4.x) [ ] +0 [ ] -1 (please include reasoning) --- - Ben [1*]: https://www.apache.org/foundation/voting.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: Browsing Maven central buggy?
Hi, thanks for all your answers and pointers to valuable tools. So far I'm using the versions plugin via command line to find out whether there's something new, but from time to time I'd simply like to use my browser to have a look into Maven central; mostly to just inspect a dependency's POM and see what's (new?) inside... ;-) Thorsten Am 24.01.24 um 18:13 schrieb Manfred Moser: I suggest to use the maintained search and browse frontend from Sonatype instead. https://search.maven.org/ .. same as https://central.sonatype.com/ And browse at https://central.sonatype.com/search It sits on top of the same data and is very nice indeed .. props to Brian Fox and team btw! Manfred On 2024-01-24 08:57, Tamás Cservenák wrote: Howdy, Yes, this is a known problem, but it does not affect Maven, as it does not "browse". Basically you have to go directly to the directory you are looking for, and not rely on HTML "index page" as that seems not maintained since a while. T On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit wrote: Hi, browsing Maven Central using a webbrowser seems, well, a bit buggy: In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/ for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1 whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible. The same happens for a few other GAV coordinates such as https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0 : The directories exist, but one level above these versions are not shown. Is this a known problem? Thorsten - 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
Browsing Maven central buggy?
Hi, browsing Maven Central using a webbrowser seems, well, a bit buggy: In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/ for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1 whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not visible. The same happens for a few other GAV coordinates such as https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/ or https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0: The directories exist, but one level above these versions are not shown. Is this a known problem? Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to force Maven to put a dependency on the module-path?
Hi Martin, Even if a library decide to do the duplication, it may still not work. Starting with Java 9, a service provider can be instantiated by invoking a public static method named "provider" in the provider declared in "module-info.class". This is an alternative to invoking the default public constructor. This alternative is very convenient when we want the provider to be a singleton for example. However the public static "provider" method is invoked only for services declared in "module-info.class", not for services declared in the old way. So if a service provider relies on that, it will not work on the class-path. I see your point, but we're not living in a fully modularized Java world: If you insist on having a Jar reside on the module path only, this prevents others from using it on applications that are not fully modularized or that cannot be modularized (yet). Furthermore I don't really see a problem of duplication. Normally you don't have tons of service provider implementations in one Jar (IMO) so this shouldn't be too much hassle to have a few lines in your module descriptor AND in the provider configuration file under META-INF/services... To the singleton example you mentioned: I don't know if that really makes sense. To be compatible with fully-modular applications and those that aren't I'd extract the necessary parts from the provider implementation into a singleton class and use that one instead. In this case you still could have multiple instances of your provider implementation, and all of them internally use a singleton for configuration data or whatever... Finally the consequence on putting a dependency on the class-path rather than the module-path is much larger than only "java.util.ServiceLoader". The behavior of any methods annotated @CallerSensitive in OpenJDK source code may be impacted. It includes for example "ClassLoader.getResource(String)". If a library depends on those methods behaving the way the behave when the file is loaded at a module, that library may be broken if put on the class-path. Out of curiosity: Can you show an example that depends on such methods? I personally don't see a reason why a library should behave different if it is on the module path or class path... So to summarize: putting a JAR file on the module-path or class-path has deep consequences. A developer way want either ways on intend (including putting a modularized JAR file on the class-path or a non-modularized JAR file on the module-path, yes the opposite of the "sane" way, there is use cases for that). Maven should not keep developers prisoners of black magic. We need control on that. IMHO a library is buggy if it's *behavior* depends on whether it is being used on the module path or on the classpath. Just my thoughts... Kind regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to increment verion number and then deploy
Hi,
The following command can deploy and then increment verion number,
but how to increment verion number and then deploy?
> mvn build-helper:parse-version versions:update-versions
-DdevelopmentVersion=${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion}
deploy
A few suggestions:
1) Split this single line into two commands:
%> mvn build-helper:parse-version versions:update-versions...
%> mvn deploy
2) Have you thought about using maven-release-plugin instead of the
above command(s)?
3) If you don't want to have fixed version numbers in your pom.xml, you
could also use ${revision} and then simply execute
"mvn deploy -Drevision=xx.yy.zz"; see [1].
[1] https://maven.apache.org/maven-ci-friendly.html
HTH
Thorsten
OpenPGP_signature
Description: OpenPGP digital signature
Re: m-release-m on Jenkins: 'cmd' is not recognized as an internal or external command
Hi, I have created MRELEASE-1110 because the same steps work when I use m-release-p 3.0.0-M5, but not 3.0.0-M6 or M7... Regards Thorsten Am 18.11.22 um 10:56 schrieb Thorsten Heit: Hello, I'm struggling with a phenomen trying to simulate a release build of a Maven project on a Jenkins agent; I hope someone has a glue what's going on... The project itself is configured as a Maven project inside Jenkins and is built by an agent running on a Windows machine. Using "clean verify" as job goals and options, I can build the project successfully. So far, so good. Changing this to "-X -B -DdevelopmentVersion=1.3.1-SNAPSHOT -DreleaseVersion=1.3.0 -Dresume=false -DdryRun=true -DautoResolveSnapshots=all release:prepare", the build finally fails: (...) [INFO] starting prepare goal in dry-run mode, composed of 17 phases: check-poms, scm-check-modifications, check-dependency-snapshots, create-backup-poms, map-release-versions, input-variables, map-development-versions, rewrite-poms-for-release, generate-release-poms, run-preparation-goals, scm-commit-release, scm-tag, rewrite-poms-for-development, remove-release-poms, run-completion-goals, scm-commit-development, end-release [INFO] 1/17 prepare:check-poms dry-run (...) [INFO] 10/17 prepare:run-preparation-goals dry-run [INFO] Executing preparation goals - since this is simulation mode it is running against the original project, not the rewritten ones [INFO] Executing goals 'clean verify'... [INFO] with additional arguments: -P override_defaults,signing,jdks,infport,sonarqubevariables [DEBUG] Using maven.home of: 'D:\Build\Tools\Java\maven\apache-maven-3.8.3'. [DEBUG] Executing: cmd.exe /X /C "D:\Build\Tools\Java\maven\apache-maven-3.8.3\bin\mvn.cmd -B -X -D maven.repo.local=D:\Build\MvnCaches\ContInteg\.m2\repository -s C:\Users\continteg\AppData\Local\Temp\release-settings3704353483465351730.xml clean verify -P override_defaults,signing,jdks,infport,sonarqubevariables" [INFO] Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739) [INFO] Maven home: D:\Build\Tools\Java\maven\apache-maven-3.8.3 [INFO] Java version: 1.8.0_152, vendor: Oracle Corporation, runtime: D:\Build\Tools\Java\JDKs\jdk1.8.0\jre [INFO] Default locale: en_US, platform encoding: Cp1252 [INFO] OS name: "windows server 2016", version: "10.0", arch: "amd64", family: "windows" (...) [INFO] [INFO] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] [INFO] [INFO] Total time: 4.492 s [INFO] [INFO] Finished at: 2022-11-18T10:07:35+01:00 [INFO] [INFO] [ERROR] 'cmd' is not recognized as an internal or external command, [ERROR] operable program or batch file. [JENKINS] Archiving disabled [INFO] [INFO] [INFO] Skipping easyMailServer [INFO] This project has been banned from the build due to previous failures. [INFO] [JENKINS] Archiving disabled [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 6.650 s [INFO] Finished at: 2022-11-18T10:07:35+01:00 [INFO] Waiting for Jenkins to finish collecting data [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:3.0.0-M7:prepare (default-cli) on project easyMailServer: Maven execution failed, exit code: 1 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:3.0.0-M7:prepare (default-cli) on project easyMailServer: Maven execution failed, exit code: 1 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMave
m-release-m on Jenkins: 'cmd' is not recognized as an internal or external command
Hello, I'm struggling with a phenomen trying to simulate a release build of a Maven project on a Jenkins agent; I hope someone has a glue what's going on... The project itself is configured as a Maven project inside Jenkins and is built by an agent running on a Windows machine. Using "clean verify" as job goals and options, I can build the project successfully. So far, so good. Changing this to "-X -B -DdevelopmentVersion=1.3.1-SNAPSHOT -DreleaseVersion=1.3.0 -Dresume=false -DdryRun=true -DautoResolveSnapshots=all release:prepare", the build finally fails: (...) [INFO] starting prepare goal in dry-run mode, composed of 17 phases: check-poms, scm-check-modifications, check-dependency-snapshots, create-backup-poms, map-release-versions, input-variables, map-development-versions, rewrite-poms-for-release, generate-release-poms, run-preparation-goals, scm-commit-release, scm-tag, rewrite-poms-for-development, remove-release-poms, run-completion-goals, scm-commit-development, end-release [INFO] 1/17 prepare:check-poms dry-run (...) [INFO] 10/17 prepare:run-preparation-goals dry-run [INFO] Executing preparation goals - since this is simulation mode it is running against the original project, not the rewritten ones [INFO] Executing goals 'clean verify'... [INFO] with additional arguments: -P override_defaults,signing,jdks,infport,sonarqubevariables [DEBUG] Using maven.home of: 'D:\Build\Tools\Java\maven\apache-maven-3.8.3'. [DEBUG] Executing: cmd.exe /X /C "D:\Build\Tools\Java\maven\apache-maven-3.8.3\bin\mvn.cmd -B -X -D maven.repo.local=D:\Build\MvnCaches\ContInteg\.m2\repository -s C:\Users\continteg\AppData\Local\Temp\release-settings3704353483465351730.xml clean verify -P override_defaults,signing,jdks,infport,sonarqubevariables" [INFO] Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739) [INFO] Maven home: D:\Build\Tools\Java\maven\apache-maven-3.8.3 [INFO] Java version: 1.8.0_152, vendor: Oracle Corporation, runtime: D:\Build\Tools\Java\JDKs\jdk1.8.0\jre [INFO] Default locale: en_US, platform encoding: Cp1252 [INFO] OS name: "windows server 2016", version: "10.0", arch: "amd64", family: "windows" (...) [INFO] [INFO] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] [INFO] [INFO] Total time: 4.492 s [INFO] [INFO] Finished at: 2022-11-18T10:07:35+01:00 [INFO] [INFO] [ERROR] 'cmd' is not recognized as an internal or external command, [ERROR] operable program or batch file. [JENKINS] Archiving disabled [INFO] [INFO] [INFO] Skipping easyMailServer [INFO] This project has been banned from the build due to previous failures. [INFO] [JENKINS] Archiving disabled [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 6.650 s [INFO] Finished at: 2022-11-18T10:07:35+01:00 [INFO] Waiting for Jenkins to finish collecting data [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:3.0.0-M7:prepare (default-cli) on project easyMailServer: Maven execution failed, exit code: 1 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:3.0.0-M7:prepare (default-cli) on project easyMailServer: Maven execution failed, exit code: 1 at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.jvnet.hudson.maven3.launcher.Maven35Launcher.main (Maven35Launcher.java:138) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at
m-antrun-p and Maven properties
Hi,
we're using m-antrun-p in a submodule of a multimodule build. Some of
the tasks configured in the plugin use ${project.parent.basedir} to
access a certain directory in the parent directory.
With m-antrun-p 1.3 this works, the commands are executed successfully.
Now with version 3.0.0 this doesn't work (anymore); the property isn't
resolved.
I also added the following into the submodule pom:
${project.parent.basedir}
But obviously the property isn't resolved; I don't see the directory
with "mvn help:effective-pom".
I could use ${project.basedir}/.. as an alternative, I know :), but what
is the reason that the property can be used with m-antrun-p 1.3?
Coincidence?
PS: I'm using Maven 3.8.3.
Regards
Thorsten
OpenPGP_signature
Description: OpenPGP digital signature
Re: Re: testExcludes/Includes to compile test with different java version
Hi,
> I am not quite sure why the java14ge profile should only compile and run
> a single test and not all tests. The more intuitive way to organise the
> build would be to run all relevant tests for all JDKs, i.e. the JDK 14
> tests being a superset of the JDK 8 tests. But you asked for a "logical
> XOR", i.e. either/or solution, so I am recommending you to use
>
> mvn help:effective-pom
>
> in order to inspect your configuration. If you look at the effective
> POM, you will see that you put your JDK8 compiler configuration with
> testExcludes into the general plugin configuration section rather than
> in the one for goal testCompile. That parameter only exists there,
> though.
>
> You can also combine with -P java8ge,!java14ge or -P !java8ge,java14ge
> in order to explicitly check for a certain profile version and override
> auto activation.
>
> One way to make your respective test compilations mutually exclusive
> would be to override the default execution default-testCompile which
> would otherwise be included in each profile unless deactivated via
> none. So how about this?
I'd suggest a different solution. It looks more complex, but in the end
lets you clearly differ between "normal" Java-8-compatible code and code
that has to use Java >= 14:
Basically use three profiles:
- The first is used as long as you're using Java 8
It only instructs m-compiler-p to use JDK 1.8 as source and target for
your code
- The second is active when you use Java >= 9:
It does the same as the first, but uses the "release" flag of the
compiler
- The third uses a feature of m-compiler-p to create a multirelease output
with only a single project; see
https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml
:
Normal code under src/main/java and src/test/java is compiled with the
default settings from profile 1 or 2, and additional code under
src/main/java14 and src/test/java14 is compiled against Java 14.
3.8.1
jdk8
[,9)
org.apache.maven.plugins
maven-compiler-plugin
${maven.compiler.plugin.version}
1.8
1.8
jdk9+
[9,)
org.apache.maven.plugins
maven-compiler-plugin
${maven.compiler.plugin.version}
8
jdk14
[14,)
${basedir}/src/main/java14
org.apache.maven.plugins
maven-compiler-plugin
${maven.compiler.plugin.version}
jdk14-compile
compile
14
${project.basedir}/src/main/java14
true
jdk14-testcompile
testCompile
14
${project.basedir}/src/test/java14
--enable-preview
org.apache.maven.plugins
maven-jar-plugin
default-jar
true
HTH
Thorsten
Re: Re: How to make plugin part of default build in Maven.
Hi Linus, > Thanks, Thorsten. > That worked perfectly. You're welcome. > What's the difference between the two? > Why doesn't pluginmanagement recognise the added plugins? In the plugin management section you can specify and (pre-)configure plugins that can be used for example in child projects, and in the plugins section you list all the plugins you use when building your project. > Any documentation? Sure: https://maven.apache.org/pom.html#Plugin_Management :-) Regards Thorsten
Re: How to make plugin part of default build in Maven.
Hi, > I've just started working with Maven and this is my initial pom > configuration. > > *snip* > How do I ensure that Checkstyle plugin is executed when I simply type mvn > on the command prompt? Move the plugin(s) you'd like to use during a build ouf of the plugin management section directly into build/plugins. HTH Thorsten
Re: PKIX path building error with Azul ZULU Open JDK 14
Hi, > When I add the maven certificate to JRE certs, its working fine. > But every time there is change at maven side, I need to add the certification > again. > Is there anything we can add to the setttings? This has nothing do to with Maven, but with your Java installation. I assume you're working in a corporate environment that uses its own PKI with its own (root) certificates. Java normally doesn't use the certificates provided by your OS, but instead has its own certificate store (the already mentioned cacerts file that is contained in your Java installation). Therefore you have to manually add your company PKI certs to the Java installation to get rid of the PKIX path building error... Again, this has nothing to do with Maven and changes as the Mave side you mentioned (whatever this is). HTH Thorsten signature.asc Description: OpenPGP digital signature
Re: Maven jdk Error
Hi, > Here is my output when I deployed (...) > --- > T E S T S > --- (...) > Caused by: java.lang.UnsupportedClassVersionError: Preview features are not > enabled for Test (class file version 58.65535). Try running with > '--enable-preview' This is the root cause of the error you're getting. See for example this for a way to fix this: https://blog.codefx.org/java/enable-preview-language-features/ HTH Thorsten signature.asc Description: OpenPGP digital signature
Re: Re: NullPointerException in maven-jlink-plugin
Hi, > Hi, > > On 16.03.20 15:50, Thorsten Heit wrote: > > Hello, > > > > I tried to use maven-jlink-plugin to create a modular Java runtime image > > for an internal application. I've followed the description in the docs, > > but finally got a NullPointeException during execution of "mvn package"; > > the same error as in MJLINK-41. > > Do you have an example project which shows the behaviour? Unfortunately I don't have an example project at hand to show. In the meantime I cloned the source code and installed into my local $HOME. With that snapshow version my project now works (apart from some other errors during jlink, but they are on my side). > I hope I will time within the next weeks to get another release for > it..yeah it's long time ago... +1 :-) Are there things on the to-do list that need some helping hand? Regards Thorsten
NullPointerException in maven-jlink-plugin
Hello, I tried to use maven-jlink-plugin to create a modular Java runtime image for an internal application. I've followed the description in the docs, but finally got a NullPointeException during execution of "mvn package"; the same error as in MJLINK-41. Version 3.0.0-alpha-1 was release september 2017, and since then there were a couple of changes in the project. Is a new release planned / in the making? Or is there a possible workaround / fix for the NPE? Regards Thorsten
Re: build maven project without setting compiler source and target
Hi Matt, > So I guess it's an issue with NetBeans then a) using such an old version > of maven b) not handle compiler version and minium required > source/target correctly. > Guess I just set it to 8, as that's the oldest jdk/vm I still have lay > around, and don't bother anymore about it. > Thanks for your replies and time anyway. Normally an IDE should respect what you have configured in your pom.xml when you execute a Maven build. Therefore I still assume that you don’t have specified what exact version of m-compiler-p you’d like to use. And that you don’t have configured source and target in m-compiler-p, i.e. you use the default parameters which - according to your mail - are an older version of Maven‘s compiler plugin and/or no source/target version set. Can you show us a minimal sample? Regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: build maven project without setting compiler source and target
Hi, > Scanning for projects... (...) > - > COMPILATION ERROR : > - > Source option 5 is no longer supported. Use 6 or later. > Target option 1.5 is no longer supported. Use 1.6 or later. > 2 errors > - You obviously use an older version of maven-compiler-plugin that still defaults to Java 5. In that case this error is expectable as Java 11 doesn't support compiling for Java 5 anymore. The actual version 3.8.1 of m-compiler-p (see [1]) defaults to Java 6 as source and target for the compiler. I suggest you upgrade your pom.xml to that version. Anyway, I recommend you pin the version of each used plugin in your pom.xml. Otherwise you may get different results if you upgrade Maven, the JVM, use another OS and so on. [1] https://maven.apache.org/plugins/maven-compiler-plugin/ Regards Thorsten
Re: Re: failing jar:deploy
Hi, > Can you please help. Did you get any solution. Facing similar problem. A few more details would be helpful: - What exactly does not work? - Which command(s) do you execute, i.e. how do you call Maven? Command line? IDE? ...? - Can you provide a minimal sample project to reproduce this? Regards Thorsten
Re: java 1.8 and java 11 using toolchains plus compiler and surefire
Hi John, > evening, > > i'm having trouble testing a multi-release jar project using > toolchains. i want to test it using both java 1.8 and java 11. > > i've the following structure; > src/main/java > src/main/java11 > src/test/java > src/test/java11 > > tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3 > > if i set java to 1.8 and do mvn clean install, everything works but it > uses java 1.8 for the testing. > > if i set java to 11 and do maven clean install, it fails starting surefire. > > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: > The forked VM terminated without properly saying goodbye. VM crash or > System.exit called? > [ERROR] Error occurred in starting fork, check output in log > [ERROR] Process Exit Code: 1 > [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork > (ForkStarter.java:669) I've seen similar errors when executing tests under Java 11. I don't remember the exact reason, but I guess it was one of the following: - features available in Java 8 that were removed in Java 11 - improper module descriptor - for example missing dependencies such as jakarta.xml.bind:jakarta.xml.bind-api in your pom.xml when you're using JAXB in your code HTH Thorsten
Re: Maven question - how to pull code from bitbucket repository as dependency
Hi, > I have a maven project that builds Java jar files. I wan to run a python > script as one of the goals in the verify phase. I am planning to use the > ant run plugin for running the python script. The python script is stored > in a separate repository that I would like to copy to my project root > folder using maven. Is this possible? What's the best way to approach this? Although I have to admin I never tried it ;-), but two ideas: 1) Use the JGit Ant task ([1]) to checkout your source code before you execute the python script from within the Ant task. 2) Add a second plugin configuration for maven scm that is being executed in the verify phase. Configure the scm plugin and add at least the (developer) connection url, and perhaps the destination (checkout) directory in which your script is to be stored. See [2]. [1] https://wiki.eclipse.org/JGit/User_Guide#Ant_Tasks [2] https://maven.apache.org/scm/maven-scm-plugin/checkout-mojo.html HTH Thorsten
Re: How to work java 9 modules with Maven Surefire Plugin?
Hi, > I want to test my JPMS module using maven surefire plugin (2.22) > with junit5. For this I added the following to my pom: > > ... > >org.junit.jupiter >junit-jupiter-engine >5.3.0 >test > > ... > > org.apache.maven.plugins > maven-surefire-plugin > 2.22.0 > > > **/IT*.java > > > > > However, I have this error: > > Please refer to dump files (if any exist)[date]-jvmRun[N].dump, > [date].dumpstream and[date]-jvmRun[N].dumpstream.The forked VM > terminated without properly saying goodbye. VM crash orSystem.exit > called?Command was /bin/sh -c cd "/home/project"&&/opt/jdk-9/bin/ > java '@/home/project/target/surefire/ > surefireargs4438382394951202560''/home/project/target/ > surefire'2018-09-13T13-42-05_435-jvmRun1 > surefire4870497011802680670tmp surefire_015850140770716473411tmp > Error occurred in starting fork, check output in log > ProcessExitCode:1 (...) > Could anyone explain what I do wrong? It seems to > me that I don't use module-path while testing but how to use it I > didn't find. Maybe any links to examples. > Please, help. It seems similar to the issue reported here: https://issues.apache.org/jira/browse/SUREFIRE-1528 Can you try switching to m-surefire-p 2.21.0? On my system this additionally resolved a ClassNotFoundException I suddenly saw with 2.22.0 in one of our projects; see https://issues.apache.org/jira/browse/SUREFIRE-1537 Regards Thorsten
Re: Re: Dependency is missed while using maven-assembly-plugin
Hi Sergey, > I updated to the latest maven version 3.5.3 and configured the project > to use > the latest maven-assembly-plugin version 3.1.0. You seem to be hit by https://issues.apache.org/jira/projects/MASSEMBLY/issues/MASSEMBLY-782. In short: You have circular dependencies in Batik 1.7: batik-bridge -> batik-script -> batik-bridge... Can you use a newer version of batik-transcoder such as 1.8, 1.9 or 1.9.1 (all available on Maven Central)? Regards Thorsten
Re: Re: Dependency is missed while using maven-assembly-plugin
Hi, > The first thing I need to mention that I gave you a wrong version of > maven-assembly-plugin. > Maven-assembly-plugin version: 2.2-beta-5 > Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; > 2014-12-14T20:29:23+03:00) > Maven home: C:\soft\apache-maven-3.2.5 > Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_131\jre > Default locale: ru_RU, platform encoding: Cp1251 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" Can you try with with m-assembly-p 3.1.0 and see whether this behaves different? Could you switch to a newer version of Maven, i.e. 3.5.3 (the newest? Regards Thorsten
Antwort: Re: Maven JAVA_HOME
Hi, > Preston, Dale wrote on 2018-03-20 11:13: > > > On my server, I have JAVA_HOME set to jdk1.8.0_161.0. When I execute echo > > $JAVA_HOME, it shows the right path to my jdk1.8.0_161.0. When I run java > > -version, it shows the right version 8 as well. > > > > When I run maven -version, it shows this: > > > > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; > > 2018-02-24T13:49:05-06:00) > > Maven home: /opt/maven/latest > > Java version: 1.8.0_161, vendor: Oracle Corporation > > Java home: /usr/lib/jvm/jdk1.7.0_79/jre > > > > Note the Java home path to the wrong version but Java version shows the right > > version. > > > > Any tips on where Maven is getting that jdk1.7.0_79/jre path? On at least Linux the Oracle JDK installs a few files under /etc/profile.d to system-wide predefine some environment variables when you log in, depending on the shell you're using... HTH Thorsten
Re: Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Hi,
> On 15/03/18 12:51, Thorsten Heit wrote:
> > Hi,
> >
> >> The Apache Maven team is pleased to announce the release of the
> >> Apache Maven EAR Plugin Version 3.0.0
> >
> > First of all thanks for releasing a new version of this plugin!
> >
> > I just gave it a try in an internal multi-module project, but now I
can't
> > deploy the EAR anymore to Wildfly 11 server from within Eclipse:
>
>
> Sorry to say...you have expected that major version change to not change
> something ? ...Maybe I misunderstand a thing here...
That was absolutely not my intention :-)
I don't mind if there are changes when a major version is released.
> > Result:
> > After the copying process has finished, Wildfly doesn't start the EAR
> > because it cannot find the WAR module that is referenced in the
> > application.xml
>
> If I correctly understand that's only happening within Eclipse?
Yes, that's what I'm seeing. Building the EAR from the command line works
(as expected).
> The 3.0.0 version contains a change to handle all the time by default a
> full mapping of artifact names which is noticed on the start page:
>
> http://maven.apache.org/plugins/maven-ear-plugin/
>
> There is which by default contains:
>
> @{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
>
> So if you like to go back just change this configuration in your build
> and it should work as before but with the risk of failing in case of
> same artifactId's..
Ok, thanks, I'll give this a try.
I guess I won't have failing builds because that's what would already have
happened actually with m-ear-p 2.10.1 ;-)
OTOH, do you know who is responsible for the now invalid output file
mapping with m-ear-p 3.0.0 when I'm deploying the EAR in Eclipse to a
Wildfly server instance? It seems to me that at least in this part there's
a bug (?) because the (change in the) output file name mapping isn't
respected...
Side note:
I like the idea of having the group Id in the file name for artifacts. Is
something similar planned for m-war-p?
Regards
Thorsten
Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Hi,
> The Apache Maven team is pleased to announce the release of the
> Apache Maven EAR Plugin Version 3.0.0
First of all thanks for releasing a new version of this plugin!
I just gave it a try in an internal multi-module project, but now I can't
deploy the EAR anymore to Wildfly 11 server from within Eclipse:
Environment:
Eclipse Oxygen.2 (4.7.2, Build id: 20171218-0600)
Wildfly 11
Java 8u162
m2e 1.8.2.20171007-0217
m2e-wtp 1.3.3.20171208-1305
Snippet from my pom.xml:
(...)
org.apache.maven.plugins
maven-ear-plugin
2.10.1
5
true
${project.artifactId}-${project.version}
true
${project.groupId}
myapp-war
/APP
(...)
${project.groupId}
myapp-war
${project.version}
war
Behaviour with m-ear-p 2.10.1:
Deploying the EAR to Wildfly creates a folder in /
standalone/deployments/, and in this folder my war is extracted in a
folder myapp-war-.war. This is also referenced in the generated
application.xml:
web-uri: myapp-war-.war
So far, so good.
Behaviour with m-ear-p 3.0.0:
The same folders are generated, i.e. in
/standalone/deployments/ and myapp-war-${version}.war inside
it, but the generated application.xml now has a different web-uri:
web-uri: -myapp-war-.war
Result:
After the copying process has finished, Wildfly doesn't start the EAR
because it cannot find the WAR module that is referenced in the
application.xml
Who is causing this strange behaviour? The JBoss/Wildfly integration in
Eclipse? m2e? ...?
And what can I do to make it work again (apart from sticking with m-ear-p
2.10.1)?
Interesting side effect:
Building the EAR via command line works and generates a correct EAR, i.e.
contains the WAR module with the groupId in its name.
Best regards
Thorsten
Re: Source build of CloudStack versions 4.8.11 and 4.9.0.1 fails
Hi Max,
> I am getting the following error when I do a source build on version
4.8.11
> and 4.9.0.1 (mvn -P deps is the command I run):
>
> ---
> BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 7.442s
> [INFO] Finished at: Tue Nov 29 14:10:59 IST 2016
> [INFO] Final Memory: 31M/74M
> [INFO]
>
> [WARNING] The requested profile "deps" could not be activated because it
> does not exist.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
> cloudstack-checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or
one
> of its dependencies could not be resolved: Failure to find
> org.apache.cloudstack:checkstyle:jar:4.8.1.1H in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central
has
> elapsed or updates are forced -> [Help 1]
> [ERROR]
> --
>
> Not clear how to fix this. Thanks in advance for all the help,
Have a look at the message:
You're activating a profile on the command line ("-P deps") that obviously
doesn't exist. What are you trying to do?
Regards
Thorsten
Re: [ANN] Apache Maven JAR Plugin Version 3.0.1 Released
Hi, > I also see that there is a v0.17.1 of the connector. > http://repo.maven.apache.org/maven2/.m2e/connectors/m2eclipse-mavenarchiver/0.17.1/N/LATEST/ > Have you tried that? I have absolutely no clue what the difference is > though...:-) Yes, same result > > You should probably move this to the m2e list instead. It might require > > another change to the mavenarchiver connector. Ok, will do that. Thanks :) Thorsten -- View this message in context: http://maven.40175.n5.nabble.com/ANN-Apache-Maven-JAR-Plugin-Version-3-0-1-Released-tp5871579p5872086.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: [ANN] Apache Maven JAR Plugin Version 3.0.1 Released
Hi, using version 3.0.1 inside Eclipse, I now get the following error after updating my project(s): Error message: org.codehaus.plexus.archiver.jar.Manifest.write(java.io.PrintWriter) Resource: pom.xml Path: / Location: line 1 Type: Maven Configuration Problem This sounds like a similar problem I had with version 3.0.0; see https://issues.apache.org/jira/browse/MJAR-222. Do you have any information what is causing this behaviour? I'm using - Eclipse Neon (4.6.0RC3) - m2e 1.7.0.20160531-2022 - m2e connector for mavenarchiver from the link in MJAR-222 - Java 1.8.0_92 Side note: Building from the command line works; the error only occurs in Eclipse... Regards Thorsten khmarbaise wrote > The Apache Maven team is pleased to announce the release of the > Apache Maven JAR Plugin Version 3.0.1. > > https://maven.apache.org/plugins/maven-jar-plugin/ > > Important Note: > > * Maven 3.X only > * JDK 6 minimum requirement > > You should specify the version in your project's plugin configuration: > > > > > org.apache.maven.plugins > > > > maven-jar-plugin > > > > 3.0.1 > > > You can download the appropriate sources etc. from the download page: > > https://maven.apache.org/plugins/maven-jar-plugin/download.cgi > > Release Notes Maven JAR Plugin 3.0.1 > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526&version=12335708 > > > Bug: > > * [MJAR-226] - Memory issues - Upgrade maven-archiver to 3.1.0 > > Improvements: > > * [MJAR-219] - Improve confusing text wrt Jarsigner plugin on Usage page > * [MJAR-225] - Upgrade maven-plugins to version 30 > * [MJAR-227] - Upgrade of 'plexus-archiver' to version 3.3. > > Enjos, > > -The Apache Maven team > > - > To unsubscribe, e-mail: > users-unsubscribe@.apache > For additional commands, e-mail: > users-help@.apache -- View this message in context: http://maven.40175.n5.nabble.com/ANN-Apache-Maven-JAR-Plugin-Version-3-0-1-Released-tp5871579p5872074.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: Best practices: m-release-p and svn:externals
Hello Robert, it's quite long ago that you answered my initial question, and I have been pretty busy with my $DAYJOB, but I wanted to say thanks for the pointers you gave. Using these hints I finally figured out how to realize such a feature and just added a quite simple patch to the Maven SCM plugin that allows to use the "--pin-externals" option with a Subversion 1.9.x client: https://issues.apache.org/jira/browse/MRELEASE-549 Regards Thorsten -- View this message in context: http://maven.40175.n5.nabble.com/Best-practices-m-release-p-and-svn-externals-tp5855187p5866324.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
Best practices: m-release-p and svn:externals
Hi, I have a few Maven projects that use svn:externals to link to code and/or resources stored in different paths in our Subversion repository. Compiling, packaging, deploying etc, works fine; even creating releases with m-release-p (release:prepare && release:perform). The svn:externals I'm actually using refer to files / folders in the trunk, not fixed versions. Example: ^/trunk/projectA/fileA fileA Therefore, when you check out a tagged release created with m-release-p somewhere in the future, the checked out files could be different compared to the time the release was created. To prevent this, I'm actually manually changing the svn:externals definition in the tagged release to reference fixed versions of the desired files/folders after m-release-p is finished: -r ^/trunk/projectA/fileA fileA Is there a way to automate this? According to the release notes of Subversion 1.9, there's a new option "--pin-externals" available for "svn copy". Is it possible to use that? If yes, how can I do this? I've also found this plugin here: https://github.com/MartinMReed/maven-svn-plugin What do you think? Regards Thorsten
Re: Re: [VOTE] Change project logo and adopt owl as mascot
+1 Thorsten Arnaud Héritier schrieb am 25.11.2014 12:01:00: > Von: Arnaud Héritier > An: Maven Developers List > Kopie: Maven Users List > Datum: 25.11.2014 12:02 > Betreff: Re: [VOTE] Change project logo and adopt owl as mascot > > +1 > > thx > > On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > +1 > > > > On 25 November 2014 at 10:57, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > For anyone who has been living under a rock, here is the background > > > > > > Background > > > = > > > > > > I think everyone can agree that the site needs a reorganisation and a > > > rewrite. Users cannot find what they need, and the end result is that > > > people keep on abusing maven rather than having maven help them. > > > > > > Try as I might, I have been unable to motivate myself to do the > > > reorganisation with the current dated look and feel of the site... I am > > not > > > saying that picking a new logo and selecting a mascot will result in > > making > > > progress, but it can't hurt and I believe it will help > > > > > > Proposed changes > > > === > > > > > > 1. Change the logo font to Alte Haas Grotesk Bold with italics applied by > > > Inkscape > > > 2. Change the highlighted letter from 'a' to 'v' and replace the v with > > > two Apache Feathers > > > 3. Adopt the (currently unnamed) owl as our mascot > > > > > > Here is a link to the font: > > > > > > http://www.dafont.com/alte-haas-grotesk.font > > > > > > Here is a large version of the owl and the logo: > > > > > > > > > > > http://people.apache.org/~stephenc/maven-logo-contest/maven-owl- > final-large.png > > > > > > A regular version of the own and the logo, e.g. a size suitable for use > > in > > > the top of the standard maven sites: > > > > > > > > http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final.png > > > > > > (Note that in all likelihood, the mascot would probably end up on the > > > other side of the title bar from the logo... and that is IF the mascot > > ends > > > up on the title bar) > > > > > > Here is both of those rendered in a site (as it can be helpful to see the > > > graphics adjacent to text) > > > > > > > > > > > http://people.apache.org/~stephenc/maven-logo-contest/maven-owl- > final-context.png > > > > > > > > > Logo Rational > > > === > > > > > > If we do some searches for the Maven logo: > > > > > > > > > > > https://www.google.com/search?site=imghp&tbm=isch&q=maven+logo&oq=maven+logo > > > > > > > > > > > http://www.bing.com/images/search?q=maven > +logo&go=Submit&qs=n&form=QBLH&scope=images&pq=maven+logo > > > > > > Our current logo, with a single highlighted letter stands out quite well > > > from the other "maven" logos, so keeping a highlighted letter and an > > italic > > > rendered font maintains continuity with our current logo. > > > > > > By changing the highlighted letter to the `v` and by using two Apache > > > feathers to create the `v`, we connect our logo back to Apache... we are > > > Apache Maven after all. > > > > > > The `v` is also the common short term for version (e.g.v3 is short for > > > version 3). Apache Maven puts a lot of emphasis on versions of > > dependencies > > > and plugins... you could say that versions are very important to Maven. > > > > > > The colours of the feather were changed to solid colours to match the owl > > > mascot's scarf, beak and eyebrows > > > > > > Voting rules > > > = > > > > > > Anyone who is subscribed to the dev or users list is eligible to vote. > > > > > > If you vote multiple times, only your final vote will be counted. > > > > > > The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014 > > > > > > The vote is for all three changes as one single change. Partial votes > > > (e.g. for the logo but not the mascot, or vice-versa) will not be > > counted. > > > > > > I, as the caller of the vote, reserve the right to cancel the vote if > > this > > > vote is putting the harmony of the community at risk. > > > > > > If a majority of the PMC believe that this vote is putting the harmony of > > > the community at risk, then the PMC may cancel this vote (though if even > > a > > > small minority of the PMC were of that belief, I will more than likely > > have > > > cancelled the vote before the PMC would need to decide... I'm just > > stating > > > this FTR) > > > > > > The decision will be a simple majority, there will be no special veto > > > powers. > > > > > > +1: [ ] Change the logo to the proposed logo and adopt the owl as project > > > mascot > > > 0: [ ] No opinion > > > -1: [ ] No change > > > > > > Please only respond with +1, 0 or -1. If you want to discuss the proposed > > > changes please use a different thread. This thread is for voting only. > > > > > > -Stephen > > > > > > > > > -- > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/S
Re: Re: Status of MRELEASE-835?
Hi Sascha, > > [...] > > I just wanted to know what the actual status is? Is there no need for such > > a IMHO usable and CI- and/or build-server friendly feature? Is there > > anything missing in the issue/patch/description/...? > > At least a comment such as "I'll look into that" would be nice :-) > > From my POV I can clearly say that this IS something I would like to see > it in the release plugin :) > > You can "work around" it by having a pre-step in the CI / build-server > using the http://mojo.codehaus.org/versions-maven-plugin/ plugin > (versions:use-releases / use-next-releases or use-latest-releases). All > a bit clumsy, but you can make it work. I know, but in that case you won't have the modified poms checked in into your SCM; you have to add at least another step to check for local modifications in combination with an optional SCM commit. If your CI / build server has lots of projects, well, :-) Apart from that, imagine the following scenario: Your pom.xml references a dependency in version, say, 1.2.3-SNAPSHOT. Your repo contains - 1.2.3 (release) - 2.0.0 where 2.0.0 has incompatible changes compared to 1.2.3. With "versions:use-latest-release", you'll eventually get an unreleasable artifact because it doesn't compile. The feature request in MRELEASE-835 and the provided patch avoids that. Greetings Thorsten
Status of MRELEASE-835?
Hi, last year in april I added an enhancement request for the release plugin that allows a user to automatically resolve snapshot dependencies in release:prepare, i.e. there's no interaction necessary; see MRELEASE-835. I also added a patch I made using the source code of version 2.4.1 that is still applicable even the recently released version 2.5. Since the issue was added, there has been no activity on it; it also isn't assigned to someone, and as far as I have seen there have been at least two similar requests: * MRELEASE-463 from 2009 (also with a patch provided) * MRELEASE-854 from last november, marked as duplicate of MRELEASE-463 I just wanted to know what the actual status is? Is there no need for such a IMHO usable and CI- and/or build-server friendly feature? Is there anything missing in the issue/patch/description/...? At least a comment such as "I'll look into that" would be nice :-) Regards Thorsten
Re: release-plugin non-interactive release and system properties
Hi Steve, > I’m confused as to how the version number in a pom file and the > system properties like -DdevelopmentVersion=2.0-SNAPSHOT and - > DreleaseVersion=1.2 > interact. > When I run a mvn –B release:prepare –DdryRun=true –Dtag=1.2 - > DdevelopmentVersion=2.0-SNAPSHOT -DreleaseVersion=1.2 for a pom.xml > where 1.0 and jar the > resulting jar file uses the pom version number not the command line > version, i.e xxx-1.0.jar . Is this expected behaviour and if so what > is the point of specifying the versions on the command line ? AFAIK this will only work when you have a snapshot version in your pom, i.e. 1.0-SNAPSHOT. Regards Thorsten
Re: maven deploy plugin fails with artifact-not-found
Hi, > I’m trying to deploy a snapshot version of the artifact for the first time. > Maven deploy fails with error “could not find artifact in the remote > repository” > Obviously the artifact was never deployed in the remote repository, > so it is not available in the remote repository. > > Tried with various versions of “deploy” plugin, the issue happens in > all of them. > > How to deploy a snapshot version on an empty repository? > > > $mvn org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy You try to deploy something that has to be built first, a step that is skipped in your case. Try "mvn deploy" instead. HTH Thorsten
Re: Jacoco:check - pom example?
Hi,
> Under build I have:
>
>
> org.jacoco
> jacoco-maven-plugin
> ${version.jacoco}
>
>
> prepare
>
> prepare-agent
>
>
>
> verify
>
>
>
> BUNDLE
>
>
> INSTRUCTION
> COVEREDRATIO
> 0.15
>
>
> CLASS
> MISSEDCOUNT
> 0
>
>
>
>
>
>
>
> report
> prepare-package
>
> report
>
>
>
>
*snip*
> I'm guessing that I've added the instruction the the pom incorrectly but
> the documentation lacks an in-context example. Can anyone shed light on
> this?
Just a guess:
You didn't specify a phase for the executions with id "prepare" and
"verify"...?
Regards
Thorsten
Re: Re: Nexus deployment of a ZIP file...
Hi, > Yup, this is a surprising repetition, agreed, but that's "normal". > Please file an enhancement request about that, I guess this might be > something fixable. I haven't used deploy:deploy-file from the command line for a longer time, but can't you omit groupId, artifactId etc. when you specify a pom.xml as a parameter (-DpomFile=)? See https://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html HTH Thorsten
Re: use properties within settings.xml
Hi,
> I would like to setup profiles with username and password as properties.
> Then I would like to use the properties in the servers/server tags in
the
> same file.
> Something like the following:
> profile>
> old-nexus
>
> true
>
>
> me
>
>
>
>
>
> releases
> ${nexus.username}
>
> When I do this ${nexus.username} is not replaced with me.
>
> Am I doing anything wrong or is it not possible?
As far as I know you can only use these properties in your pom.xml, but
not in the settings.xml file itself.
Thorsten
Re: String index out of range: -12 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
Hi, > maven-release-plugin:2.4:prepare failed: String index out of range: -12 > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:225) *snip* Have you tried running "mvn -e -X ..."? Perhaps there's something missing in your pom.xml, such as an invalid property that is referenced somewhere, an empty or missing plugin configuration section etc.pp. HTH Thorsten
Re: Maven dependencies - best practice
Hi, > I am testing the Maven dependecies. In a parent-child project arhitecture I > am using many frameworks > (log4j, xdoclet, etc) and these are installed in may local repository and I > am able to use them. > > I created and installed a POM, called "x-deps", to manage the dependecies: *snip* > > 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";> > 4.0.0 > sk > x-deps > 0.0.1-SNAPSHOT > pom > > > > log4j > log4j > 1.2.8 > > > xdoclet > xdoclet > 2.0.3 > > > > > > In a parent POM, called "a", I set the dependecyManager for "x-deps": > > 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";> > 4.0.0 > sk > a > 0.0.1-SNAPSHOT > pom > > ../b > > > > > sk > x-deps > 0.0.1-SNAPSHOT > pom > > > > > > In its child POM, called "b", I would like to add the dependency only for > log4j: > > 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";> > 4.0.0 > b > > sk > a > 0.0.1-SNAPSHOT > > > > log4j > log4j > > > > > When I want to validate my POM "a" I get this error: > > error: 'dependencies.dependency.version' for log4j:logj:jar is missing > > Can somebody help me? Quite easy: In the referenced parent sk:a:0.0.1-SNAPSHOT you only manage a dependency for sk:x-deps:0.0.1-SNAPSHOT (which isn't used in b, btw), but not for the real dependencies you're using in your project b... To use them, move the dependency management section from x-deps to your project a. That should do the trick. HTH Thorsten
Re: Re: Escape '*' in property command line
Hi, > I did try single quotes, unfortunately that did not work either. > > I modified the maven script to print out is quoted args variable, > looks like it did some sort of filename expansion with the '*' > character. > > When I perform: > echo "0 0 23 * * *" I get: > 0 0 23 * * *, as one would expect. > > Seems like a bug in the maven script that is creating the QUOTED_ARGS > variable at the beginning of the script. Have you tried to escape the "*" with a backslash, i.e. '\*'? HTH Thorsten
Re: Re: Some questions about Webby
Hi Miguel, > Did you manage to figure out this? I've just asked the exact same > thing in m2e's mailing list! No, and I haven't used Webby since then anymore... :-) I just read your mail on m2e, and Benjamin told you a workaround that sounds good, although I have to admit that I didn't try it... Regards Thorsten
Re: Re: Why does mvn compiile using java 1.3?
Hi, > I have never seen any java application fail just because I run the > version 7 VM. Even really old code still runs. A couple of Atlassian applications I work with in our department that didn't run (fine) with Java 7: - JIRA <= 5.1.x (5.2 was released ~3 weeks ago) - Bamboo <= 3.2.x (3.3 was released 11 october 2011) - Confluence <= 4.1.x (4.2 was released 10 april 2012) etc. It took quite a long time for the manufacturer to implement the necessary changes to let their products work with Java 7. JIRA for example wouldn't even start correctly when using 1.7.* and instead threw lots of exceptions in its log, whereas for at least Confluence 4.1.x there were some workarounds to let it run with a JVM 7... In our department we had a very old legacy application written by some colleagues back in the days of Java 1.2 when the first Swing UI came out. They told me they had lots of problems with former Swing UI bugs and programmed workarounds to get the application finally work with Java 1.4. These workarounds didn't work correct anymore with Java 5 (Swing bugs were fixed?), i.e. the application's UI had some nice "features" a.k.a bugs :-o Unfortunately they weren't given the time to fix them (you know, the usual problems with sales that had other priorities...) so they had to stick with Java 1.4 until ~2.5 years ago (!), until the application finally died about one year ago. That's life... Regards Thorsten
Re: Maven Shade Plugin - XmlAppendingTransformer cannot be loaded
Hi Benjamin, > I'm running into an error when trying to build my project using the > shade plugin. I need to merge some XML-Files, so the interesting > part of my pom.xml looks like this: *snip* > > implementation="org.apache.maven.plugins.shade.resource.XmlAppendingTrans > former"> ^^ > Stacktrace: > > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade- > plugin:1.4:shade (default) on project validator: Unable to parse > configuration of mojo org.apache.maven.plugins:maven-shade-plugin:1. > 4:shade: ClassNotFoundException: Class name which was explicitly > given in configuration using 'implementation' attribute: > 'org.apache.maven.plugins.shade.resource.XmlAppendingTransformer' > cannot be loaded -> [Help 1] Have a look at the error message: Obviously you have a spelling error in your transformer declaration; see above... HTH Thorsten
Re: Re: Re: How to zip the source code separately using Maven
Hi, > I wanted only source code but it tries to combine the whole project content > with Jar and etc. I am getting the following error. > > Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.3:assembly (make-assembly) > on project ABCServices: Error reading assemblies: No assembly descriptors > found. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException You haven't said what you have done so far. Have you really read the link you were given? They contain several examples how to use these plugins. Apart from that: If you don't give any information about what you have done, how your project is structured, how your pom.xml looks like, how you trigger Maven, what you did to see the above mentioned error etc., nobody is able and possibly even willing to help you resolve your problems... HTH Thorsten
Re: Re: How to zip the source code separately using Maven
Hi, > can somebody give me the sample code... Please read the links you were given. What have you tried so far? And what problems do you still have? Regards Thorsten
Antwort: How to zip the source code separately using Maven
Hi, > Please tell me how we can add a task in POM.xml file to zip the source code > separately while build the application. I want both .war file and .zip files > independent of each other. https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html https://maven.apache.org/plugins/maven-source-plugin/ ? HTH Thorsten
Re: JDK - Maven - Orekit - Re-configure / Output Charts { Look/Feel}
Hi,
> Essentially all i wanted to do was get this
> http://www.iers.org/nn_11252/IERS/EN/DataProducts/
> EarthOrientationData/__Function/Plots__GpsrapidDaily/
> generischeTabelle__Diagramm.html
> data series and reconfigure the output charts. { Look/Feel }
> And redisplay them on a website.
>
> I understand that the data series is being formatted using "
> https://www.orekit.org/static/index.html Orekit " Which is a plugin
built
> upon Maven and therefore needs jdk. { All areas which are new, but I
should
> be able to pick it up }
>
> I thought initially what I wanted to do would be relatively
straightforward,
> but this is how I understand the workflow required for what I'd like to
do.
>
> If anyone has a simpler/quicker method to mind // would be really
helpful
What you you want to do at all? What kind of question(s) do you have? I
don't get it to be honest...
Perhaps you should describe what you already did, what you expected to
happen, what really happened etc.
Cheers
Thorsten
PS: I assume that you know the following pages:
- http://maven.apache.org/users/index.html
- http://maven.apache.org/guides/index.html
- http://docs.codehaus.org/display/MAVENUSER/Home
Re: jdk for os 10.5.8
Hi, > Hi can any one advise which jdk for os 10.5.8 / would be good to start with , > im new to maven . and just starting out If you're on Mac OS X < 10.7, then you have to live with the JDK Apple is providing: - Java 5 for 10.5.x (*) - Java 6 for 10.6.x (*) I'm not sure, but I guess I have seen some Java 6 versions also for 10.5, but only for 64-bit machines. HTH Thorsten PS: http://support.apple.com/downloads/?val=java+for+mac+os+x+10.5#java for mac os x 10.5
Re: pom
Hi, > I import a maven project with the pom file which is included in > attach. There are no attachments in your mail. > eclipse report this error : > > Plugin execution not covered by lifecycle configuration: > org.mule.tools:maven-mule-plugin:1.7:attach-test-resources > (execution: default-attach-test-resources, phase: validate) > > Plugin execution not covered by lifecycle configuration: > org.mule.tools:maven-mule-plugin:1.7:filter-resources (execution: > default-filter-resources, phase: process-resources) > > Please tell how to resolve it . Thank you ! http://lmgtfy.com/?q=Plugin+execution+not+covered+by+lifecycle+configuration => http://wiki.eclipse.org/M2E_plugin_execution_not_covered HTH Thorsten
Antwort: Maven + Spring 3.1.2.RELEASE Error
Hi, > I'm trying to build a project using Maven to package the latest spring > 3.1.2.RELEASE jars into a war file. For some reason, it's pulling the latest > version for some of the spring modules, but not for all of them. For > example, the 3.1.2.RELEASE spring-orm module is downloaded, but the 3.0.0.GA > spring-core module is downloaded... Can anyone tell me why this could be > happening? I'm not nesting or inheriting pom.xml files. I've pasted part of > my pom.xml below: I don't use Spring, but have you tried "mvn help:effective-pom"? HTH Thorsten
Re: Error in deploying war file
Hi, > and create resources, webapp folders in Myapplication\src\main > and inside resources i created 3 folders hibernate, properties and spring. > in hibernate i kept all .hbm.xml files, in properties all properties files, > and in spring again i created 3 folders beans, config and database. > in beans i kept dispatch-servlet.xml and in database i kept > hibernate.cfg.xml. >in webapp i created WebINF\pages inside WebINF i kept web.xml and inside > the pages folder i kept all jsp pages... I don't know if this is simply a spelling error in your mail, but that folder is normally called WEB-INF, not WebINF... Apart from that, why do you add lots of repository entries to your pom.xml? This is generally considered a bad idea, and I recommend to install a repository manager such as Nexus, Artifactory, Archiva etc. somewhere on your environment and point your Maven installation to that instance... HTH Thorsten PGP.sig Description: Signierter Teil der Nachricht
Re: How can I recursively build -SNAPSHOT dependencies present in the filesystem but outside the reactor?
Hi Chris, > Is there a neat way I could get Maven to perform a recursive build > that looks on the filesystem to find -SNAPSHOT dependency projects > and builds them? > I'm familiar with Maven plugin development, but haven't yet found > any clues toward a solution in the Maven / Aether documentation. I'd suggest you use a CI system such as Jenkins for that purpose: Jenkins parses the pom.xml files on Maven projects and automatically detects dependencies between jobs. If you start a certain job, Jenkins automatically triggers builds on all dependent subjobs, quite similar to what you want to achieve. I'd recommend to install the Upstream Downstream Column Plugin that adds two quite useful columns to Jenkins' job list: one that lists all "parent" jobs, and another with all subjobs as far as Jenkins has detected them. HTH Thorsten
Re: Create Error reading settings.xml: Unrecognised association: 'servers' error
Hi, > Can anyone help me to solve the following error which I got when I was using > atlassian. > > "Create Error reading settings.xml: Unrecognised association: 'servers' > (position: START _TAG seen ...ven must make a connection to a remote > server.\n |-->\n ... @110:12) Line: 110 Column: 12". It seems to me that your XML file contains invalid XML. Perhaps a tag is not correctly closed, misspelled, ... Regards Thorsten
Re: Re: apache httpd plugin
Hi,
> Yes, Starting/stopping
> Deploying to an instance (whatever that means)
>
> The most important thing I was thinking of is testing. That means
testing a
> web application with apache httpd and selenium. Testing a web app that
> requires mod_rewrite won't work at the moment because tomcat and jetty
are
> not aware of .htaccess and mod_rewrite and therefor the requests will
not
> be redirected to the correct php/perl/cgi scripts. Having a web.xml with
> servlet mappings that are similar to the .htaccess rewrite rules for
only
> supporting maven tests sounds not good for me.
Is it really necessary to start and stop a webserver from within Maven
solely for the purpose of testing? Wouldn't it be easier to simply let
Apache run in the background, for example on a dedicated machine or build
server etc., (re-)deploy your artifact(s) and then start testing?
If you still need starting/stopping the Apache instance from within a
Maven build, I'd suggest you have a look at the exec plugin ([1]) and
start and stop your Apache instance directly via "apachectl -k
{start,stop}".
[1] http://mojo.codehaus.org/exec-maven-plugin/
HTH
Thorsten
Re: How to do a release build in Maven?
Hi, > How can I do something similar in Maven, or how does Maven do a release > build? http://www.lmgtfy.com/?q=maven+release+build First link... Regards Thorsten
Some questions about Webby
Hi, today I decided to give Webby a try. Apart from Webby Core I also installed the embedded Jetty 8.x container. So far, so good. Some questions: a) How does Webby deal with dependencies having their scope set to "provided"? Our applications are mostly WARs / EARs that are deployed into WebSphere Application Server 7.x. Therefore a couple of dependencies such as javax.servlet:servlet-api or javax.mail:mail are specified in the pom.xml's with scope "provided". Using such an application with the embedded Jetty container results in ClassNotFoundExceptions; using a local Tomcat 7.x installation (on which I have the necessary jars copied into the lib folder) works, although it seems to me to take a bit longer for startup. b) Can I use Webby to debug web applications via HTTPS? The locally installed Tomcat instance is already configured for accepting SSL connections. This works well as long as I'm debugging my application via Eclipse, WTP and m2eclipse-wtp, but obviously not when using Webby. Creating a run or debug configuration lets me only choose a normal HTTP port, but there's nothing about HTTPS... Regards Thorsten
Re: javac: invalid target release: 1.7
Hi, > Mac OS X version 10.7.3 > java -version > java version "1.6.0_31" > > Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > (because required by project I want to build) > > The project I want to build is: > http://code.google.com/p/cmake-maven-project/source/browse/ > > The error I am getting when running mvn install is: > > > [ERROR] Failure executing javac, but could not parse the error: > javac: invalid target release: 1.7 > Usage: javac > use -help for a list of possible options > > I can't upgrade to java 1.7 (if this is the cause of the error). Yup. A compiler target 1.7 means Java 7 is needed for successful compilation. > Are there > other means to fix this? Install Oracle's recently released Java 7 port for MacOS X on your machine :-) HTH Thorsten
Re: Errors in maven build
Hi, > I have been getting the following errors while executing “man > package” for Jenkins plug-in. > The error log is attached here. IIRC I have seen that error when using Java 7 for packaging a Hudson/Jenkins plugin. Try to use Java 6 instead, that should do the trick. HTH Thorsten
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: Re: Re: maven compile error message format
Hi, > > ok thnak you very much. This was what I was expecting, however i could > not > > see what the issue was. Here are the lines in the code from line 1 on > > > > package com.huawei.cona.android.zeroconf; > > > > import java.io.IOException; > > > > import jmdns-1.0; > > import service-1.0; > > (...) > > Quite easy: These package names are invalid. See for example here: > http://java.about.com/od/i/g/identifier.htm Or better: http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isJavaIdentifierStart%28int%29 http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isJavaIdentifierPart%28int%29 HTH Thorsten
Re: Re: maven compile error message format
Hi, > ok thnak you very much. This was what I was expecting, however i could not > see what the issue was. Here are the lines in the code from line 1 on > > package com.huawei.cona.android.zeroconf; > > import java.io.IOException; > > import jmdns-1.0; > import service-1.0; (...) Quite easy: These package names are invalid. See for example here: http://java.about.com/od/i/g/identifier.htm HTH Thorsten
Re: eclipse plugin for maven using jdk 1.3
Hi, > I checked if the JRE in the Run AS configuration was 1.3 but it was not. Why > is the maven plugin using 1.3 is beyond my understanding. http://maven.apache.org/general.html#Compiling-J2SE-5 HTH Thorsten
Re: Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > When been over this several times on this list. You have to extract > the configuration out of the binary. You mustn't have a Maven build > that could generate different flavors of an artifact. Which one would > you deploy to the repository? Ok, this was a bit misleading by me. With "flavors" I just meant * mvn clean deploy by command or on a nightly base * mvn release:prepare release:perform final releases / pre-releases meant for an integration build and/or tests by our business department > If you can't separate the configuration out of the binary, you should > have multiple projects each one generate one of the flavors. +1 Regards Thorsten
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > > I'm using profiles at work for the sole purpose of deciding what to do > > with the build artifact, i.e. activating different deployment targets > > (application servers) for an EAR. > > I see this as a completely different task where you're simply using > Maven as a utility tool. When using Maven as a "build tool", you will > be deploying the artifacts to a repository. What you then do with the > artifacts after that (like e.g. publish to an app server) is outside > of the build story, and should be handled as a separate task. Ok, but in that case I'm just simplifying life: We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... Regards Thorsten
Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, > Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. > If you think you should be using profiles, think again. If you still > think they are the solution, please think it through once more. If you > still persist, go use Ant. > Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Regards Thorsten
Antwort: Maven error: Embedded error: Not a root project: org.sonar.api.batch.bootstrap.ProjectDefinition@1bc5130a
Hi, > running the command "mvn sonar:sonar" works fine on my project... > however attempting to run "mvn install" against the following POM > throws the stack trace below...can anyone explain this? thank you! Just a wild guess: You have specified that your project is an aggregator project: > pom and you want to run Sonar on a project that doesn't contain any sources...? Regards Thorsten
Re: The "perfect" reporting tool?
Hi, > I am in search for a nice way to compile all reports for a Maven build. > I have for instance JUnit results, findbugs results and code coverage > results (using Emma). > > The maven site plugin does not really aggregate info so that I can get > the total number of findbugs bugs so I started to look at the dashboard > plugin from codehaus, but that plugin does not seem to get developed any > more. And there is not way to support Emma in it either. What does your pom look like? And what version of Maven, site/findbugs/... plugins do you use? On my system I'm using a corporate parent pom containing a couple of profiles that, when activated, add Findbugs, Checkstyle and/or PMD reports to the generated website. Works pretty fine. Regards Thorsten
Re: Re: Added source directory still allows for compile errors
Hi, > > Yes, there are lots of source files in this generated directory. > > > > They were generated with the command wsdl2java > > Is there no plugin for wsdl2java that you could leverage? Generally > Maven plugins "tell" Maven about new source files to be compiled once > they are created, such that your usage of the build-helper would be > eliminated. What about this one: http://mojo.codehaus.org/axistools-maven-plugin/ It lets you generate Java code from WSDL files and vice-versa via Axis' Java2WSDL. A couple of months ago I've written an extension for m2eclipse so you can use this plugin from within Eclipse... Regards Thorsten
Re: Re: Antwort: eclipse plugin has a POM of its own
Hi Syed, > Yeah thats a good suggestion. Also can you tell me how to remove the > C:\RSA75Workspace\workspace/ blah blah to some thing relative to workspace?? > so that the POM is portable to another workspace. According to your initial post the effective pom lets me guess that you're using the standard directory layout. The absolute paths are the ones Maven resolves from your pom. As long as you don't have hardcoded entries in that file, your project should be perfectly portable to other workspaces/machines/users. You only have to take care if you're using relative paths, but as long as they are relative to your project, that shouldn't matter. If you have to use a different directory layout, I suggest you have a look at the documentation ([1]), especially [2]. Depending on the plugins you're using you should also have a look at their documentation ([3]); perhaps their configuration has to be adapted to fit your project layout. [1] http://maven.apache.org/guides/index.html [2] http://maven.apache.org/guides/mini/guide-using-one-source-directory.html [3] http://maven.apache.org/plugins/index.html Regards Thorsten
Antwort: eclipse plugin has a POM of its own
Hi,
>
>
>
>
C:\RSA75Workspace\workspace\finAppWeb\src
>
> C:\RSA75Workspace\workspace\finAppWeb\src\main
> \scripts
>
> C:\RSA75Workspace\workspace\finAppWeb\src\test
> \java
>
> C:\RSA75Workspace\workspace\finAppWeb\target\build
> \classes
>
> C:\RSA75Workspace\workspace\finAppWeb\target\test-
> classes
*snip*
Just a side note:
I have made the experience that backslashes in files are treated by Java
more or less often as a quoting character. To prevent strange errors I'd
recommend either using forward slashes ('/'; should also work as directory
separator under Java in Windows environments), or a double backslash '\\'.
HTH
Thorsten
Re: AppAssembler and very long classpath
*bump*
Anyone?
"Thorsten Heit" schrieb am 13.02.2012 17:30:44:
> Von: "Thorsten Heit"
> An: Maven Users List
> Datum: 13.02.2012 17:31
> Betreff: AppAssembler and very long classpath
>
> Hi,
>
> I'm using the appassembler plugin to generate executable scripts for
> Windows and Unix machines. The resulting structure is basically the
> following:
>
>
> +- bin
> +- lib
> +- log
>
> My pom.xml contains:
>
>
> org.codehaus.mojo
> appassembler-maven-plugin
> 1.2
>
>
> attach-appassembler
> package
>
> assemble
>
>
>
>
>
> unix
> windows
>
>
> .sh
> .cmd
>
> ${project.build.directory}/myapp
> flat
> lib
>
> false includeConfigurationDirectoryInClasspath>
>
>
> my.app.Tool
> ${project.artifactId}
>
>
>
>
>
> No big magic, and until recently everything worked fine.
>
> Because lots of the dependencies that are used are being worked on and
> actually available only as snapshots, the generated class path at least
in
> the Windows script gets too long so that I cannot start my program
anymore
> on Windows machines.
>
> The mojo's FAQ page says that to solve this problem, one has to use
> "booter-windows" and/or "booter-unix" platforms. But how exactly do I
have
> to do this? Inserting these values as platform names results in an
error:
>
> "Non-valid default platform declared, supported types are: [windows,
unix]
> -> [Help 1]"
>
> The only other hint about "booter-unix" / "booter-windows" is under
"Usage
> -> Daemon" in the mojo documentation, but I cannot figure out how to
> create such a daemon mechanism...
>
>
> Can someone point me in the right direction and/or has a working
solution
> for that problem?
>
>
> Regards
>
> Thorsten
Antwort: RE: offline not truly offline?
Hi, > From my experience with the archetype plugin, it appears to ignore your > company proxies and mirrors and always and only goes to repo1 unless you > tell it otherwise > using -DarchetypeCatalog=http://your.company.repo/ or > -DarchetypeCatalog=local > > I don't have a proxy, but I do have everything redirecting via a mirror > to our Nexus repository and I still have to do the above to get it to > find my archetypes. http://jira.codehaus.org/browse/ARCHETYPE-283 http://jira.codehaus.org/browse/ARCHETYPE-358 HTH Thorsten
AppAssembler and very long classpath
Hi,
I'm using the appassembler plugin to generate executable scripts for
Windows and Unix machines. The resulting structure is basically the
following:
+- bin
+- lib
+- log
My pom.xml contains:
org.codehaus.mojo
appassembler-maven-plugin
1.2
attach-appassembler
package
assemble
unix
windows
.sh
.cmd
${project.build.directory}/myapp
flat
lib
false
my.app.Tool
${project.artifactId}
No big magic, and until recently everything worked fine.
Because lots of the dependencies that are used are being worked on and
actually available only as snapshots, the generated class path at least in
the Windows script gets too long so that I cannot start my program anymore
on Windows machines.
The mojo's FAQ page says that to solve this problem, one has to use
"booter-windows" and/or "booter-unix" platforms. But how exactly do I have
to do this? Inserting these values as platform names results in an error:
"Non-valid default platform declared, supported types are: [windows, unix]
-> [Help 1]"
The only other hint about "booter-unix" / "booter-windows" is under "Usage
-> Daemon" in the mojo documentation, but I cannot figure out how to
create such a daemon mechanism...
Can someone point me in the right direction and/or has a working solution
for that problem?
Regards
Thorsten
Re: Re: Deploy javadoc/sources for snapshots
Hi, > That's essentially what the profile would do. But it should be added > in the corporate parent so that not all projects need to specify it. > Also, and possibly more importantly, i don't want it to be bound to > the build lifecycle for the developers as it adds some significant > build time. It should only be executed on the CI (deploying snapshots > to the repo). So it has to be in a profile not active by default. Ok. What about the following idea: Add the javadoc and source plugin to build>>plugins in your parent pom, but without any configuration. Create two profiles, one for javadoc and one for source, and configure each plugin in profile > build > pluginManagement > plugin Then you should be able to optionally create javadoc and/or sources together with your normal build artifacts if you activate the corresponding profiles. This is basically what I'm doing in several EAR projects I'm working on with a couple of deployment targets specified in profiles in the parent pom. Regards Thorsten
Antwort: Deploy javadoc/sources for snapshots
Hi, > Anyone run into the desire to deploy javadoc and sources artifacts for > snapshots, in a similar fashion as done by the release-profile? If so, > how are you handling that? Add the following configuration to build>>plugins in your pom.xml: org.apache.maven.plugins maven-javadoc-plugin 2.8.1 attach-javadocs jar org.apache.maven.plugins maven-source-plugin 2.1.2 attach-sources verify jar-no-fork This is what I'm doing in a pluginManagement section in my parent pom. See: http://maven.apache.org/plugins/maven-javadoc-plugin/faq.html#How_to_deploy_Javadoc_jar_file http://maven.apache.org/plugins/maven-source-plugin/usage.html HTH Thorsten
Re: maven and wsdl2java
Hi, > Hi, I am trying to use maven to generate some client stubs for axis 1.4. > The below pom, runs without complaint, but it doesn't generate the > required ServiceLocator classes. If I download axis 1.4 and use the > standard wsdl2java from the command line, everything is fine. I have seen a similar behaviour recently with a WSDL I got from a colleague: The "generated" ServiceLocator file had a length of 0 bytes. Comparing the new WSDL with an older version showed me that there was an improperly set wsdlsoap:address entry: (...) ** http://server:port/some/more/stuff"/> (...) I replaced the line marked with "**" with http://webservices.test.srv.de"/> and the ServiceLocator was generated, i.e. the problem was solved... HTH Thorsten
Re: Plugin execution not covered by lifecycle configuration
Hi, >I stuck with the Plugin execution not covered by lifecycle > configuration while using flexmojos-maven-plugin and getting below warning > when doing maven build > > [WARNING] Some problems were encountered while building the effective model > for com.cccis.appraiser-management:appraiser-management:swf:2.1 > [WARNING] 'dependencies.dependency.scope' for > com.adobe.flex.framework:spark:swc must be one of [provided, compile, > runtime, test, system] but is 'theme'. @ line 80, column 11 > [WARNING] 'dependencies.dependency.scope' for > com.adobe.flex.framework:halo:swc:theme must be one of [provided, compile, > runtime, test, system] but is 'theme'. @ line 88, column 11 What don't you understand when you read that warning message? Regards Thorsten
Re: Installation glitch!
Hi, > I am a first time user of maven and new to open source in general. Congrats and welcome! > After running several different permutations and attempting to gain an > expected response from the command prompt using mvn –version the system > has proved to be not properly installed. The command mvn is not > recognised. I have a standard Windows 7 install with a fairly standard > AMD processor. Plenty of memory and disk space. > > Can anyone identify what might be causing this phenomenon on my machine? I assume you have installed Java on your machine...? Have you tried to logout and then login again before trying out "mvn --version"? Changing environment variables doesn't have any influence to already running programs... Regards Thorsten
Re: Creating an OS X Application
Hi, > Is there a plug-in somewhere that can help package a Java application as > an OS X application? Have a look at http://mojo.codehaus.org/osxappbundle-maven-plugin/ I have to admit that I haven't tried it; I can't tell how good it works... Cheers Thorsten
Re: Maven deploy question ...
Hi, > a) Run the entire mvn build with just the clean and deploy, but > deploy ONLY if all projects build and pass the tests properly > > b) Run the other installs, but when it comes to the deploy, not to > run the install again, just deploy what is already there. Have a look at http://wiki.hudson-ci.org/display/HUDSON/Join+Plugin or https://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin if you're using Jenkins. I haven't used that plugin by myself, but according to the docs it seems that it can be a solution for your problem. HTH Thorsten
Re: Re: UTF-8 Test Mystery
Hi Erik,
> once
>
> Doesn't help.
>
> I have some new insight on the problem. I changed my code to
>
> if (lambda.length() == 1)
> {
> char λ = lambda.charAt(0);
> if (λ != 'λ')
> //if (!lambda.equals("λ"))
> {
> // UTF-8 sanity check failed!
> println(System.err, "lambda = '" + lambda + "'");
> String message = "UTF-8 encoding problem for " +
> propertiesResource;
> println(System.err, message);
> throw new PropertiesError(message);
> }
> }
>
> This code works when built in Eclipse, but fails to compile from the
> command line with
*snip*
Can't you just use plain ASCII characters in your source code? This will
prevent you from such mysterious behaviour. And, as I wrote in an earlier
mail, replace non-ASCII-characters in strings by their Unicode value. In
that case, if I have seen right, replace the lambda char by \u03BB
(Unicode value of the Greek small letter lambda). Saves you a lot of
time
Regards
Thorsten
Antwort: UTF-8 Test Mystery
Hi Erik, > I am having trouble understanding a mystery. > > I have code that checks my .properties file to make sure that it has not > been corrupted after being edited by a non UTF-8 editor. In particular I > have a property called lambda = λ and I check to see that it actually > does resolve to the correct character. > > If I run my code from main (my manual unit test) it works. If I run my > test from JUnit in Eclipse, it works. But when the same test runs under > Maven it fails because lambda = ? I can understand your use case, and we have had similar problems in our department: Code was (is) built and tested locally on Windows PCs, but in production runs under AIX. From time to time we had problems with German umlauts because some guys hardcoded them in their Java code... The only solution that works cross-platform not only from within Java files, but also from property files is to replace non-ASCII-characters by their Unicode value. Example: before: String str = "Schließen"; // ^= "close" after: String str = ""Schlie\u00DFen"; Doesn't look as nice as before, right, and isn't directly readable, but prevents you from such troubles as you have. As I wrote, this also works for properties. HTH Thorsten
Re: Re: Incorrect assembly created with Maven 3.0.3
Hi, > Just a wild guess, do you have a dependencyManagament handling these > artifacts where the scope is defined? I've seen different behavior > between Maven 2.x and 3.0.x due to this (MJBOSSPACK-40 [1]). No, I haven't used dependency management. I simply referenced xerces and/or xalan (don't remember it exactly because I changed the project in the meantime...) Regards Thorsten
Antwort: Re: Incorrect assembly created with Maven 3.0.3
Hi, > Thorsten Heit wrote: > > > > ...snip ... > > > > But what puzzles me is that the archives created by Maven 2.2.1 and Maven > > 3.0.3 are different, and I don't see a reason why... > > > > ...snip... > > > > Hi there, > > Did you ever get anywhere with this? I'm seeing the same problem: Maven > 3.0.3 adds batik-js-1.7.jar and omits serializer-2.7.1.jar. > > Though I am not positive, I believe this is the cause of an exception I see > at runtime, the stack trace of which starts like this: > > java.lang.IllegalAccessError: > org/apache/xml/serializer/ExtendedContentHandler >at > org.apache.xalan.transformer.TransformerImpl.createSerializationHandler > (TransformerImpl.java:1233) > ... I get a ClassNotFoundException at runtime. I don't know exactly which class, but it was one from the serializer jar... Unfortunately the only solution I have so far is to directly add a dependency to the serializer jar in the pom although no class in the project uses it - it is used transitively by xerces or xalan I guess... Regards Thorsten
Re: Re: Setting site distribution URL in parent POM for entire company
Hi,
> Thanks for the example. This is quite similar to what I'm trying to do.
But
> if I do it like this, Maven will deploy my site under:
>
> scp://.../${parent.groupId}/${parent.artifactId}/$
> {parent.version}/../../../${project.groupId}/${project.artifactId}/$
> {project.version}/${project.artifactId}/
>
> I have no clue why the last artifactId is added.
>
> Also, I have no use for the artifactId. At my company we have unique
> groupIds for each project that would have a site.
>
> Anyway, I think I can just create an archetype that sets the deployment
URL.
> This would let me to provide a default site.xml as well.
I forgot to mention that I only set the properties and distribution
management in the parent pom; there's no need to overwrite them in a
depending project.
BTW, I'm using Maven 3.
Thorsten
Re: Setting site distribution URL in parent POM for entire company
Hi Lóránt,
> However, requiring each project to do this is rather error prone, so I'd
> like to define a pattern in the company parent POM, and have all
projects
> automatically derive their location from there.
>
> This doesn't work. If I set a location in our top-level POM to, say,
> "scp://maven-sites/var/www/", sites will be published to folders under
that
> location based on their artifactId. This means that I get URLs like
this:
>
> http://maven-sites.local/hello-parent/
> http://maven-sites.local/hello-parent/hello-core/
>
> I have several problems with this:
>
>- The URLs I get are not very nice.
>- The company POM's site gets published to the root location (
>http://maven-sites.local/), which causes all kinds of troubles.
>- If I have two projects with different groupIds, but with the same
>artifactId, their sites will collide.
>
> Is there an easy way to solve this, or should all projects define their
own
> site locations?
I'm doing something similar by using the following properties /
definitions in my parent (company) pom:
scp://myserver/var/apache2/2.2/htdocs/docs
http://myserver/docs
${base.site.url}/${project.groupId}/${project.artifactId}/${project.version}
...
releases-site
Published web sites
${distribution.repository.website}/${project.groupId}/${project.artifactId}/${project.version}
This lets all projects that use my parent pom deploy their websites under
the "/docs" subdirectory under my Apache's document root directory
"/var/apache2/2.2/htdocs/".
Note:
The group Id isn't "splitted" in several subdirectories, i.e. you'll end
up having "com.example/blah/1.0-SNAPSHOT" as path, not
"com/example/blah/1.0-SNAPSHOT".
Using the following default site.xml in my projects lets "mvn site-deploy"
resolve parent relationship links by using the links/urls given in the
parent pom:
http://maven.apache.org/DECORATION/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0
http://maven.apache.org/xsd/decoration-1.0.0.xsd";>
http://maven.apache.org/";
img="
http://maven.apache.org/images/logos/maven-feather.png"; />
HTH
Thorsten
release plugin: automatically resolving snapshot dependencies in non-interactive releases?
Hello, when I execute "mvn release:prepare" on a command line, I'm asked whether snapshot dependencies should be resolved. Is it possible to have them resolved automatically when preparing/performing a release in non-interactive mode? Ok, I could use "mvn versions:use-releases" to do this, but in that case I have to manually commit the pom if it has been changed... What do you think? BTW: I'm using release plugin 2.2 Regards Thorsten
Antwort: Re: Site deploy problem
Hi, > Oh I forgot... > > I use Maven 2.2.1 and maven-site-plugin version 2.3. > The behavior is the same on Windows and Linux. What kind of SCP transfer do you want to use? Password-less, i.e. public-key-authentification, or using username/password? In the first case: Did you upload your public key to the remote machine? In the latter case: You have to add a server entry section containing your user credentials in your $HOME/.m2/settings.xml: site-repo your_username your_password ... Regards Thorsten
Antwort: maven assembly plugin - chmod question
Hi,
> My assembly looks like:
>
>
> jar-with-dependencies
>
> zip
>
> false
>
>
> false
> runtime
> lib
> true
> 755
>
>
>
>
>
>
${project.build.directory}/${project.build.finalName}.jar
>
>
>
>
>
>
> So the fileMode works on the sub-elements. Each item in my LIB director
> gets a 755 CHMOD. But the actual LIB folder itself stays 777. Is there a
> way to make the LIB folder also get a 755?
What about 755 at the same hierarchy level
as ?
See http://maven.apache.org/xsd/assembly-1.1.2.xsd
Regards
Thorsten
Re: Incorrect assembly created with Maven 3.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, >> finally got ClassNotFoundException because of a missing dependency Jar in >> the lib folder; more precisely xalan:serializer:2.7.1 >> >> PS: I tested it with Maven 3.0.3 using Java 1.6.0_24, first on Solaris 11 >> Express and then on Mac OS X 10.6.7. > > Xalan and Xerces are special since they have been absorbed into the > JVM as of 1.4. In 1.5 they were basically shaded so now they are under > com.sun.* instead of directly under org.apache.* which was causing > problems. Xalan and Xerces are actually included because the versions in 1.4 / 1.5 are older than those available at apache.org. As far as I know they are needed by some legacy code for (de-)serialization of objects. I don't know if it is feasible to replace that code in short or mid term to make (better) usage of the capabilities provided directly by Java 6. > What class specifically is giving you the CNFE? I'm at home so I can't tell what class was causing this error. I'll see Monday when I'm at work, but I guess it was something like org/apache/xml/serializer/Serializer > Are you building and > then running your code with the same version etc of the JVM? Yes. But what puzzles me is that the archives created by Maven 2.2.1 and Maven 3.0.3 are different, and I don't see a reason why... > This may > be a situation where a jdk-specific profile is kicking in and > including (or not) a dependency during your build... or something else > of course. I don't use any profile, and the in-house dependencies I'm using also don't make usage of profiles. Thorsten -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNzlPbAAoJEFpUu7h4Il4IQ+cP/0Hg0YYDc4Uu3eVTGMqPYWd9 GeKmiUNw/mZHcR56aAUG1xgCjxfvtX1Ub3SGGNn8TKF4fNMboQv+YE41Ze8ALVC7 uX1TBu8LeWO3gq3qP7McsTxZ/+aVjYqv3RigEWEs/gOv9Z+oei3hYl8/c+9sr/sq c1TU+A6dZqjsBeEnp0/lNoGvPV6fe/Dg+GuO9XVBZsPf7f8trL16vUPmAuyFaEoy awN0+ZneWbMi3Ye/bTw6cCqePXIJW9UasP4uN/+QuEHokNbLixyXjd5AQ9dQhOKm Ov3Nf2xaFa99XGi8lIqiX0ds548hC/Ub8B04/5yyv2bKcyxKcuoIa9oxYb1LlyBB PV8VOQuVhz++mjdYVe7g70NklXI4uLo7kCxnOsfd8XgFnoxUjjj646AKpbiOwzHH ACn1DVN2ijBDfmGmfracJo7nwkdbuEKGNIqivTg87S3EzZNATErTbSlBM4Y1Fj7+ tJb0J7SUcQBxWt4jiJBqOva0/S7l+tveQGezpIrdsv4/OglTy3vLvGNL9+J+GQlm nlBRxsFcCVJkmhViBhNjuFAx1M6+g7pEjjxETl7OaZKtWJ0lDcoxUxQ/POfC5RKS grhykOtrW1xU4qAJCzI4OJ72Qv9z9p/ORwGy5DAFaGAvTUK8ClzzZJRwznkilcBo kV7bX6nN+bDhTzp//8P9 =Yfmg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Incorrect assembly created with Maven 3.0.3
Hi, I have a strange problem when building an assembly with Maven 3.0.3, and I don't know where to debug...: My project uses a combination of the appassembler mojo (1.1.1) and assembly plugin (2.2.1), both attached to the "package" phase, to create a tar.gz archive that basically has the following structure: my-prg/ my-prg/bin/ my-prg/bin/my-prg.cmd my-prg/bin/my-prg.sh my-prg/bin/local-log4j.xml my-prg/bin/log4j.dtd my-prg/lib/ (lots of Jar files) my-prg/log/ my-prg/log/readme.txt An end user unzips the archive and starts the program by one of the shell scripts (.cmd for Windows, .sh for Unix). Today I released a new version of my program, and just before informing my colleages that it's available I tested it by myself from a Windows box and finally got ClassNotFoundException because of a missing dependency Jar in the lib folder; more precisely xalan:serializer:2.7.1 Looking into the tar.gz archive I couldn't see that jar although it is used as a transitive compile-time dependency somewhere in the dependency tree of my program. The latter is verifiable by for example mvn dependency:tree: thorsten$ mvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building my-prg 0.4.6 [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ my-prg --- [INFO] prg:my-prg:jar:0.4.6 ... [INFO] | +- lib:v-base:jar:1.8:compile [INFO] | | +- org.apache.axis:axis-saaj:jar:1.4:compile [INFO] | | +- commons-logging:commons-logging:jar:1.1.1:compile (version managed from 1.0.4) [INFO] | | +- commons-validator:commons-validator:jar:1.0.2:compile [INFO] | | | +- commons-beanutils:commons-beanutils:jar:1.5:compile [INFO] | | | \- commons-collections:commons-collections:jar:2.1:compile [INFO] | | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | +- oro:oro:jar:2.0.8:compile [INFO] | | +- commons-discovery:commons-discovery:jar:0.4:compile [INFO] | | +- wsdl4j:wsdl4j:jar:1.6.1:compile [INFO] | | +- xerces:xercesImpl:jar:2.9.1:compile [INFO] | | \- xalan:xalan:jar:2.7.1:compile [INFO] | | \- xalan:serializer:jar:2.7.1:compile ... For curiosity I did a "mvn package" on my project by using Maven 2.2.1 and exactly the same code base. Comparing the resulting archives shows an interesting phenomenon: * The archive created by Maven 3.0.3 contains a dependency to org.apache.xmlgraphics:batik-js:1.7 (not shown by dependency:tree) and is missing one to xalan:serializer:jar * The archive created by Maven 2.2.1 contains only those dependencies that are listed in the dependency tree with scope "compile". >From my pom.xml: (...) src/main/resources ../my-prg org.apache.maven.plugins maven-compiler-plugin 2.3.2 1.6 1.6 org.apache.maven.plugins maven-deploy-plugin 2.5 org.apache.maven.plugins maven-javadoc-plugin 2.8 org.apache.maven.plugins maven-release-plugin 2.1 org.apache.maven.plugins maven-resources-plugin 2.5 org.apache.maven.plugins maven-scm-plugin 1.5 cvs_native install org.apache.maven.plugins maven-source-plugin 2.1.2 org.codehaus.mojo appassembler-maven-plugin 1.1.1 attach-appassembler package assemble
Re: Maven 3 and cargo plugin
> I have no clue. There shouldn't be any difference. I'm guessing there is
> some difference in your maven 2 and maven 3 execution environments.
Nope:
I unpacked the binary tar archives for both Maven 2 and 3 in /usr/local, i.e.
there are directories /usr/local/apache-maven-{2.2.1, 3.0.2}. There's a symlink
/usr/local/maven that points to the latest version, i.e. 3.0.2, and M2_REPO
defaults to this symlink. Therefore executing "mvn ..." from the command line
fires Maven 3.
When I want to use Maven 2 I only have to redirect the M2_REPO variable and
prepend the full path to the mvn shell script from the Maven 2 installation.
This is exactly what I did a couple of hours ago.
Regards
Thorsten
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 and cargo plugin
Hi, > You need to declare 'org.codehaus.cargo' as a pluginGroup in your > settings.xml: > > >org.codehaus.cargo > Ok, thanks, I'll try it tomorrow when I'm back at work. OTOH: Why can Maven 2 find the Cargo plugin without having the above section in the settings.xml? AFAIK M2 only searches in the groups org.apache.maven.plugins and org.codehaus.mojo, i.e. "mvn cargo:help" should normally not work out of the box, right? Best regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 and cargo plugin
Hi, > which version of the cargo plugin do you use? > > Can you give a snippet of your POM.xml where you configure cargo, cause i'm > using cargo with maven 3.0.X For testing purposes I only added the following minimalist configuration snippet to my pom.xml as explained on the Cargo website [1]: ... org.codehaus.cargo cargo-maven2-plugin ... I didn't specify a version so I assume Maven downloaded the newest available version. Using Maven 3 I get the mentioned error with "mvn cargo:help" whereas with Maven 2 the same command line works... [1] http://cargo.codehaus.org/Starting+and+stopping+a+container Regards Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
