Re: Use of maven.test.skip
Hi, it is my experience that no matter how focused and fast each single test is, at some point running all of them will take too long if you build often. I agree totally with Jeffrey that it is important to make fast running focused test, but when you reach that limit when you feel you wait too long for the unit tests to run - I know I have a long time ago - it's time to make focused test suites for what you are working on right now (and include tests you feel are likley to break). For this to work in practise it is important that somebody else runs all the tests all the time and notify you if you have broken something lately. In our house, Bob does this (as in Bob the Builder). He runs Cruise Control and notifies us if we have broken something we did not antispate. We all feel that this is a good way to go about building and testing, but I'm sure there are people out there who would feel differently. As for making a focused test suite in maven (I do this in my IDE), I would try making your own goal in maven.xml running only a few tests at a time. This is just my opinion, though. I would love to hear how other people use maven to build, and run tests! Best regards, Bent André On Tue, 10 Aug 2004 19:54:57 -0500, Jeffrey D. Brekke <[EMAIL PROTECTED]> wrote: On Tue, 10 Aug 2004 22:40:13 +0100, Charles Daniels <[EMAIL PROTECTED]> said: I recommend you forget that the flag exists and make the tests faster. That doesn't necessarily help. If all of his tests take 0.1 second on average, but he has 1000 tests, it still takes 100 seconds to run them all, which may still be unacceptably long to wait when running frequently. Then they would still be too slow I guess. There are projects with many more than 1000 tests that run in a reasonable time ( http://jakarta.apache.org/commons/collections/junit-report.html ). Everyone has a threshold wrt build times. Maven runs the tests on each build because that is a best practice in our industry. They should be fast and focused tests, otherwise maybe the build should not be dependant upon them ( the slow ones that is, in which case you could move them into a separate testing project ). In my experience, slow running tests usually have external dependencies ( files, database, network ) which slow them down. I try to have unit/programmer tests not depend on anything external. Those tests ( that depend on external systems ) are important, and should exist. But having the build depend on them may not be wise. This has been discussed on this list before, sorry if I came off too harsh, I was really trying to help. > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod <[EMAIL PROTECTED]> said: > Folks, I currently have a project where the unit tests take a > considerable amount of time to run (5 minutes or so), and as a > result, running them every time I do a build is proving impractical. > Initially, I just added the maven.test.skip flag to my > project.properties, but this isn't a good solution, mainly because > if I explicitly want to run the unit tests, I have to take the flag > out again. > What I want is for the unit tests not to be run when i do a build, > but I do want them to run if I explicitly say so. The interactions > between the Java and Test plugins don't seem to be flexible enough > to allow this. > My current solution is to move the unit tests out to a seperate > project, but that seems like an arse-backwards way of going about > it. Can anyone suggest a better approach? I think you may be onto something here. If they are so long, maybe they aren't unit tests and should be moved. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: disable checkstyle?
Yeah, that's the problem. It doesn't handle the enums or static imports of 1.5 I understand the reasons, I just want to turn it off. After all, I already configured a style in Idea, and have it doing conformance on the fly. Malachi At 09:14 PM 8/9/2004, you wrote: Sorry Malachi, I misunderstood your original question. I run javadocs without checkstyle, but I'm using JDK1.4. Jeff On Mon, 09 Aug 2004, at 19:57:30 [GMT -0700] Malachi de AElfweald wrote: > I had tried that; currently, I have the entire report section commented out. > Are you using JDK1.5 enums and static imports? > Malachi > At 07:21 AM 8/8/2004, you wrote: >>I just have this: >> >> >> maven-javadoc-plugin >> >> >>in my project.xml, and get javadocs without checkstyle. What does your >>report section look like? >> >> Jeff >> >>On Sun, 08 Aug 2004, at 06:38:28 [GMT -0700] Malachi de AElfweald >>wrote: >> >> > It appears that checkstyle prevents JDK1.5 source from being compiled >> (enum >> > or static imports). The only way I have been able to disable it was to >> > completely stop all javadoc, site, and reporting. Even deregistering it >> > didn't seem to work. >> >> > Is there any way to still do javadocs without using checkstyle? >> >> > BTW: Yes, I did submit a Jira bug -- would just be nice to have >> javadocs of >> > my code before checkstyle is fixed. >> >> > Thanks, >> > Malachi >> >>-- >>mailto:[EMAIL PROTECTED] >> >> >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use of castor plugin
Sory for this, I had forgotten the xmlns:castor="castor" Now I get another error when running the Castor generator : castor:prepare-filesystem: [echo] Generating sources for D:\eclipse\workspace\crbt-metier\src\schemas\add_group_response.xsd -- Suppressing non fatal warnings. -- Disabling generation of Marshalling framework methods (marshall, unmarshall, validate). BUILD FAILED File.. C:\Documents and Settings\ndeloof\.maven\cache\maven-castor-plugin-1.2\plugin.jelly Element... ant:java Line.. 92 Column 38 java.lang.NoClassDefFoundError: sun/reflect/ConstructorAccessorImpl Total time: 6 seconds Any idea ? Notice I use SUN jdk 1.4.2 and that I can run the generator from command line without troubles. Nico. > Hi, > > can someone help me using castor plugin ? > > I've added this in my maven.xml : > > > > > And I get : > SAXParseException: The prefix "castor" for element "castor:generate" is not bound. > > What did I miss ? > > Nico. Our name has changed. Please update your address book to the following format: "[EMAIL PROTECTED]". This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
> On Tue, 10 Aug 2004 22:40:13 +0100, Charles Daniels <[EMAIL PROTECTED]> said: >> I recommend you forget that the flag exists and make the tests >> faster. > That doesn't necessarily help. If all of his tests take 0.1 second > on average, but he has 1000 tests, it still takes 100 seconds to run > them all, which may still be unacceptably long to wait when running > frequently. Then they would still be too slow I guess. There are projects with many more than 1000 tests that run in a reasonable time ( http://jakarta.apache.org/commons/collections/junit-report.html ). Everyone has a threshold wrt build times. Maven runs the tests on each build because that is a best practice in our industry. They should be fast and focused tests, otherwise maybe the build should not be dependant upon them ( the slow ones that is, in which case you could move them into a separate testing project ). In my experience, slow running tests usually have external dependencies ( files, database, network ) which slow them down. I try to have unit/programmer tests not depend on anything external. Those tests ( that depend on external systems ) are important, and should exist. But having the build depend on them may not be wise. This has been discussed on this list before, sorry if I came off too harsh, I was really trying to help. >> > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod >> <[EMAIL PROTECTED]> said: >> >> > Folks, I currently have a project where the unit tests take a > >> considerable amount of time to run (5 minutes or so), and as a > >> result, running them every time I do a build is proving >> impractical. > Initially, I just added the maven.test.skip flag to >> my > project.properties, but this isn't a good solution, mainly >> because > if I explicitly want to run the unit tests, I have to >> take the flag > out again. >> >> > What I want is for the unit tests not to be run when i do a >> build, > but I do want them to run if I explicitly say so. The >> interactions > between the Java and Test plugins don't seem to be >> flexible enough > to allow this. >> >> > My current solution is to move the unit tests out to a seperate > >> project, but that seems like an arse-backwards way of going about > >> it. Can anyone suggest a better approach? >> >> I think you may be onto something here. If they are so long, maybe >> they aren't unit tests and should be moved. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
hmm, my fingers are bad. I meant, point test resource in your project.xml to the dummy one On Tue, 10 Aug 2004 14:57:06 -0700, dan tran <[EMAIL PROTECTED]> wrote: > How about this! ;-) > > Create 2 test suites. One is a dummy one, and the other one has all > tests you want to run. > > Point test resource in your project.xml so that maven will invoke > after compilation. > it happens very fast since no test to run. > > Create a goal in your maven.xml to run your real test suite using test:single > goal. and run it any time you want > > > -D > > > > > On Tue, 10 Aug 2004 22:40:13 +0100, Charles Daniels <[EMAIL PROTECTED]> wrote: > > > > > > > -Original Message- > > > From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, August 10, 2004 8:37 PM > > > To: Maven Users List > > > Subject: Re: Use of maven.test.skip > > > > > > > > > > > > I recommend you forget that the flag exists and make the tests faster. > > > > That doesn't necessarily help. If all of his tests take 0.1 second on > > average, but he has 1000 tests, it still takes 100 seconds to run them all, > > which may still be unacceptably long to wait when running frequently. > > > > > > > > > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod > > > <[EMAIL PROTECTED]> said: > > > > > > > Folks, I currently have a project where the unit tests take a > > > > considerable amount of time to run (5 minutes or so), and as a > > > > result, running them every time I do a build is proving impractical. > > > > Initially, I just added the maven.test.skip flag to my > > > > project.properties, but this isn't a good solution, mainly because > > > > if I explicitly want to run the unit tests, I have to take the flag > > > > out again. > > > > > > > What I want is for the unit tests not to be run when i do a build, > > > > but I do want them to run if I explicitly say so. The interactions > > > > between the Java and Test plugins don't seem to be flexible enough > > > > to allow this. > > > > > > > My current solution is to move the unit tests out to a seperate > > > > project, but that seems like an arse-backwards way of going about > > > > it. Can anyone suggest a better approach? > > > > > > I think you may be onto something here. If they are so long, maybe > > > they aren't unit tests and should be moved. > > > > > > -- > > > = > > > Jeffrey D. Brekke [EMAIL PROTECTED] > > > Wisconsin, USA [EMAIL PROTECTED] > > > [EMAIL PROTECTED] > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
How about this! ;-) Create 2 test suites. One is a dummy one, and the other one has all tests you want to run. Point test resource in your project.xml so that maven will invoke after compilation. it happens very fast since no test to run. Create a goal in your maven.xml to run your real test suite using test:single goal. and run it any time you want -D On Tue, 10 Aug 2004 22:40:13 +0100, Charles Daniels <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 10, 2004 8:37 PM > > To: Maven Users List > > Subject: Re: Use of maven.test.skip > > > > > > > > I recommend you forget that the flag exists and make the tests faster. > > That doesn't necessarily help. If all of his tests take 0.1 second on > average, but he has 1000 tests, it still takes 100 seconds to run them all, > which may still be unacceptably long to wait when running frequently. > > > > > > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod > > <[EMAIL PROTECTED]> said: > > > > > Folks, I currently have a project where the unit tests take a > > > considerable amount of time to run (5 minutes or so), and as a > > > result, running them every time I do a build is proving impractical. > > > Initially, I just added the maven.test.skip flag to my > > > project.properties, but this isn't a good solution, mainly because > > > if I explicitly want to run the unit tests, I have to take the flag > > > out again. > > > > > What I want is for the unit tests not to be run when i do a build, > > > but I do want them to run if I explicitly say so. The interactions > > > between the Java and Test plugins don't seem to be flexible enough > > > to allow this. > > > > > My current solution is to move the unit tests out to a seperate > > > project, but that seems like an arse-backwards way of going about > > > it. Can anyone suggest a better approach? > > > > I think you may be onto something here. If they are so long, maybe > > they aren't unit tests and should be moved. > > > > -- > > = > > Jeffrey D. Brekke [EMAIL PROTECTED] > > Wisconsin, USA [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Use of maven.test.skip
> -Original Message- > From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 10, 2004 8:37 PM > To: Maven Users List > Subject: Re: Use of maven.test.skip > > > > I recommend you forget that the flag exists and make the tests faster. That doesn't necessarily help. If all of his tests take 0.1 second on average, but he has 1000 tests, it still takes 100 seconds to run them all, which may still be unacceptably long to wait when running frequently. > > > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod > <[EMAIL PROTECTED]> said: > > > Folks, I currently have a project where the unit tests take a > > considerable amount of time to run (5 minutes or so), and as a > > result, running them every time I do a build is proving impractical. > > Initially, I just added the maven.test.skip flag to my > > project.properties, but this isn't a good solution, mainly because > > if I explicitly want to run the unit tests, I have to take the flag > > out again. > > > What I want is for the unit tests not to be run when i do a build, > > but I do want them to run if I explicitly say so. The interactions > > between the Java and Test plugins don't seem to be flexible enough > > to allow this. > > > My current solution is to move the unit tests out to a seperate > > project, but that seems like an arse-backwards way of going about > > it. Can anyone suggest a better approach? > > I think you may be onto something here. If they are so long, maybe > they aren't unit tests and should be moved. > > -- > = > Jeffrey D. Brekke [EMAIL PROTECTED] > Wisconsin, USA [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pom.siteDirectory
Eric, thanks for the prompt response. It works.
-Original Message-
From: Erik Husby [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 4:11 PM
To: Maven Users List
Subject: Re: pom.siteDirectory
Liu, Zhihai wrote:
>I wanted to define pom.siteDirectory in build.properties to overwrite
> in project.xml to deploy to a different location, but it
did
>not work.
>
>This is what I have in build.properties
>...
>maven.site.deploy.method=fs
>pom.siteDirectory=C:/app/site
>...
>
>Maven build always uses the value for in project.xml and
>ignores my change in build.properties.
>
>Any help is greatly appreciated.
>
>
Put in the pom something like
${siteDirectory}
Then put a default value in project.properties
siteDirectory=defaultSite
Then put in build.properties
siteDirectory=c:/app/site
--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pom.siteDirectory
Liu, Zhihai wrote:
I wanted to define pom.siteDirectory in build.properties to overwrite
in project.xml to deploy to a different location, but it did
not work.
This is what I have in build.properties
...
maven.site.deploy.method=fs
pom.siteDirectory=C:/app/site
...
Maven build always uses the value for in project.xml and
ignores my change in build.properties.
Any help is greatly appreciated.
Put in the pom something like
${siteDirectory}
Then put a default value in project.properties
siteDirectory=defaultSite
Then put in build.properties
siteDirectory=c:/app/site
--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
pom.siteDirectory
I wanted to define pom.siteDirectory in build.properties to overwrite in project.xml to deploy to a different location, but it did not work. This is what I have in build.properties ... maven.site.deploy.method=fs pom.siteDirectory=C:/app/site ... Maven build always uses the value for in project.xml and ignores my change in build.properties. Any help is greatly appreciated. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Announcement Plugin 1.3 released
The maven team is pleased to announce the Maven Announcement Plugin 1.3 release! http://maven.apache.org/reference/plugins/announcement/ The Announcement plugin generates release announcements. It uses the information found in both the POM and in the changes.xml file to generate the announcement text. Changes in this version include: New Features: o Added check to verify that the POM has a versionelement for the announcement to be generated. Issue: MPANNOUNCEMENT-14. Thanks to Felipe Leme. o Added new optional maven.announcement.encodingproperty that defines which charset encoding to use to generate the text announcement (defaults to UTF-8). Issue: MPANNOUNCEMENT-13. Thanks to Felipe Leme. o Added new announcement:mailgoal to automatically send the generated announcement by email. Issue: MPANNOUNCEMENT-9. Thanks to Felipe Leme. o Added new optional maven.announcement.stylesheet.pathproperty that defines what stylesheet to use to generate the text announcement. Issue: MPANNOUNCEMENT-11. Thanks to Felipe Leme. Fixed bugs: o Fixed error message when current version is not available at xdocs/changes.xml. Issue: MPANNOUNCEMENT-12. Thanks to Felipe Leme. To automatically install the plugin, type the following on a single line: maven plugin:download -DgroupId=maven -DartifactId=maven-announcement-plugin -Dversion=1.3 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-announcement-plugin-1.3.jar Have fun! -The maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
I recommend you forget that the flag exists and make the tests faster. > On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod <[EMAIL PROTECTED]> said: > Folks, I currently have a project where the unit tests take a > considerable amount of time to run (5 minutes or so), and as a > result, running them every time I do a build is proving impractical. > Initially, I just added the maven.test.skip flag to my > project.properties, but this isn't a good solution, mainly because > if I explicitly want to run the unit tests, I have to take the flag > out again. > What I want is for the unit tests not to be run when i do a build, > but I do want them to run if I explicitly say so. The interactions > between the Java and Test plugins don't seem to be flexible enough > to allow this. > My current solution is to move the unit tests out to a seperate > project, but that seems like an arse-backwards way of going about > it. Can anyone suggest a better approach? I think you may be onto something here. If they are so long, maybe they aren't unit tests and should be moved. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiproject:clean problem
Hi Mario, I followed Dion Gillard's suggestions and I created a customized "multiproject:cleam" goal inside maven.xml of the my master project. This way: [Ctp] ### Running CtpMultiproject:Clean ### . . . And, I run maven this way: maven multiproject:clean mygoal ... -Dmm_tag_version=$1 -Dmm_subprojects_name=spbmessage,mmserver,MM_Business,ispbdns -Dmm_domain=cetip -Dmm_cvs_checkout=true -X | tee -a $HOME/MMmaster/mmlogs/$DATA It worked perfectly. Thanks a lot. Best regards, Roberto de Castro Analista de Suporte Cetip - Desus Rio de Janeiro +55 21 2276-7439 mailto:[EMAIL PROTECTED] -Mensagem original- De: Stefanutti, Mario [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 10 de agosto de 2004 14:12 Para: Maven Users List Assunto: R: Multiproject:clean problem It is a workaround. Anyway it works so fine! maven -o multiproject:clean Bye -Messaggio originale- Da: Milos Kleint [mailto:[EMAIL PROTECTED] Inviato: lunedì 9 agosto 2004 15.34 A: Maven Users List Oggetto: Re: Multiproject:clean problem and what about the scenario when I do a multiproject clean the a multiproject build which however failt mid-way.. a subsequent multiproject clean failt, because it cannot resolve all dependencies.. is there a way out? it seems liuke one can only do a clean build after successfully building the multiproject.. Milos Dion Gillard wrote: >You typically need to do a multiproject:install or >multiproject:install-snapshot before using any other goals. > >This places the dependent jars in the local repo. > >On Mon, 9 Aug 2004 10:24:04 -0300, Roberto Castro <[EMAIL PROTECTED]> wrote: > > >>Hi, when I run "Multiproject:clean" in my master project, it tries to find a jar >>file that was not created yet. >>I use an argument passed to Maven (mm_domain) to create the name of jar file. >>Is there a bug in Multiproject:clean? I've looked up in faq but I didn't find >>anything about this error. >>Here is log: >>+ >>| Executing clean:clean MM - SPBDns >>| Memory: 3M/6M >>+ >>Verifying dependencies for MM:spbdns >>Getting failed dependencies: [EMAIL PROTECTED] >>Attempting to download spbmessage-cetip-snapshot.jar. >>Getting URL: http://laranjeiras:8080/maven/MM/jars/spbmessage-cetip-snapshot.jar >>Received status code: 404 >>File not found on one of the repos >>java.io.FileNotFoundException: >>http://laranjeiras:8080/maven/MM/jars/spbmessage-cetip-snapshot.jar >>at org.apache.maven.util.HttpUtils.retrieveArtifact(HttpUtils.java:547) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:381) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:287) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:181) >>at >> org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(DependencyVerifier.java:326) >>at >> org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyVerifier.java:255) >>at >> org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(DependencyVerifier.java:171) >>at >> org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.java:97) >>at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) >>at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:510) >>at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) >>at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:342) >>at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >>at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) >>at com.werken.werkz.Goal.fire(Goal.java:639) >>at com.werken.werkz.Goal.attain(Goal.java:575) >>at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) >>at >> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) >>at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >>at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java
R: Multiproject:clean problem
It is a workaround. Anyway it works so fine! maven -o multiproject:clean Bye -Messaggio originale- Da: Milos Kleint [mailto:[EMAIL PROTECTED] Inviato: lunedì 9 agosto 2004 15.34 A: Maven Users List Oggetto: Re: Multiproject:clean problem and what about the scenario when I do a multiproject clean the a multiproject build which however failt mid-way.. a subsequent multiproject clean failt, because it cannot resolve all dependencies.. is there a way out? it seems liuke one can only do a clean build after successfully building the multiproject.. Milos Dion Gillard wrote: >You typically need to do a multiproject:install or >multiproject:install-snapshot before using any other goals. > >This places the dependent jars in the local repo. > >On Mon, 9 Aug 2004 10:24:04 -0300, Roberto Castro <[EMAIL PROTECTED]> wrote: > > >>Hi, when I run "Multiproject:clean" in my master project, it tries to find a jar >>file that was not created yet. >>I use an argument passed to Maven (mm_domain) to create the name of jar file. >>Is there a bug in Multiproject:clean? I've looked up in faq but I didn't find >>anything about this error. >>Here is log: >>+ >>| Executing clean:clean MM - SPBDns >>| Memory: 3M/6M >>+ >>Verifying dependencies for MM:spbdns >>Getting failed dependencies: [EMAIL PROTECTED] >>Attempting to download spbmessage-cetip-snapshot.jar. >>Getting URL: http://laranjeiras:8080/maven/MM/jars/spbmessage-cetip-snapshot.jar >>Received status code: 404 >>File not found on one of the repos >>java.io.FileNotFoundException: >>http://laranjeiras:8080/maven/MM/jars/spbmessage-cetip-snapshot.jar >>at org.apache.maven.util.HttpUtils.retrieveArtifact(HttpUtils.java:547) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:381) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:287) >>at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:181) >>at >> org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(DependencyVerifier.java:326) >>at >> org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyVerifier.java:255) >>at >> org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(DependencyVerifier.java:171) >>at >> org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.java:97) >>at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) >>at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:510) >>at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) >>at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:342) >>at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >>at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) >>at com.werken.werkz.Goal.fire(Goal.java:639) >>at com.werken.werkz.Goal.attain(Goal.java:575) >>at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) >>at >> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) >>at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >>at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) >>at com.werken.werkz.Goal.fire(Goal.java:639) >>at com.werken.werkz.Goal.attain(Goal.java:575) >>at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) >>at >> org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) >>at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) >>at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) >>at >> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) >>at com.werken.werkz.Goal.fire(Goal.java:639) >>at com.werken.werkz.Goal.attain(Goal.java:575) >>at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) >>at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634) >>at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) >>at org.apache.maven.cli.App.doMain(App.java:486) >>at org.apache.maven.cli.App.main(App.java:1215) >>at sun.reflect.NativeMe
Re: Use of maven.test.skip
Kenny, You can create simple wrapper goals like this: Then just invoke the appropriate one. Jeff On Tue, 10 Aug 2004, at 13:49:06 [GMT +0100] Kenny MacLeod wrote: > Folks, > I currently have a project where the unit tests take a considerable amount of time > to run (5 minutes or so), and as a result, running them every time I do a build is > proving impractical. > Initially, I just added the maven.test.skip flag to my project.properties, but this > isn't a good solution, mainly because if I explicitly want to run the unit tests, I > have to take the flag out > again. > What I want is for the unit tests not to be run when i do a build, but I do want > them to run if I explicitly say so. The interactions between the Java and Test > plugins don't seem to be flexible > enough to allow this. > My current solution is to move the unit tests out to a seperate project, but that > seems like an arse-backwards way of going about it. Can anyone suggest a better > approach? > cheers > kenny -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
Hi!
Maybe it help you
${systemScope.setProperty('maven.test.skip', 'true')}
${systemScope.setProperty('maven.test.skip', 'false')}
Kenny MacLeod wrote:
Folks,
I currently have a project where the unit tests take a considerable amount of time to
run (5 minutes or so), and as a result, running them every time I do a build is
proving impractical. Initially, I just added the maven.test.skip flag to my
project.properties, but this isn't a good solution, mainly because if I explicitly
want to run the unit tests, I have to take the flag out again.
What I want is for the unit tests not to be run when i do a build, but I do want them to run if I explicitly say so. The interactions between the Java and Test plugins don't seem to be flexible enough to allow this.
My current solution is to move the unit tests out to a seperate project, but that
seems like an arse-backwards way of going about it. Can anyone suggest a better
approach?
cheers
kenny
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of maven.test.skip
You can override project properties on the maven command line: maven -Dmaven.test.skip=false If you have one environment where you want testing on by default and another where you want it off set maven.test.skip as appropriate in build.properties rather than project.properties. Andy [EMAIL PROTECTED] To: [EMAIL PROTECTED] 10/08/04 13:49 cc: Please respond toSubject: Use of maven.test.skip users Folks, I currently have a project where the unit tests take a considerable amount of time to run (5 minutes or so), and as a result, running them every time I do a build is proving impractical. Initially, I just added the maven.test.skip flag to my project.properties, but this isn't a good solution, mainly because if I explicitly want to run the unit tests, I have to take the flag out again. What I want is for the unit tests not to be run when i do a build, but I do want them to run if I explicitly say so. The interactions between the Java and Test plugins don't seem to be flexible enough to allow this. My current solution is to move the unit tests out to a seperate project, but that seems like an arse-backwards way of going about it. Can anyone suggest a better approach? cheers kenny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ For the latest data on the economy and society consult National Statistics at http://www.statistics.gov.uk ** Please Note: Incoming and outgoing email messages are routinely monitored for compliance with our policy on the use of electronic communications ** Legal Disclaimer : Any views expressed by the sender of this message are not necessarily those of the Office for National Statistics ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Use of maven.test.skip
How about just running maven java:compile? or, do maven mybuild -Dmaven.test.skip=true Eric > -Original Message- > From: Kenny MacLeod [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 10, 2004 2:49 PM > To: Maven Users List > Subject: Use of maven.test.skip > > > Folks, > > I currently have a project where the unit tests take a > considerable amount of time to run (5 minutes or so), and as a > result, running them every time I do a build is proving > impractical. Initially, I just added the maven.test.skip flag to > my project.properties, but this isn't a good solution, mainly > because if I explicitly want to run the unit tests, I have to > take the flag out again. > > What I want is for the unit tests not to be run when i do a > build, but I do want them to run if I explicitly say so. The > interactions between the Java and Test plugins don't seem to be > flexible enough to allow this. > > My current solution is to move the unit tests out to a seperate > project, but that seems like an arse-backwards way of going about > it. Can anyone suggest a better approach? > > cheers > kenny > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use of maven.test.skip
Folks, I currently have a project where the unit tests take a considerable amount of time to run (5 minutes or so), and as a result, running them every time I do a build is proving impractical. Initially, I just added the maven.test.skip flag to my project.properties, but this isn't a good solution, mainly because if I explicitly want to run the unit tests, I have to take the flag out again. What I want is for the unit tests not to be run when i do a build, but I do want them to run if I explicitly say so. The interactions between the Java and Test plugins don't seem to be flexible enough to allow this. My current solution is to move the unit tests out to a seperate project, but that seems like an arse-backwards way of going about it. Can anyone suggest a better approach? cheers kenny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SV: Error in simple Maven build file
Sorry my bad
Must have been drinking to much this weekend... :-)
The problem is solved...
I was returning an error code..
Hi,
> -Original Message-
> From: ext Claus Pedersen [mailto:[EMAIL PROTECTED]
> The file test.c :
>
> int main()
> {
> int a = A;
> printf("a = %i",a);
> return a;
> }
> All the right values are returned, but why does it say
> [ERROR] after the
> execution?
My C(++) days lay years behind me, but I think you are giving back an
error code (return a), that's why maven assums, that something went
wront. try return 0 instead.
BR,
Andreas Ebbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error in simple Maven build file
Hi!
I think that you c code should return 0 as return value, usually other
than 0 means some error.
Artsi
ti, 2004-08-10 kello 13:53, Claus Pedersen kirjoitti:
> I have the following maven.xml file:
>
>
>
>
>
> ${i}
>
>
>
>
>
>
>
>
>
>
>
> The file test.c :
>
> int main()
> {
> int a = A;
> printf("a = %i",a);
> return a;
> }
>
> It looks like it works... I get the right output from the function
>
> Here is the Maven output:
>
> build:start:
>
> myGoal:
> [echo] 1
> [exec] a = 1
> [exec] [ERROR] Result: 1
> [echo] 2
> [exec] a = 2
> [exec] [ERROR] Result: 2
> [echo] 3
> [exec] a = 3
> [exec] [ERROR] Result: 3
> [echo] 4
> [exec] a = 4
> [exec] [ERROR] Result: 4
> [echo] 5
> [exec] a = 5
> [exec] [ERROR] Result: 5
> BUILD SUCCESSFUL
> Total time: 2 seconds
>
>
> All the right values are returned, but why does it say [ERROR] after the
> execution?
>
> I hope you have an answer.
>
> Best regards,
> Claus
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error in simple Maven build file
Hi,
> -Original Message-
> From: ext Claus Pedersen [mailto:[EMAIL PROTECTED]
> The file test.c :
>
> int main()
> {
> int a = A;
> printf("a = %i",a);
> return a;
> }
> All the right values are returned, but why does it say
> [ERROR] after the
> execution?
My C(++) days lay years behind me, but I think you are giving back an error code
(return a), that's why maven assums, that something went wront. try return 0 instead.
BR,
Andreas Ebbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Error in simple Maven build file
I have the following maven.xml file:
${i}
The file test.c :
int main()
{
int a = A;
printf("a = %i",a);
return a;
}
It looks like it works... I get the right output from the function
Here is the Maven output:
build:start:
myGoal:
[echo] 1
[exec] a = 1
[exec] [ERROR] Result: 1
[echo] 2
[exec] a = 2
[exec] [ERROR] Result: 2
[echo] 3
[exec] a = 3
[exec] [ERROR] Result: 3
[echo] 4
[exec] a = 4
[exec] [ERROR] Result: 4
[echo] 5
[exec] a = 5
[exec] [ERROR] Result: 5
BUILD SUCCESSFUL
Total time: 2 seconds
All the right values are returned, but why does it say [ERROR] after the
execution?
I hope you have an answer.
Best regards,
Claus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JCoverage and Junit do not give same test result
Hi, I'm using JCoverage plugin and Junit plugin in the same project. Junit report no failure and no error Jcoverage report an error with the same testcase. I've got a java.lang.VerifyError (Illegal constant pool index) I'm using the following properties: maven.test.failure.ignore=true maven.junit.fork=yes maven.junit.jvmargs=-Djava.awt.headless=true maven.compile.source=1.5 maven.compile.target=1.5 maven.jcoverage.junit.fork=yes Has anybody an idea of what happen? Best Regards Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
