Re: Maven profiles activations
Hi Rafael, Rafael Vanderlei wrote: Jörg, I understood when you first said that the way Maven is currently implemented it does not work this way. I'm just wondering if there is a suitable reason for that. So what I still dont understand is if a property declared in a parent pom can be used on the child pom for other purposes, WHY cant it be used to activate a profile defined in that child pom? Maybe it's just a matter that maven developers did not think about and maybe could be simply implemented to work this way. On top of Benjamin's answer you have to understand *when* Maven is resolving the profiles and *when* the properties. The properties are determined from the effective pom for the current project i.e. the project model that is the result of merging all inherited POMs and active profiles into the final one that is used to build the project. This effective pom *is* what defines your project build - including the properties, because they are part of your final project definition. The profiles are used to modify this project model for alternate builds, they create a different effective pom i.e. the result is more or less a different project. Since the properties are part of the model, they cannot be used to modify it again - this is the chicken and egg problem. In the light of this it is unfortunate that the tag in the activation is named property instead of systemProperty, because most people make the wrong association. Forget your assumption of evaluating the parent pom first - the model has to be complete to evaluate anything. As a consequence of this behavior you can use a property in the parent, but define (or overwrite) it in the child. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Could not launch cc: java.io.IOException: Cannot run program cc
Hi All,
I am getting a below error message during the maven build in cpp and c
package.
Embedded error: Could not launch cc: java.io.IOException: Cannot run
program cc (in directory
“/opt/project/test/target/nar/obj/sparc-SunOS-CC): error=9, Bad file number
I am facing this error after upgrading java to 16.0_24 not in 1.6.0_20.
Under /opt/project/test/src/main/ I have directory c, cpp, include and
resources.
Build is not compiling all c files.
--
Debug log:
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.cxx, **/*.cc, **/*.cpp] excludes: [] }
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.c] excludes: [] }
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.for, **/*.f] excludes: [] }
[DEBUG] Starting dependency analysis for 2 files.
Here it is analyzing dependency check for only cpp module not for c module.
Due to this build is failing.
--
But With Java 1.6.0_20 it does analysis for both c and cpp module.
[DEBUG] Adding reference: ant.ComponentHelper
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.cxx, **/*.cc, **/*.cpp] excludes: [] }
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.c] excludes: [] }
[DEBUG] ConditionalFileSet: Setup scanner in dir /opt/project/test/src/main
with patternSet{ includes: [**/*.for, **/*.f] excludes: [] }
[DEBUG] Starting dependency analysis for 41 files
Could you please help me to identify why the build is failing with java
1.6.0_24 not with 1.6.0_20.
Regards,
Kalai
--
View this message in context:
http://maven.40175.n5.nabble.com/Could-not-launch-cc-java-io-IOException-Cannot-run-program-cc-tp4263555p4263555.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
[ERROR] CC: Error in wait [DEBUG] Core 1 interrupted
Pending Alert: This post has NOT been accepted by the mailing list yet. Hi I am using maven for compiling c and cpp files. During the maven build the core 1 is compiling few files and it is waiting in some stage. [DEBUG] 41 total files to be compiled. [DEBUG] Found 8 processors available [DEBUG] Limited used processors to 2 ^M0 / 41 files compiled...^M[DEBUG] Starting Core 0 with 1 source files... [DEBUG] Starting Core 1 with 1 source files... - - - ^M3 / 41 files compiled...^M[ERROR] CC: Error in wait [DEBUG] Core 1 interrupted Due to this build is getting failed. I have upgraded my java to 1.6.0_24 from 1.6.0_20. Below is my debug log with successful case using jdk 1.6.0_20. [DEBUG] 41 total files to be compiled. [DEBUG] Found 12 processors available [DEBUG] Limited used processors to 2 [DEBUG] Starting Core 0 with 1 source files... ^M0 / 41 files compiled...[DEBUG] ^M - - ^M2 / 41 files compiled...^M^M2 / 41 files compiled...^M[ERROR] 2 Warning(s) detected. ^M3 / 41 files compiled...^M[DEBUG] Found 12 processors available [DEBUG] Starting Core 0 with 4 source files... [DEBUG] Starting Core 1 with 4 source files... [DEBUG] Starting Core 1 with 1 source files... --- - Please help me to solve the issue. Regards, Kalai -- View this message in context: http://maven.40175.n5.nabble.com/ERROR-CC-Error-in-wait-DEBUG-Core-1-interrupted-tp4263552p4263552.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
enforcer plugin rules to prevent circular dependencies
Hi, I've just discovered the enforcer plugin and would like to use it to reduce our dependency conflicts but a bigger problem for us when it does turn up are circular dependencies. The Dependency Tree plugin spots these, but does anyone have any rules for the enforcer plugin to fail the build if it occurs? Thanks Caoilte
Re: Re-using tests - best practice
Thanks for your comments Yegor, however you do not address the question, perhaps I did not put it well. What is the best way to re-use tests, given that Surefire will not discover tests in a jar and you cannot extend a non-pom project? I feel that the solution I have come up with is pretty clunky and would welcome a more elegant to the problem of test reuse. cheers Tim On 24 March 2011 08:08, Yegor Bugayenko wrote: What is the point of retesting a library which has already been tested? You need your own tests, that will check the validity of your own application, not a third-party library. If you want to reuse some code from the library - just get their .java files from their repository and add them to your project statically (don't forget to review their license restrictions). — Yegor Bugayenko, PMP®, SCEA On Tue, Mar 22, 2011 at 12:17 PM, Tim Pizey tim.pi...@gmail.com wrote: Hi, Atombeat http://code.google.com/p/atombeat/ has a set of possible configurations with different backends and security policies. atombeat-exist-full atombeat-exist-minimal atombeat-exist-full-secure atombeat-exist-minimal-secure atombeat-orbeon-full atombeat-orbeon-minimal atombeat-orbeon-full-secure atombeat-orbeon-minimal-secure Atombeat has a separate project which contains the tests for all of the above: http://code.google.com/p/atombeat/source/browse/trunk/parent/atombeat-integration-tests/pom.xml As an Atombeat user I want to re-purpose these tests to test a particular Atombeat installation, with a different security mechanism (CAS). Because the Atombeat tests test a set of different configurations some are not applicable - testing security on an unsecured configuration for example - so the tests pom file contains a lot of configuration information. I had hoped to be able to inherit from the Atombeat test pom, ie set it as parent, but parents may only be of type pom. The Atombeat test source is in src/test/java, so currently no jar file is produced. I can fix that by adding plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin however the surefire plugin will not run the tests as it does not look inside jars to discover tests. Unpacking the jar into target/test-classes gets the tests discovered by Surefire. I then need to configure my project by duplicating the configuration information in the test POM. Is this the best way to reuse tests? cheers Tim -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven profiles activations
Jörg and Benjamin, thanks for your explanation. I understand now that profiles are not allowed to be activated by properties defined inside a POM because it could form cycles (though maybe with some design decisions it could be avoided, but I have no idea of Maven code to give any suggestions about that). And, Jörg, about the name of the tag in the activation, I believe it´s property instead of systemProperty because there are both options to activate it: one using a system/environment property/variable and other using a maven property (although in the latter case its necessary to be a property defined in the command line) Regards, Rafael Vanderlei On Fri, Mar 25, 2011 at 3:37 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Rafael, Rafael Vanderlei wrote: Jörg, I understood when you first said that the way Maven is currently implemented it does not work this way. I'm just wondering if there is a suitable reason for that. So what I still dont understand is if a property declared in a parent pom can be used on the child pom for other purposes, WHY cant it be used to activate a profile defined in that child pom? Maybe it's just a matter that maven developers did not think about and maybe could be simply implemented to work this way. On top of Benjamin's answer you have to understand *when* Maven is resolving the profiles and *when* the properties. The properties are determined from the effective pom for the current project i.e. the project model that is the result of merging all inherited POMs and active profiles into the final one that is used to build the project. This effective pom *is* what defines your project build - including the properties, because they are part of your final project definition. The profiles are used to modify this project model for alternate builds, they create a different effective pom i.e. the result is more or less a different project. Since the properties are part of the model, they cannot be used to modify it again - this is the chicken and egg problem. In the light of this it is unfortunate that the tag in the activation is named property instead of systemProperty, because most people make the wrong association. Forget your assumption of evaluating the parent pom first - the model has to be complete to evaluate anything. As a consequence of this behavior you can use a property in the parent, but define (or overwrite) it in the child. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven profiles activations
On 25 March 2011 13:36, Rafael Vanderlei rafaelvander...@gmail.com wrote: Jörg and Benjamin, thanks for your explanation. I understand now that profiles are not allowed to be activated by properties defined inside a POM because it could form cycles (though maybe with some design decisions it could be avoided, but I have no idea of Maven code to give any suggestions about that). And, Jörg, about the name of the tag in the activation, I believe it´s property instead of systemProperty because there are both options to activate it: one using a system/environment property/variable and other using a maven property (although in the latter case its necessary to be a property defined in the command line) properties defined by the CLI _are_ system properties. Regards, Rafael Vanderlei On Fri, Mar 25, 2011 at 3:37 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Rafael, Rafael Vanderlei wrote: Jörg, I understood when you first said that the way Maven is currently implemented it does not work this way. I'm just wondering if there is a suitable reason for that. So what I still dont understand is if a property declared in a parent pom can be used on the child pom for other purposes, WHY cant it be used to activate a profile defined in that child pom? Maybe it's just a matter that maven developers did not think about and maybe could be simply implemented to work this way. On top of Benjamin's answer you have to understand *when* Maven is resolving the profiles and *when* the properties. The properties are determined from the effective pom for the current project i.e. the project model that is the result of merging all inherited POMs and active profiles into the final one that is used to build the project. This effective pom *is* what defines your project build - including the properties, because they are part of your final project definition. The profiles are used to modify this project model for alternate builds, they create a different effective pom i.e. the result is more or less a different project. Since the properties are part of the model, they cannot be used to modify it again - this is the chicken and egg problem. In the light of this it is unfortunate that the tag in the activation is named property instead of systemProperty, because most people make the wrong association. Forget your assumption of evaluating the parent pom first - the model has to be complete to evaluate anything. As a consequence of this behavior you can use a property in the parent, but define (or overwrite) it in the child. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven profiles activations
oww so forgive me for what i said before Regards, Rafael. On Fri, Mar 25, 2011 at 10:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 25 March 2011 13:36, Rafael Vanderlei rafaelvander...@gmail.com wrote: Jörg and Benjamin, thanks for your explanation. I understand now that profiles are not allowed to be activated by properties defined inside a POM because it could form cycles (though maybe with some design decisions it could be avoided, but I have no idea of Maven code to give any suggestions about that). And, Jörg, about the name of the tag in the activation, I believe it´s property instead of systemProperty because there are both options to activate it: one using a system/environment property/variable and other using a maven property (although in the latter case its necessary to be a property defined in the command line) properties defined by the CLI _are_ system properties. Regards, Rafael Vanderlei On Fri, Mar 25, 2011 at 3:37 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Rafael, Rafael Vanderlei wrote: Jörg, I understood when you first said that the way Maven is currently implemented it does not work this way. I'm just wondering if there is a suitable reason for that. So what I still dont understand is if a property declared in a parent pom can be used on the child pom for other purposes, WHY cant it be used to activate a profile defined in that child pom? Maybe it's just a matter that maven developers did not think about and maybe could be simply implemented to work this way. On top of Benjamin's answer you have to understand *when* Maven is resolving the profiles and *when* the properties. The properties are determined from the effective pom for the current project i.e. the project model that is the result of merging all inherited POMs and active profiles into the final one that is used to build the project. This effective pom *is* what defines your project build - including the properties, because they are part of your final project definition. The profiles are used to modify this project model for alternate builds, they create a different effective pom i.e. the result is more or less a different project. Since the properties are part of the model, they cannot be used to modify it again - this is the chicken and egg problem. In the light of this it is unfortunate that the tag in the activation is named property instead of systemProperty, because most people make the wrong association. Forget your assumption of evaluating the parent pom first - the model has to be complete to evaluate anything. As a consequence of this behavior you can use a property in the parent, but define (or overwrite) it in the child. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-enforcer-plugin and Maven 3
Hello, the rule 'Require Plugin Versions' is discarded when run in Maven 3, not in Maven 2. Is there any reason and how to achieve the same behaviour using Maven 3 ? Thanks Jeff MAURY -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
fail-at-end not working
Hi all, I am using Maven 2.2.1 and I need to have my build run until the very end because I am running integration tests that start and stop my JBoss. Currently, when a test has a failure/error, the build quits and my JBoss keeps on running. I tried adding the '-fae' parameter, but this does not seem to work... I also can't use '-Dmaven.test.failure.ignore' and '-Dmaven.test.error.ignore', since they will have Maven report 'BUILD SUCCESSFUL', which is obviously wrong! Can someone tell me if the '-fae' not working is a bug? And if so, is there a way I can work around it? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin: release project from within subdirectory
Got stuck with the same problem. Is there a solution to this? -- View this message in context: http://maven-users.828.n2.nabble.com/Release-plugin-release-project-from-within-subdirectory-tp5057222p6207546.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: enforcer plugin rules to prevent circular dependencies
On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor caoi...@gmail.com wrote: Hi, I've just discovered the enforcer plugin and would like to use it to reduce our dependency conflicts but a bigger problem for us when it does turn up are circular dependencies. The Dependency Tree plugin spots these, but does anyone have any rules for the enforcer plugin to fail the build if it occurs? In what situation does the build get far enough to use a plugin to detect this? I thought Maven would just stop with an error if it encountered a cycle. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: fail-at-end not working
You should use the failsafe-plugin, which has separate goals for performing the tests and verifying the outcome. That will make it possible to stop your app server before verifying. The plugin site describes this quite well. /Anders On Fri, Mar 25, 2011 at 15:21, Asmann, Roland roland.asm...@adesso.atwrote: Hi all, I am using Maven 2.2.1 and I need to have my build run until the very end because I am running integration tests that start and stop my JBoss. Currently, when a test has a failure/error, the build quits and my JBoss keeps on running. I tried adding the '-fae' parameter, but this does not seem to work... I also can't use '-Dmaven.test.failure.ignore' and '-Dmaven.test.error.ignore', since they will have Maven report 'BUILD SUCCESSFUL', which is obviously wrong! Can someone tell me if the '-fae' not working is a bug? And if so, is there a way I can work around it? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: fail-at-end not working
I just found that one, will take a look at it. But it seems to be exactly what I need. Thanks! Roland On 25.03.2011 16:05, Anders Hammar wrote: You should use the failsafe-plugin, which has separate goals for performing the tests and verifying the outcome. That will make it possible to stop your app server before verifying. The plugin site describes this quite well. /Anders On Fri, Mar 25, 2011 at 15:21, Asmann, Roland roland.asm...@adesso.atwrote: Hi all, I am using Maven 2.2.1 and I need to have my build run until the very end because I am running integration tests that start and stop my JBoss. Currently, when a test has a failure/error, the build quits and my JBoss keeps on running. I tried adding the '-fae' parameter, but this does not seem to work... I also can't use '-Dmaven.test.failure.ignore' and '-Dmaven.test.error.ignore', since they will have Maven report 'BUILD SUCCESSFUL', which is obviously wrong! Can someone tell me if the '-fae' not working is a bug? And if so, is there a way I can work around it? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: fail-at-end not working
It is exactly what you want! :-) /Anders On Fri, Mar 25, 2011 at 16:08, Asmann, Roland roland.asm...@adesso.atwrote: I just found that one, will take a look at it. But it seems to be exactly what I need. Thanks! Roland On 25.03.2011 16:05, Anders Hammar wrote: You should use the failsafe-plugin, which has separate goals for performing the tests and verifying the outcome. That will make it possible to stop your app server before verifying. The plugin site describes this quite well. /Anders On Fri, Mar 25, 2011 at 15:21, Asmann, Roland roland.asm...@adesso.atwrote: Hi all, I am using Maven 2.2.1 and I need to have my build run until the very end because I am running integration tests that start and stop my JBoss. Currently, when a test has a failure/error, the build quits and my JBoss keeps on running. I tried adding the '-fae' parameter, but this does not seem to work... I also can't use '-Dmaven.test.failure.ignore' and '-Dmaven.test.error.ignore', since they will have Maven report 'BUILD SUCCESSFUL', which is obviously wrong! Can someone tell me if the '-fae' not working is a bug? And if so, is there a way I can work around it? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-enforcer-plugin and Maven 3
There's already a bug report about this (You could vote for it): http://jira.codehaus.org/browse/MENFORCER-98 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Is there a way to ignore profiles in settings.xml?
Hi everyone. If I configure my .m2/settings.xml to activate some profiles, is there a way to deactivate all of them on the command line in one go, so I can use only explicitly typed profiles? e.g.: Let´s say I have declared 4 profiles in settings.xml profile1,profile2,profile3,profile4 and configure they as active profiles. Now let´s say I want to run a build only with other profiles, like profile5 and profile6. But I dont want to run something like ' mvn -P!profile1,!profile2,!profile3,!profile4,profile5,profile6 package ' I would like something like ' mvn magic_argument -Pprofile5,profile6 package ' Is there such a magic_argument that ignores all profiles declared as active in settings.xml ? Thanks and regards. Rafael Vanderlei.
Emma plugin advice needed (conflict w/ OpenJPA)
There seems to be an issue with dueling byte-code instrumenting/weaving/enhancing between Emma and OpenJPA. I found this old issue for OpenJPA https://issues.apache.org/jira/browse/OPENJPA-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991027and that points over to a SERP issue which is where they decided the problem was. BTW ... I am using the terms instrument, enhance and weave willy-nilly as they mean almost the same thing in this context. It is the process of modifying the byte code of a class after javac compiles and and before java executes it. Anyway ... the short form is that if OpenJPA attempts to enhance a class after Emma has instrumented it, an error message says IllegalArgumentException: 5 with a stack trace.Then the tests fail when they run with a message saying they aren't enhanced. Because the OpenJPA enhance error message is so limited, nobody seems to know whether its just some classes or all of them that have the issue. All of the unit tests complain about the lack of enhancement. There are other comments here and there I found by Googling that seem to say there is a similar problem with Cobertura but it only happens depending on the order of the instrumenting. I don't recall if it fails when Cobertura instruments first or if OpenJPA has to enhance first to have it fail. Emma instruments at compile time. Cobertura instruments at run time. My problems are, obviously, with running JUnit 3 tests inside Maven. I have read that they run twice--once without Emma instrumentation and once with. OpenJPA can enhance at compile time. There is a maven plugin to do that. Or, if not already enhanced, it will happen at run time, perhaps when the class loads. (It depends on the JDK version. I'm using JDK 5 or 6) Finally the question ... what would I have to do to make sure that OpenJPA enhances the classes before Emma instruments them. I don't know if this will make my tests run correctly but its the only thing I have come up with to try. It's not clear to me which phase of the lifecycle is the one in which the Emma instrumentation takes place. if I know that, I might be able to do the OpenJPA enhancing prior to that point. I'm also wondering about a typical way to do the OpenJPA enhancing after comiple and before running tests. This should make my tests run faster since there would be no enhancing going for every one of the hundreds of tests. I/m assuming if there are classes marked with @Entity they get enhanced if loaded even if no actual database activity goes on in the test. (This question came up as I thought about how Emma instruments one time and Coburtura instruments when every test runs so Emma runs tests faster.) If it doesn't work to reverse the enhancing order with Emma, my next plan is to see what I can do with Cobertura, though I have found Emma easier to use. Thanks -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Maven or antrun-plugin manipulates JAVA_HOME and build fails
Hello,
i have the following problem: If i call mvn clean process-resources
and then ant directly on my build.xml, then the build is successful.
If i want to execute the antrun-plugin, with mvn compile, then the
build fails with the message
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.6:run (compile) on pro
ject infopool: An Ant BuildException has occured: The following error
occurred while executing this
line:
[ERROR] E:\Softwareentwicklung\Git_Repositories\project\build.xml:120:
The following error occu
rred while executing this line:
[ERROR] E:\Softwareentwicklung\Git_Repositories\project\modules_artifact.xml:12:
The following
error occurred while executing this line:
[ERROR] E:\Softwareentwicklung\Git_Repositories\project\buildAndRelease.xml:21:
The following e
rror occurred while executing this line:
[ERROR] E:\Softwareentwicklung\Git_Repositories\project\buildAndRelease.xml:193:
Unable to find
a javac compiler;
[ERROR] com.sun.tools.javac.Main is not on the classpath.
[ERROR] Perhaps JAVA_HOME does not point to the JDK.
[ERROR] It is currently set to C:\Programme\Java\jdk1.5.0_22\jre
echo %JAVA_HOME% gives me C:\Programme\Java\jdk1.5.0_22, which is the
correct path. So where does this jre come from?
My pom.xml:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdde.company/groupId
artifactIdparent/artifactId
version50-SNAPSHOT/version
/parent
groupIdde.company/groupId
artifactIdartifact/artifactId
version0.0.1-SNAPSHOT/version
packagingjar/packaging
nameinfopool/name
properties
project.build.sourceEncodingCp1252/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdde.company/groupId
artifactIdprotokoll/artifactId
version2.0.0-SNAPSHOT/version
/dependency
dependency
groupIdde.company/groupId
artifactIdtracking/artifactId
version2.0.0-SNAPSHOT/version
/dependency
dependency
groupIdde.company/groupId
artifactIdtrackingimpl/artifactId
version2.0.0-SNAPSHOT/version
/dependency
dependency
groupIdde.company/groupId
artifactIdprotokollauftrag/artifactId
version2.0.0-SNAPSHOT/version
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.2/version
executions
execution
idcopydeps/id
phaseprocess-resources/phase
goals
goalcopy-dependencies/goal
/goals
inheritedfalse/inherited
configuration
outputDirectory${project.build.directory}/lib/outputDirectory
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
stripVersiontrue/stripVersion
prependGroupIdtrue/prependGroupId
includeGroupIdsde.company/includeGroupIds
excludeArtifactIdsloggingapi,hibernate/excludeArtifactIds
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.6/version
executions
execution
idcompile/id
Re: Re-using tests - best practice
In such a case (if you still want to reuse tests apart from the SUT they are designed for) your approach with dependency:unpack looks correct. But again, I would suggest to analyze the reason behind this operation and do everything you can to avoid this artificial separation of the SUT (system under testing) and its tests. — Yegor Bugayenko, PMP®, SCEA On Fri, Mar 25, 2011 at 11:02 AM, Tim Pizey tim.pi...@gmail.com wrote: Thanks for your comments Yegor, however you do not address the question, perhaps I did not put it well. What is the best way to re-use tests, given that Surefire will not discover tests in a jar and you cannot extend a non-pom project? I feel that the solution I have come up with is pretty clunky and would welcome a more elegant to the problem of test reuse. cheers Tim On 24 March 2011 08:08, Yegor Bugayenko wrote: What is the point of retesting a library which has already been tested? You need your own tests, that will check the validity of your own application, not a third-party library. If you want to reuse some code from the library - just get their .java files from their repository and add them to your project statically (don't forget to review their license restrictions). — Yegor Bugayenko, PMP®, SCEA On Tue, Mar 22, 2011 at 12:17 PM, Tim Pizey tim.pi...@gmail.com wrote: Hi, Atombeat http://code.google.com/p/atombeat/ has a set of possible configurations with different backends and security policies. atombeat-exist-full atombeat-exist-minimal atombeat-exist-full-secure atombeat-exist-minimal-secure atombeat-orbeon-full atombeat-orbeon-minimal atombeat-orbeon-full-secure atombeat-orbeon-minimal-secure Atombeat has a separate project which contains the tests for all of the above: http://code.google.com/p/atombeat/source/browse/trunk/parent/atombeat-integration-tests/pom.xml As an Atombeat user I want to re-purpose these tests to test a particular Atombeat installation, with a different security mechanism (CAS). Because the Atombeat tests test a set of different configurations some are not applicable - testing security on an unsecured configuration for example - so the tests pom file contains a lot of configuration information. I had hoped to be able to inherit from the Atombeat test pom, ie set it as parent, but parents may only be of type pom. The Atombeat test source is in src/test/java, so currently no jar file is produced. I can fix that by adding plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin however the surefire plugin will not run the tests as it does not look inside jars to discover tests. Unpacking the jar into target/test-classes gets the tests discovered by Surefire. I then need to configure my project by duplicating the configuration information in the test POM. Is this the best way to reuse tests? cheers Tim -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org
Re: Is there a way to ignore profiles in settings.xml?
On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: If I configure my .m2/settings.xml to activate some profiles, is there a way to deactivate all of them on the command line in one go, so I can use only explicitly typed profiles? Why are there so many profiles and what are they for? (If you explain what problem you're trying to solve, someone can probably help you come up with a better solution. Clearly, having a bunch of profiles that are active by default and then wanting them to NOT be active indicates something is wrong.) -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to ignore profiles in settings.xml?
Hi, Wendy. I have many dependencies on runtime and they vary on many environments. Basically, my application must be able to run in 5 different environments, named local (which actually is the machine of the developer), development, integration, trainning and production. In which of those environments, I have other applications on which mine depends and so I have a bunch of combinations of profiles for each environment and for each application on which mine depends. The whole organization of environments/applications is something like this: - Enviroment 1 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 2 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 3 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 4 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 5 --- MyApplication, Application B, Application C, Application D, Application E I need my build configuration to be flexible enough to allow someone to build MyApplication for the Environment1 that uses Application B that runs on Environment 2, Application C that runs on Environment 3... well.. any variations of those Apps and Envs.. So, the default profiles are supposed to determine the configuration of the local enviroment, which is the machine of each developer, but when I try to build for another environment, I dont want the default profiles to be activated, because they will contain configurations specific only for the local environment and those default profiles come into direct conflict with the profiles for the other environments. I think people may be confused by reading all these explanations about the real case I´m working on and that´s why I tried to hide it on the first post and questioned only specific details about Maven profiles, which I think would easier to analyse and answer. I hope this helped more than messed things up lol. Regards, Rafael. On Fri, Mar 25, 2011 at 5:30 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: If I configure my .m2/settings.xml to activate some profiles, is there a way to deactivate all of them on the command line in one go, so I can use only explicitly typed profiles? Why are there so many profiles and what are they for? (If you explain what problem you're trying to solve, someone can probably help you come up with a better solution. Clearly, having a bunch of profiles that are active by default and then wanting them to NOT be active indicates something is wrong.) -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to ignore profiles in settings.xml?
What if you don't activate the profiles fully in settings.xml, don't activate them by default in settings.xml but, instead, activate them based on an environment variable on the machine? You could set MAVEN_SETTINGS_PROFILES=default in the startup for the developer's workstation/laptop. Then put in the option to activate those default profiles profiles profile activation property nameenv.MAVEN_SETTINGS_PROFILES/name valuedefault/value /property /activation ... /profile /profiles If that developer is going to be doing something unusual, they would clear the value of the environment variable and use the -Pprofile1,profile2 command line profile setter when building the non-standard stuff. Thanks. Lee On Fri, Mar 25, 2011 at 4:02 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: Hi, Wendy. I have many dependencies on runtime and they vary on many environments. Basically, my application must be able to run in 5 different environments, named local (which actually is the machine of the developer), development, integration, trainning and production. In which of those environments, I have other applications on which mine depends and so I have a bunch of combinations of profiles for each environment and for each application on which mine depends. The whole organization of environments/applications is something like this: - Enviroment 1 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 2 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 3 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 4 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 5 --- MyApplication, Application B, Application C, Application D, Application E I need my build configuration to be flexible enough to allow someone to build MyApplication for the Environment1 that uses Application B that runs on Environment 2, Application C that runs on Environment 3... well.. any variations of those Apps and Envs.. So, the default profiles are supposed to determine the configuration of the local enviroment, which is the machine of each developer, but when I try to build for another environment, I dont want the default profiles to be activated, because they will contain configurations specific only for the local environment and those default profiles come into direct conflict with the profiles for the other environments. I think people may be confused by reading all these explanations about the real case I´m working on and that´s why I tried to hide it on the first post and questioned only specific details about Maven profiles, which I think would easier to analyse and answer. I hope this helped more than messed things up lol. Regards, Rafael. On Fri, Mar 25, 2011 at 5:30 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: If I configure my .m2/settings.xml to activate some profiles, is there a way to deactivate all of them on the command line in one go, so I can use only explicitly typed profiles? Why are there so many profiles and what are they for? (If you explain what problem you're trying to solve, someone can probably help you come up with a better solution. Clearly, having a bunch of profiles that are active by default and then wanting them to NOT be active indicates something is wrong.) -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Re: Is there a way to ignore profiles in settings.xml?
Hi, Lee. Thanks for response. Activating the profiles based on an environment variable seems to be better than activating them fully in settings.xml, but to do so I would still have one step before the ' mvn -Pprofile1,profile2 package '. My intention when I first submitted the email to the list was to know if there is an even simpler way to do that just by running something like ' mvn magic_argument -Pprofile1,profile2 package ' as I said before. For now, I´m working like the easiest possible way that I know of: The profiles I need to be active by default are configure with activeByDefaulttrue/activeByDefault . If one developer needs to do something unusual, he simply runs ' mvn -Pprofile1,profile2 package ' . By doing so, all the activeByDefault profiles will be automatically deactivated and only the profiles explicitly defined will be activated. I was trying to activate profiles using the settings.xml just because I did not want the default profiles configuration to be shared between developers, i.e., I did not want to share these informations on the pom.xml that is on the version control system. On Fri, Mar 25, 2011 at 6:32 PM, Lee Meador l...@leemeador.com wrote: What if you don't activate the profiles fully in settings.xml, don't activate them by default in settings.xml but, instead, activate them based on an environment variable on the machine? You could set MAVEN_SETTINGS_PROFILES=default in the startup for the developer's workstation/laptop. Then put in the option to activate those default profiles profiles profile activation property nameenv.MAVEN_SETTINGS_PROFILES/name valuedefault/value /property /activation ... /profile /profiles If that developer is going to be doing something unusual, they would clear the value of the environment variable and use the -Pprofile1,profile2 command line profile setter when building the non-standard stuff. Thanks. Lee On Fri, Mar 25, 2011 at 4:02 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: Hi, Wendy. I have many dependencies on runtime and they vary on many environments. Basically, my application must be able to run in 5 different environments, named local (which actually is the machine of the developer), development, integration, trainning and production. In which of those environments, I have other applications on which mine depends and so I have a bunch of combinations of profiles for each environment and for each application on which mine depends. The whole organization of environments/applications is something like this: - Enviroment 1 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 2 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 3 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 4 --- MyApplication, Application B, Application C, Application D, Application E - Enviroment 5 --- MyApplication, Application B, Application C, Application D, Application E I need my build configuration to be flexible enough to allow someone to build MyApplication for the Environment1 that uses Application B that runs on Environment 2, Application C that runs on Environment 3... well.. any variations of those Apps and Envs.. So, the default profiles are supposed to determine the configuration of the local enviroment, which is the machine of each developer, but when I try to build for another environment, I dont want the default profiles to be activated, because they will contain configurations specific only for the local environment and those default profiles come into direct conflict with the profiles for the other environments. I think people may be confused by reading all these explanations about the real case I´m working on and that´s why I tried to hide it on the first post and questioned only specific details about Maven profiles, which I think would easier to analyse and answer. I hope this helped more than messed things up lol. Regards, Rafael. On Fri, Mar 25, 2011 at 5:30 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: If I configure my .m2/settings.xml to activate some profiles, is there a way to deactivate all of them on the command line in one go, so I can use only explicitly typed profiles? Why are there so many profiles and what are they for? (If you explain what problem you're trying to solve, someone can probably help you come up with a better solution. Clearly, having a bunch of profiles that are active by default and then wanting them to NOT be active indicates something is wrong.) -- Wendy - To unsubscribe, e-mail:
Re: Is there a way to ignore profiles in settings.xml?
On Fri, Mar 25, 2011 at 6:08 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: The profiles I need to be active by default are configure with activeByDefaulttrue/activeByDefault . If one developer needs to do something unusual, he simply runs ' mvn -Pprofile1,profile2 package ' . By doing so, all the activeByDefault profiles will be automatically deactivated and only the profiles explicitly defined will be activated. What version of Maven are you using? I thought that behavior (which was awfully non-intuitive) had changed... -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to ignore profiles in settings.xml?
I'm using Maven 2.2.0, although I'm planning to migrate to Maven 3.. I hope this behavior hasn't changed in Maven 3, since I'm quite depending on it right now. On Fri, Mar 25, 2011 at 7:10 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 6:08 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: The profiles I need to be active by default are configure with activeByDefaulttrue/activeByDefault . If one developer needs to do something unusual, he simply runs ' mvn -Pprofile1,profile2 package ' . By doing so, all the activeByDefault profiles will be automatically deactivated and only the profiles explicitly defined will be activated. What version of Maven are you using? I thought that behavior (which was awfully non-intuitive) had changed... -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to ignore profiles in settings.xml?
On Fri, Mar 25, 2011 at 6:14 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: I'm using Maven 2.2.0, although I'm planning to migrate to Maven 3.. I hope this behavior hasn't changed in Maven 3, since I'm quite depending on it right now. Maybe it was just discussed but not changed. At least, http://maven.apache.org/guides/introduction/introduction-to-profiles.html still says All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to ignore profiles in settings.xml?
Good to know. Actually I had already seen this page early this week, but I was not sure if this page was meant for Maven 2 or Maven 3... now I see that it mentions Maven 3 on that page, so I think there are valid information for both versions. On Fri, Mar 25, 2011 at 7:17 PM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 6:14 PM, Rafael Vanderlei rafaelvander...@gmail.com wrote: I'm using Maven 2.2.0, although I'm planning to migrate to Maven 3.. I hope this behavior hasn't changed in Maven 3, since I'm quite depending on it right now. Maybe it was just discussed but not changed. At least, http://maven.apache.org/guides/introduction/introduction-to-profiles.html still says All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Is this possible with Maven profiles?
Hi again. I have a variation on my persistence.xml and I'm not sure about the best approach to achieve my goal. When I deploy the package to the JBoss Server, my persistence.xml must look like this: persistence-unit name=NAME transaction-type=JTA ... (dozens of lines) jta-data-sourceJNDI_NAME_FOR_MY_DATASOURCE/jta-data-source ... (dozens of lines) /persistence But for the unit tests, I run JPA standalone (out of JBoss) and so the persistence-unit.xml must look like this: persistence-unit name=NAME transaction-type=RESOURCE_LOCAL ... (dozens of lines) property name=eclipselink.jdbc.driver value=oracle.jdbc.OracleDriver / property name=eclipselink.jdbc.url value=... / property name=eclipselink.jdbc.user value=... / property name=eclipselink.jdbc.password value=... / ... (dozens of lines) /persistence As far as I know, properties values can only be Strings. So even if I only need to make those few changes, the best (and maybe only) way to automate this using profiles is to have a copy of that quite huge file with the variations, although, of course, it comes with the downside of needing to maintain both files consistent? Regards, Rafael Vanderlei.
Re: Is this possible with Maven profiles?
persistence-unit name=NAME transaction-type=${transtype}
${dbconfig}
/persistence
Try something along these lines:
profile
idproduction/production
properties
transtypeJTA/transtype
dbconfig![CDATA[jta-data-sourceJNDI_NAME_FOR_MY_DATASOURCE/jta-data-source]]/dbconfig
/properties
/profile
And yes, you'd need to put the whole property... section in a CDATA
node for your unit test version.
Having said all that, I think I'd look for another option. Surely
OpenJPA would allow you to specify an alternate P-U config file so you
could just include both and then instruct OpenJPA which one to use.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: enforcer plugin rules to prevent circular dependencies
On Fri, Mar 25, 2011 at 8:45 AM, Wendy Smoak wsm...@gmail.com wrote: On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor caoi...@gmail.com wrote: Hi, I've just discovered the enforcer plugin and would like to use it to reduce our dependency conflicts but a bigger problem for us when it does turn up are circular dependencies. The Dependency Tree plugin spots these, but does anyone have any rules for the enforcer plugin to fail the build if it occurs? I wrote a plugin to do it. It uses org.apache.maven.shared.dependency.tree.DependencyTreeBuilder to get the list of DependencyNode. Then it cycles through each one calling getArtifact() and compares it to see if it is the same as the main project's Artifact (same group id and artifact id). In other words, if any of my dependencies are myself, then it throws an exception. In what situation does the build get far enough to use a plugin to detect this? I thought Maven would just stop with an error if it encountered a cycle. I have heard that it will catch a cycle in a reactor build, but otherwise no, it won't catch it. That's why I submitted this bug a couple months ago: http://jira.codehaus.org/browse/MNG-4999 I don't think it is really possible to introduce a cycle when using releases, but it is definitely possible with snapshots (just follow the steps in the bug). You can read my thread about cycle detection from a couple months ago here: http://maven.40175.n5.nabble.com/Why-is-Maven-allowing-cycles-td3355428.html Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Extra dependency added to eclipse projects
On Sat, Mar 12, 2011 at 5:26 AM, John Lussmyer john.lussm...@amdocs.com wrote: We have a large project hierarchy, and use mvn eclipse:eclipse to generate Eclipse projects for it. In 3 of the projects, maven adds a dependency to spring-2.0.3.jar - which we don't use, and don't have. This .jar does not appear in ANY of our pom.xml files. mvn dependency:tree doesn't find any references to this jar either. Any ideas on how to get rid of these added, annoying, unwanted, dependencies? John, have you made any discoveries on this? If it's a problem in m-ecliose-p I want to get it fixed - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
