Re: What's new in maven-compiler-plugin 3.0?
Hi, 2012/12/12 Jeff Care car...@gmail.com: Is there any documentation about what's new in maven-compiler-plugin 3.0 over the 2.5.1 version? I scoured the project site found nothing; various Google searches have also found nothing. After switching to maven-compiler-plugin 3.0 I'm seeing compilation problems that do not show up when using the 2.5.1 version, nor do they show up in Eclipse. I missed something in release notes. See coming new version doc: http://maven.apache.org/plugins-archives/maven-compiler-plugin-3.1-SNAPSHOT/ Since 3.0, the default compiler is javax.tools.JavaCompiler (if you are using java 1.6) and is used to compile Java sources. If you want to force the plugin using javac, you must configure the plugin option forceJavacCompilerUse. This can definitely show more warning than the previous versions of plexus compiler could missed. If you don't want that add configuration field on compiler plugin: forceJavacCompilerUsetrue/forceJavacCompilerUse or -Dmaven.compiler.forceJavacCompilerUse=true -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven and JEE Modules (Dependency WAR - EJB)
Hi, I want to build an EAR file with maven, containing 1 WAR, 1 EJB and 1 Utility JAR module. The WAR module is dependent from the EJB and the JAR, so a classpath entry must be written to the WAR's manifest for both modules (because the Utility JAR is not packaged into the lib/-folder within the EAR so it is not automatically in the classpath of the other modules.) But when enabling the manifest generation with classpath entries plugin artifactIdmaven-war-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath classpathPrefixutilities//classpathPrefix /manifest /archive /configuration /plugin the EJB module is also referenced within the manifest using the utilities/-subfolder - which is not correct, because it is packaged directly within the EAR file. Are there any solutions EXCEPT configuring manifest entries manually? Kind regards, Ralf Zahn ARS Computer und Consulting GmbH, http://www.ars.de Ridlerstrasse 55, 80339 Muenchen, Deutschland Application Development Services, Business Transformation Services, IT Infrastruktur Services Beratung und Vertrieb zu IBM Software, System x, POWER Systems, Storage License Management Services, IBM Passport Advantage Lizenzierung Handelsregister Muenchen, HRB 101829, USt-ID: DE 155 068 909 Geschaeftsfuehrer: Michael Arbesmeier, Kai-Uwe Rommel, Roland Schock, Joachim Gucker
Re: Release plugin ${project.version} dependencies
In our case the 2 projects will always have the same versions, so you're
correct, if we make a change to the project-windows then it will also
require a release of the project-main artifact. In practice though
project-windows rarely changes, while project-main is constantly in flux,
so that hasn't ever been an issue.
Potentially, these should probably be a single project. However, that would
involve more complexity and maintenance on our CI server and greater chance
for mistakes to happen than just having the 2 separate projects.
Why does it only ignore ${project.version} from the current reactor and not
for all dependencies? There must be something I'm missing, as I can't see
any downside to allowing it for any all dependencies.
Thanks,
Dan.
On 13 December 2012 20:37, Robert Scholte rfscho...@apache.org wrote:
Hi,
the maven-release-plugins only accepts ${project.version} for
reactor-projects, i.e. projects being part of a multi-module project.
The fact that your projects are separated also means that they both have
their own release-cycle. As you describe, they often(!) will be the same,
but if your MSI config is changed, does that require a new project-main? So
I understand why it was implemented like this.
You could change the value for allowTimestampedSnapshots[1] to true, but
then you've lost the check for all snapshots.
What you could probably do is combine this with the enforcer rule called
RequireReleaseDependencies[2] (have never done this myself though).
Robert
[1] http://maven.apache.org/**plugins/maven-release-plugin/**
prepare-mojo.html#**allowTimestampedSnapshotshttp://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots
[2] http://maven.apache.org/**enforcer/enforcer-rules/**
requireReleaseDeps.htmlhttp://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
Op Thu, 13 Dec 2012 13:51:06 +0100 schreef Dan Godfrey
daniel.godf...@gmail.com:
Hi,
I'm having trouble using the release-plugin on a project as it is
complaining that it has snapshot dependencies, even though those
dependencies are actually set to ${project.version}. So when the
dependency
check phase runs they are indeed SNAPSHOT dependencies, if it were to
continue then they would be updated to non-SNAPSHOT dependencies in a
later
phase.
I was wondering if anybody knows of anyway to get around this?
To explain why: I have 2 separate projects project-main project-windows.
project-main is a jar (well multiple jars)which are deployed to our local
repo. project-windows then takes that deployed jar and packages it up as
an
MSI. Both of these projects are kept in lockstep with regards version
numbers and have separate CI jobs. I've split the 2 projects up in
different SCM repos like this as we have have other CI jobs depending on
project-main for testing, and potentially in the future a project-linux,
etc.
Thanks,
Dan.
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
maven 3.0.4 installation issue on OEL linux 6 - quick question
Hi We have trouble installing Maven 304 -rw-r--r-- 1 root root7028 Dec 14 07:17 apache-maven-3.0.4-bin.tar.gz The checksum don't match. We tried downloading with Chrome or Firefox. Is there a simpler way, a step-by-step to show us ? Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Remove and Rename Files in MAven
Hi I have very simple question. I have the files like 1.)log4j_dev.properties for dev 2.)log4j_uat.properties for uat So i just want to 1.rename the file when the packagins is done and 2.How to pass the variable like Denv=DEV so that i can take decison based on the enviroemnt variable. Thanks Raj -- View this message in context: http://maven.40175.n5.nabble.com/Remove-and-Rename-Files-in-MAven-tp5738251.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: maven 3.0.4 installation issue on OEL linux 6 - quick question
-rw-r--r-- 1 root root7028 Dec 14 07:17 apache-maven-3.0.4-bin.tar.gz The checksum don't match. We tried downloading with Chrome or Firefox. 7028 bytes is clearly not the Maven tarball. I believe you have downloaded the HTML mirror redirection page. Try again. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove and Rename Files in MAven
Quick answer, If you want to do exactly what you asking, then I would use the antrun plugin to do that. Personally settings like this are always external, so the projects I'm working on create a zip with this files in, one for each environment and allow each environment to be altered without repackaging the war/ear/jar. Silly just to repackage and redeploy if you want different logging values. Our check log4j for changes and automatically pick that up. On 14 December 2012 15:49, godisone rajan.j...@verizonwireless.com wrote: Hi I have very simple question. I have the files like 1.)log4j_dev.properties for dev 2.)log4j_uat.properties for uat So i just want to 1.rename the file when the packagins is done and 2.How to pass the variable like Denv=DEV so that i can take decison based on the enviroemnt variable. Thanks Raj -- View this message in context: http://maven.40175.n5.nabble.com/Remove-and-Rename-Files-in-MAven-tp5738251.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Remove and Rename Files in MAven
No, i do need for logging but i have different licence files which need to be copied so i am loking for renaming them accoss different env. -- View this message in context: http://maven.40175.n5.nabble.com/Remove-and-Rename-Files-in-MAven-tp5738251p5738255.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: Remove and Rename Files in MAven
Two small assembly projects - one for uat one for dev. No code in either - just configuration and other stuff that is environment specific. On 14/12/2012 11:56 AM, godisone wrote: No, i do need for logging but i have different licence files which need to be copied so i am loking for renaming them accoss different env. -- View this message in context: http://maven.40175.n5.nabble.com/Remove-and-Rename-Files-in-MAven-tp5738251p5738255.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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Optional dependency not overlaid
Hi,
It appears we are using 2.0 of maven-war-plugin due to some incorrect
dependency graphs - at least that's what the comment says.
I'm testing maven-war-plugin with 2.3 right now, and I can confirm that
the optional dependency is overlaid.
However, it brings up a new problem. In my first email I mentioned that I
am overlaying with a skip parameter, as in:
//parent-of-everything/pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
overlays
overlay
artifactIdto-be-overlaid/artifactId
skip${exclude.optional.overlay}/skip
includes
include**/include
/includes
/overlay
overlay
!-- default self overlay --
/overlay
/overlays
/configuration
/plugin
So if the overlay is skipped, I don't want my files to show up, period.
The new problem is that the to-be-overlaid dependency, whether optional or
not, is included in my jetty webapp context, since it is a war dependency.
Since to-be-overlaid is in the context, the files are present at runtime.
The jetty-maven-plugin is part of the same profile in the
parent-of-everything/pom.xml
JettyWebAppContext@772eab80@772eab80/,[file:/Users/dwinsor/project/target/t
mp/webinf/, [file:/Users/dwinsor/project/src/main/webapp/,
jar:file:/Users/dwinsor/.m2/repository/to-be-overlaid-SNAPSHOT.war!/,
jar:file:/Users/dwinsor/project/target/some-webapp-war.war!/]],[file:/Users
/dwinsor/project/src/main/webapp/] started
So maybe I'm going about this the wrong way. What I want is to have test
files applied to a war in a development environment and totally absent
from a production environment. Am I on the right track and somehow
messing up, or am I on the wrong track and there's a better or easier way?
Thank you,
Daniel Winsor
Associate, IT Architecture
On 12/8/12 12:35 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Daniel,
The 2.0 version of Maven WAR Plugin is over 6 years old. The first thing
I'd do is try a later version to see if it solves your problem. The
latest version is 2.3.
On 2012-12-08 02:32, Winsor, Daniel wrote:
Hi,
I have declared an optional dependency, but it is not being overlaid
with maven-war-plugin v 2.0
//parent-of-everything/pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
overlays
overlay
artifactIdto-be-overlaid/artifactId
includes
include**/include
/includes
/overlay
overlay
!-- default self overlay --
/overlay
/overlays
/configuration
/plugin
//some-webapp-war/pom.xml
dependencies
dependency
artifactIdto-be-overlaid/artifactId
optionaltrue/optional
typewar/type
/dependency
/dependencies
When optional is set to false, then
[INFO] Assembling webapp some-webapp-war in /target/some-webapp-war
[INFO] Expanding: /.m2/repository/to-be-overlaid.war into
/target/to-be-overlaid
[INFO] Overlaying 1 war(s).
When optional is set to true, then no such overlaying happens.
However, according to optional dependencies, if some-webapp-war
optionally depends on to-be-overlaid, well it should show up in this
first level dependency, just like normal. What is going on here? And
how can I best overlay a war to certain other wars while leaving them
out of most wars using parent-of-everything (I am currently using a
property in the skip parameter in maven-war-plugin)?
Thank you,
Daniel Winsor
Associate, IT Architecture
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Dennis Lundberg
-
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: What's new in maven-compiler-plugin 3.0?
Wayne Fay wrote Can you be more specific (with error messages etc), or perhaps even create a little sample Maven project to share that demonstrates the issues you're seeing? Eclipse has its own compiler so it is not necessarily true that no failures in Eclipse means no failures when compiling with Oracle's JDK. These were errors, not warnings. I've since switched back to 2.5.1 so I don't have the exact messages but the one I specifically remember was a purported syntax error (class, interface or enum expected) on the same line (or one previous to) as the location of the package declaration. As I mentioned, the same file compiles fine after switching back to 2.5.1 also compiles fine in Eclipse. I attempted to put together a small test case but I wasn't able to replicate the problem. This build is very large (~150 modules) we are using multithreading; my supposition is that there's some combination of things that is messing up the compiler. I will be experimenting with single threading on 3.0 to see if I can replicate the problem that way on the real build. -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738296.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: What's new in maven-compiler-plugin 3.0?
olamy wrote Since 3.0, the default compiler is javax.tools.JavaCompiler (if you are using java 1.6) and is used to compile Java sources. If you want to force the plugin using javac, you must configure the plugin option forceJavacCompilerUse. This can definitely show more warning than the previous versions of plexus compiler could missed. If you don't want that add configuration field on compiler plugin: forceJavacCompilerUsetrue /forceJavacCompilerUse or -Dmaven.compiler.forceJavacCompilerUse=true Hmm, this is interesting. I will have to try this report back. -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738297.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: What's new in maven-compiler-plugin 3.0?
Anders Hammar wrote Do you mean compilation errors or warnings? There's some major changes in the the underlying plexus-compiler that will provide compilation info in a better way. So although you didn't see this in earlier version you might still have had the problems. They were errors in that they caused Maven to stop. In my test I had not changed any compiler plugin configuration settings, just the version. The specific error that I remember was about a syntax error (class, interface or enum expected) in a Java file that is syntactically correct. -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738298.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: What's new in maven-compiler-plugin 3.0?
The specific error that I remember was about a syntax error (class, interface or enum expected) in a Java file that is syntactically correct. OK, looks like a bug. Would be very good if you could reproduce this so it could get fixed. /Anders -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738298.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: Optional dependency not overlaid
I would create a separate module that builds the test overlay war file and
leave the production artifact unmolested always
On Friday, 14 December 2012, Winsor, Daniel wrote:
Hi,
It appears we are using 2.0 of maven-war-plugin due to some incorrect
dependency graphs - at least that's what the comment says.
I'm testing maven-war-plugin with 2.3 right now, and I can confirm that
the optional dependency is overlaid.
However, it brings up a new problem. In my first email I mentioned that I
am overlaying with a skip parameter, as in:
//parent-of-everything/pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
overlays
overlay
artifactIdto-be-overlaid/artifactId
skip${exclude.optional.overlay}/skip
includes
include**/include
/includes
/overlay
overlay
!-- default self overlay --
/overlay
/overlays
/configuration
/plugin
So if the overlay is skipped, I don't want my files to show up, period.
The new problem is that the to-be-overlaid dependency, whether optional or
not, is included in my jetty webapp context, since it is a war dependency.
Since to-be-overlaid is in the context, the files are present at runtime.
The jetty-maven-plugin is part of the same profile in the
parent-of-everything/pom.xml
JettyWebAppContext@772eab80
@772eab80/,[file:/Users/dwinsor/project/target/t
mp/webinf/, [file:/Users/dwinsor/project/src/main/webapp/,
jar:file:/Users/dwinsor/.m2/repository/to-be-overlaid-SNAPSHOT.war!/,
jar:file:/Users/dwinsor/project/target/some-webapp-war.war!/]],[file:/Users
/dwinsor/project/src/main/webapp/] started
So maybe I'm going about this the wrong way. What I want is to have test
files applied to a war in a development environment and totally absent
from a production environment. Am I on the right track and somehow
messing up, or am I on the wrong track and there's a better or easier way?
Thank you,
Daniel Winsor
Associate, IT Architecture
On 12/8/12 12:35 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Daniel,
The 2.0 version of Maven WAR Plugin is over 6 years old. The first thing
I'd do is try a later version to see if it solves your problem. The
latest version is 2.3.
On 2012-12-08 02:32, Winsor, Daniel wrote:
Hi,
I have declared an optional dependency, but it is not being overlaid
with maven-war-plugin v 2.0
//parent-of-everything/pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
overlays
overlay
artifactIdto-be-overlaid/artifactId
includes
include**/include
/includes
/overlay
overlay
!-- default self overlay --
/overlay
/overlays
/configuration
/plugin
//some-webapp-war/pom.xml
dependencies
dependency
artifactIdto-be-overlaid/artifactId
optionaltrue/optional
typewar/type
/dependency
/dependencies
When optional is set to false, then
[INFO] Assembling webapp some-webapp-war in /target/some-webapp-war
[INFO] Expanding: /.m2/repository/to-be-overlaid.war into
/target/to-be-overlaid
[INFO] Overlaying 1 war(s).
When optional is set to true, then no such overlaying happens.
However, according to optional dependencies, if some-webapp-war
optionally depends on to-be-overlaid, well it should show up in this
first level dependency, just like normal. What is going on here? And
how can I best overlay a war to certain other wars while leaving them
out of most wars using parent-of-everything (I am currently using a
property in the skip parameter in maven-war-plugin)?
Thank you,
Daniel Winsor
Associate, IT Architecture
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mai
Re: What's new in maven-compiler-plugin 3.0?
These were errors, not warnings. I've since switched back to 2.5.1 so I don't have the exact messages but the one I specifically remember was a purported syntax error (class, interface or enum expected) on the same line (or one previous to) as the location of the package declaration. As I mentioned, the same file compiles fine after switching back to 2.5.1 also compiles fine in Eclipse. Would be great if you could switch back to 3.0 and try again, then report back with the error details (ideally with a small sample) so it can be looked into and resolved if it is a problem/bug. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What's new in maven-compiler-plugin 3.0?
Anders Hammar wrote OK, looks like a bug. Would be very good if you could reproduce this so it could get fixed. I was able to confirm a few things: 1) Multi-threaded (-T 2C) builds with compiler plugin 3.0 consistently fail when *forceJavacCompilerUse* is false. 2) Single-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is false. 3) Multi-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is true. I wish I could put together a simple test case to demonstrate the issue but unfortunately I can't share the code where I am seeing the problem. Hopefully the above will yield some clues. Other potentially pertinent info: * java -version* java version 1.6.0 Java(TM) SE Runtime Environment (build pxa6460sr10-20111208_01(SR10)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr10-20111207_96808 (JIT enabled, AOT enabled) J9VM - 20111207_096808 JIT - r9_2007_21307ifx1 GC - 20110519_AA) JCL - 2004_02 * uname -a* Linux REDACTED 2.6.32-220.7.1.el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux * cat /proc/cpuinfo | grep processor | wc -l* 24 -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738310.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: What's new in maven-compiler-plugin 3.0?
Wayne Fay wrote Would be great if you could switch back to 3.0 and try again, then report back with the error details (ideally with a small sample) so it can be looked into and resolved if it is a problem/bug. Just responded to Anders with details of additional testing. Bottom line, 3.0 works for me single-threaded, or multithreaded when *forceJavacCompilerUse* is true, but fails otherwise. Unfortunately my small sample wasn't able to reproduce the problem. My hunch is that our combination of a large project (~150 modules) multi-threading (-T 2C on a 24-way box) is exposing a problem that a small sample wouldn't expose. -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738311.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: What's new in maven-compiler-plugin 3.0?
2012/12/14 Jeff Care ca...@us.ibm.com: Anders Hammar wrote OK, looks like a bug. Would be very good if you could reproduce this so it could get fixed. I was able to confirm a few things: 1) Multi-threaded (-T 2C) builds with compiler plugin 3.0 consistently fail when *forceJavacCompilerUse* is false. What you can do is to use compilerReuseStrategy parameter see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy maybe in your case alwaysNew can help. The compiler is very platform dependent (I have tested some but not this one :-) ) 2) Single-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is false. 3) Multi-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is true. I wish I could put together a simple test case to demonstrate the issue but unfortunately I can't share the code where I am seeing the problem. Hopefully the above will yield some clues. Other potentially pertinent info: * java -version* java version 1.6.0 Java(TM) SE Runtime Environment (build pxa6460sr10-20111208_01(SR10)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr10-20111207_96808 (JIT enabled, AOT enabled) J9VM - 20111207_096808 JIT - r9_2007_21307ifx1 GC - 20110519_AA) JCL - 2004_02 * uname -a* Linux REDACTED 2.6.32-220.7.1.el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux * cat /proc/cpuinfo | grep processor | wc -l* 24 -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738310.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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What's new in maven-compiler-plugin 3.0?
Could I please ask you to file a ticket with this info, so we have it on the board. Thanks, /Anders On Fri, Dec 14, 2012 at 11:16 PM, Jeff Care ca...@us.ibm.com wrote: Anders Hammar wrote OK, looks like a bug. Would be very good if you could reproduce this so it could get fixed. I was able to confirm a few things: 1) Multi-threaded (-T 2C) builds with compiler plugin 3.0 consistently fail when *forceJavacCompilerUse* is false. 2) Single-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is false. 3) Multi-threaded builds with compiler plugin 3.0 work fine when *forceJavacCompilerUse* is true. I wish I could put together a simple test case to demonstrate the issue but unfortunately I can't share the code where I am seeing the problem. Hopefully the above will yield some clues. Other potentially pertinent info: * java -version* java version 1.6.0 Java(TM) SE Runtime Environment (build pxa6460sr10-20111208_01(SR10)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr10-20111207_96808 (JIT enabled, AOT enabled) J9VM - 20111207_096808 JIT - r9_2007_21307ifx1 GC - 20110519_AA) JCL - 2004_02 * uname -a* Linux REDACTED 2.6.32-220.7.1.el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux * cat /proc/cpuinfo | grep processor | wc -l* 24 -- View this message in context: http://maven.40175.n5.nabble.com/What-s-new-in-maven-compiler-plugin-3-0-tp5738129p5738310.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
merging xml files with xml plugin
How to merge xml files with codehaus xml plugin? it runs xslt transform: one input file - one output file. I need to run xml transform on all input files, producing one output file. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
