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 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 >> >> >> org.apache.maven.plugins >> maven-jar-plugin >> >> >> >> test-jar >> >> >> >> >> >> 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 wrote: > 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 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 > wrote: > >> 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 > 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 > > wrote: > > > >> 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 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 wrote: > 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 > wrote: > > > 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 wrote: > 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 > > wrote: > > > > > 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 -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-tabpanel&focusedCommentId=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:
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
de.company
parent
50-SNAPSHOT
de.company
artifact
0.0.1-SNAPSHOT
jar
infopool
Cp1252
de.company
protokoll
2.0.0-SNAPSHOT
de.company
tracking
2.0.0-SNAPSHOT
de.company
trackingimpl
2.0.0-SNAPSHOT
de.company
protokollauftrag
2.0.0-SNAPSHOT
maven-dependency-plugin
2.2
copydeps
process-resources
copy-dependencies
false
${project.build.directory}/lib
true
true
true
true
true
de.company
loggingapi,hibernate
maven-antrun-plugin
1.6
compile
compile
run
false
Regards,
Manuel
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
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 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 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 > >> > >> > >>org.apache.maven.plugins > >>maven-jar-plugin > >> > >> > >> > >> test-jar > >> > >> > >> > >> > >> > >> 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 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 wrote: > On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei > 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 env.MAVEN_SETTINGS_PROFILES default ... 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 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 wrote: > > > On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei > > 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 -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 true . 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 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 > > > > > >env.MAVEN_SETTINGS_PROFILES >default > > >... > > > > > 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 wrote: > > > > > On Fri, Mar 25, 2011 at 12:18 PM, Rafael Vanderlei > > > 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 > > > > > > -
Re: Is there a way to ignore profiles in settings.xml?
On Fri, Mar 25, 2011 at 6:08 PM, Rafael Vanderlei wrote: > The profiles I need to be active by default are configure with > true . 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 wrote: > On Fri, Mar 25, 2011 at 6:08 PM, Rafael Vanderlei > wrote: > > > The profiles I need to be active by default are configure with > > true . 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 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 wrote: > On Fri, Mar 25, 2011 at 6:14 PM, Rafael Vanderlei > 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: ... (dozens of lines) JNDI_NAME_FOR_MY_DATASOURCE ... (dozens of lines) But for the unit tests, I run JPA standalone (out of JBoss) and so the persistence-unit.xml must look like this: ... (dozens of lines) ... (dozens of lines) 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?
>
>
${dbconfig}
>
>
Try something along these lines:
production
JTA
Re: enforcer plugin rules to prevent circular dependencies
On Fri, Mar 25, 2011 at 8:45 AM, Wendy Smoak wrote: > On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor 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 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
