Re: Maven on JDK1.5
Um, JDK 1.5 isn't yet the current release of Java. It's still only beta. On Mon, 2004-07-26 at 13:59, Malachi de AElfweald wrote: Thanks to everyone for their help... Adding those two properties (either -D or project.properties) fixed the problem. A couple thoughts/comments 1) Searching through the issue-tracking, two people posted the same bug and never got a reply. http://jira.codehaus.org/browse/MPJAVA-22 http://jira.codehaus.org/browse/MPJAVA-24 2) shouldn't the default release be compatible with the current release of Java without tweaking? 3) Perhaps the main maven site should be update with a quick tip in the install directions? OR, perhaps add that as a part of the FAQ 4) perhaps the main maven site should list the bug database along with the current listings of FAQ,Wiki,and user mailing list? Thanks again, Malachi At 11:26 PM 7/24/2004, Dion Gillard wrote: maven.compile.source=1.5 and maven.compile.target=1.5? javac: target release 1.1 conflicts with default source release 1.5 - 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: Can I suppress the junit output?
That doesn't help at all. I'm already using that. My issue is that for a given class in the test tree I get output like this: [junit] Testcase: testSimpleParsing took 0.044 sec [junit] Testcase: testChildParsing took 0 sec [junit] Testcase: testAttributeParsing took 0 sec [junit] Testcase: testCombinedParsing took 0.001 sec [junit] Running com.flashtalk.verona.directory.DispatcherTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.158 sec [junit] Testsuite: com.flashtalk.verona.directory.DispatcherTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.158 sec [junit] That's nine lines in the output, just to tell me it passed the test. The timing and other details are nice to have in the junit report for the site, but they're completely useless when I'm doing a build from inside vim. I want to suppress the output if the test passes and only be notified of test failures. Honestly, the output as it's currently generated goes against the spirit of the whole JUnit test package. A passing testcase should generate *no* output. On Tue, 2003-12-30 at 03:06, Emmanuel Venisse wrote: You can fork junit with this : maven.junit.fork=true Emmanuel - Original Message - From: Scott Brickner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 29, 2003 11:00 PM Subject: Can I suppress the junit output? How can I fix things so I don't get the 5+ lines of output on the console for every single testcase? I really only want to know when a test fails. The xml reports are fine for when I'm building the site, but 99% of the time I'm building during new development and just want failing testcases. In my ant build files, I used to run the junit task with the brief formatter. That's kind of what I'm looking for here. What are my options? - 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]
Can I suppress the junit output?
How can I fix things so I don't get the 5+ lines of output on the console for every single testcase? I really only want to know when a test fails. The xml reports are fine for when I'm building the site, but 99% of the time I'm building during new development and just want failing testcases. In my ant build files, I used to run the junit task with the brief formatter. That's kind of what I'm looking for here. What are my options? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCoverage plugin problem
On Wed, 2003-12-17 at 15:16, Emmanuel Venisse wrote: Plugin is released. You can download it. Emmanuel Great. This looks to be working now. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCoverage plugin problem
maven-jcoverage-plugin-1.0.1 (seems to happen with 1.0, too) On Wed, 2003-12-03 at 15:04, Emmanuel Venisse wrote: What's you jcoverage plugin version? Emmanuel - Original Message - From: Scott Brickner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 01, 2003 9:08 PM Subject: JCoverage plugin problem I just added the jcoverage report to my project and it's not running right. Has anyone seen this before? The actual text referenced in the exception is \357\277\275. The output of the JCoverage task is below... jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY Generate report for /home/scottb/projects/verona/target/jcoverage/coverage.xml file. OutputDir = /home/scottb/projects/verona/target/docs/jcoverage java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48 ) at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1207) at java.lang.Double.valueOf(Double.java:202) at java.lang.Double.init(Double.java:277) at org.apache.maven.jcoveragereport.CoverageReport.generatePercentResult(Covera geReport.java:493) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFile(CoverageR eport.java:425) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFiles(Coverage Report.java:391) at org.apache.maven.jcoveragereport.CoverageReport.generate(CoverageReport.java :96) at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(CoverageRep ortGenerator.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:87) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.CatchTag.doTag(CatchTag.java:90) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) 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 com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag. java:107) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) 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 com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag. java:107) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135
JCoverage plugin problem
I just added the jcoverage report to my project and it's not running right. Has anyone seen this before? The actual text referenced in the exception is \357\277\275. The output of the JCoverage task is below... jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY Generate report for /home/scottb/projects/verona/target/jcoverage/coverage.xml file. OutputDir = /home/scottb/projects/verona/target/docs/jcoverage java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1207) at java.lang.Double.valueOf(Double.java:202) at java.lang.Double.init(Double.java:277) at org.apache.maven.jcoveragereport.CoverageReport.generatePercentResult(CoverageReport.java:493) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFile(CoverageReport.java:425) at org.apache.maven.jcoveragereport.CoverageReport.generateSourceFiles(CoverageReport.java:391) at org.apache.maven.jcoveragereport.CoverageReport.generate(CoverageReport.java:96) at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(CoverageReportGenerator.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:87) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.CatchTag.doTag(CatchTag.java:90) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) 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 com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) 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 com.werken.werkz.jelly.AttainGoalTag.doTag(AttainGoalTag.java:134) at org.apache.maven.jelly.tags.werkz.LazyAttainGoalTag.doTag(LazyAttainGoalTag.java:107) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145) 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.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at
Re: How do I move maven.log?
On Sun, 2003-11-09 at 01:40, [EMAIL PROTECTED] wrote:
placing the log in ~/.maven makes sense, except when you run multiple
mavens simultaneously.
Placing it in the current working directory doesn't make any more sense.
The --find option lets you run maven from pretty much anywhere in your
project tree. I tend to run it from within vi, and I tell vi to cd to
the package's source directory to make it easier to switch between
multiple files. That means I get maven.log in every directory where I
happen to do a build.
Having it go to ~/.maven or ${basedir} or /tmp or whatever would be much
more useful.
Frankly, it would be even *more* useful if maven didn't produce a log
file unless it had something useful to say. Generating two lines of
output every time - the same two lines that come at the end of the
normal console output - is dumb.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do I move maven.log?
Does this seem stupid to anyone else? I mean, the log files are there to
analyze maven when things go wrong, they aren't specific to the project
- so why should they end up in the project directory? ~/.maven would
make more sense, I'd think. And they shouldn't have *anything* unless
something does go wrong (or if I ask for a higher-than-normal level of
verbosity).
On Sat, 2003-11-08 at 09:41, Jim Crossley wrote:
Hi Scott
Scott Brickner [EMAIL PROTECTED] writes:
Maven is littering my project folders with maven.log files, none of
which say anything useful (just info on the running time). Is there
some officially supported way for me to make it put that log
somewhere else? Or to suppress it entirely when things are running
fine?
I don't think so. In the past, I've solved this in two ways:
1. Write a custom 'clean' [pre|post]goal (either in maven.xml or a
shared plugin) something like this:
goal name=realclean
attainGoal name=clean/
delete quiet=true
fileset dir=${basedir} includes=**/*~,**/*.log defaultexcludes=no/
/delete
/goal
2. Modify the log4j.properties file inside ${MAVEN_HOME}/lib/maven.jar
The latter option would enable you to fully-qualify the path of the
log file to put it somewhere else.
Jim
-
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]
How do I move maven.log?
Maven is littering my project folders with maven.log files, none of which say anything useful (just info on the running time). Is there some officially supported way for me to make it put that log somewhere else? Or to suppress it entirely when things are running fine? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
