Re: Funny reactor bug in rc1
It should be being set relative to the project.xml being processed. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Paul Libbrecht [EMAIL PROTECTED] wrote on 08/11/2003 09:13:38 AM: Hi Maveners, I had the funny following bug when running the jelly project.xml in reactor: commonDependencies.ent file not found. I was, of course, in a different directory and it looks like the parser on the project.xml doesn't set the system-id correctly... Maybe it's already fixed in CVS ? Paul - 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: Funny reactor bug in rc1
Why ? I know it should be thus, it worked doing a symbolic link but the program manipulating the parser should set the systemId and not only give a stream to the parser! Paul [EMAIL PROTECTED] wrote: It should be being set relative to the project.xml being processed. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Paul Libbrecht [EMAIL PROTECTED] wrote on 08/11/2003 09:13:38 AM: Hi Maveners, I had the funny following bug when running the jelly project.xml in reactor: commonDependencies.ent file not found. I was, of course, in a different directory and it looks like the parser on the project.xml doesn't set the system-id correctly... Maybe it's already fixed in CVS ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building Maven
Seems it already is. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Alain Javier Guarnieri del Gesu [EMAIL PROTECTED] wrote on 08/11/2003 01:53:39 AM: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2003-11-07 06:16]: Horn, Cameron [EMAIL PROTECTED] wrote on 06/11/2003 02:57:36 PM: Re: return codes I'll submit an issue for it tomorrow, but if anyone was curious, here's a snippet: snip [exec] + [exec] | Building Maven VDoclet Plug-in [exec] | Memory: 156M/158M [exec] + snip [exec] java:compile: [exec] [echo] Compiling to C: \blah\jbuild\maven\src\plugins-build\vdoclet/target/classes [exec] [javac] Compiling 1 source file to C: \blah\jbuild\maven\src\plugins-build\vdoclet\target\classes [exec] BUILD FAILED [exec] com.werken.werkz.UnattainableGoalException: Unable to obtain goal [plugin] -- file:/C:/Documents and Settings/hornc/. maven/plugins/java/:55:48: ant:javac Error starting modern compiler snip very long error description [exec] Unable to obtain goal [plugin] -- file:/C:/Documents and Settings/hornc/.maven/plugins/java/:55:48: ant:javac Error starting modern compiler [echo] [echo] +--+ [echo] || [echo] | I N S T A L L I N G T H E P L U G I N S| [echo] || [echo] +--+ [echo] snip happily continuing build I don't know when this was taken from, but CVS HEAD no longer has the vdoclet plugin as part of the bootstrap process. BTW, the bootstrap process is built in Ant for the most part. I suppose we could update the bootstrap exec to failonerror. +1. Fail fast. Fail loud. -- Alain Javier Guarnieri del Gesu - [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: Funny reactor bug in rc1
Sorry, I did not mean I know it should be thus but I know it's working this way but that it should not be thus. Paul Paul Libbrecht wrote: Why ? I know it should be thus, it worked doing a symbolic link but the program manipulating the parser should set the systemId and not only give a stream to the parser! Paul [EMAIL PROTECTED] wrote: It should be being set relative to the project.xml being processed. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Paul Libbrecht [EMAIL PROTECTED] wrote on 08/11/2003 09:13:38 AM: Hi Maveners, I had the funny following bug when running the jelly project.xml in reactor: commonDependencies.ent file not found. I was, of course, in a different directory and it looks like the parser on the project.xml doesn't set the system-id correctly... Maybe it's already fixed in CVS ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: war plugin : [maven.caller.call.compile-java] is not defined
Ok, I think I understand what you mean now. You want to have a
distributed workflow instead of a centralized one. So you want to move
from WKG to WKP (Well-Known Plugins).
What I don't like is that it means not all plugins will be equal, some
will be more equal than others ;-) It also means that 'other' plugins
will be tied to all WKPs.
I think I may agree with you, if the WKP are empty shells only, unlike
what is currently the case. It means that instead of having one caller
plugin, you'll have a caller-compile, caller-test, caller-whatever
plugins... delegating to the real implementations like java:compile,
aspectj:compile, etc.
In the end, your proposal looks like an extension to the caller plugin,
i.e. having several call plugins instead of one. It may or may not be
better.
However, I do think this workflow stuff has to be in Maven core. With
the current Maven implementation, I'd say it's a tag. Actually if I find
a few hours, I'll reimplement the caller plugin as a jelly tag in Maven
core.
But do we agree that ideally the WKP must not have implementation logic?
They delegate to implementing plugins.
What do others think?
Thanks
-Vincent
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 07 November 2003 21:39
To: Maven Users List
Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 9:08 PM
To: 'Maven Users List'
Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 07 November 2003 19:36
To: Maven Users List
Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined
[snip]
That in goal war:init:
goal name=war:init
description=Initialize the file system and attain any
necessary
goals
ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
/j:if
ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
/goal
There should be no call to caller plugin
just something like
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
and it should be up to (just an example - I am not imposing
anything)
java
plugin to handle this call (In place of WKG there will be WKG in
Well
Know
Plugin).
I would not like at all that the java plugin has to know about all
the
other plugins (like the aspectj plugin, the xdoc plugin, etc).
Me neither
what I want to have (writen with caller plugin sematic)
goal name=java:compile
j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
/j:if
/goal
If we have:
j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/ (e.g
x:compile=java:compile)
attainGoal name=test:test/
/j:if
And if there is some interception, then it is *very* misleading
because
the reader will think the java plugin will be called but in practice
it
will be some other plugin's goal.
Exactly that's the point. java plugin and java:compile plugin will be
always called and should be always called!.
So you can add prepostGoals for java:compile
and the do
maven.caller.call.compile-java = javac:compile
or
maven.caller.call.compile-java = jikes:compile
if you call
caller:call goalInterface=compile-java/ from war plugin you have
to
change blocks like
preGoal name=java:compile
do something here
.preGoal
every time you want to change a compiler.
Michal
-
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: Getting cactus error output into the report
Hi Daniel, It looks like it's a limitation of the Maven junit-report plugin. Could you post a JIRA improvement report for the junit-report plugin. Although I haven't tested it, I believe you'll also not see stack trace information for pure junit tests when using Maven. Thanks -Vincent -Original Message- From: Daniel Rabe [mailto:[EMAIL PROTECTED] Sent: 04 November 2003 01:34 To: '[EMAIL PROTECTED]' Subject: Getting cactus error output into the report I'm using maven with the cactus plugin on Windows XP. If one of my cactus tests gets an error (it throws an exception), a stack trace is emitted into the .txt and .xml files in target/test-cactus-reports/tomcat5x. However, the report that's generated by the cactus plugin only shows the exception message. It would really be helpful to have the actual stack trace in the report. Is there any way I can configure maven and/or the cactus plugin to do this? Thanks, Daniel Rabe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting cactus error output into the report
Oops. Actually this may not be true. I had forgotten there was a cactus.jsl file in the cactus plugin. I'll have a look and fix this. Thanks -Vincent -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 08 November 2003 11:56 To: 'Maven Users List' Cc: [EMAIL PROTECTED] Subject: RE: Getting cactus error output into the report Hi Daniel, It looks like it's a limitation of the Maven junit-report plugin. Could you post a JIRA improvement report for the junit-report plugin. Although I haven't tested it, I believe you'll also not see stack trace information for pure junit tests when using Maven. Thanks -Vincent -Original Message- From: Daniel Rabe [mailto:[EMAIL PROTECTED] Sent: 04 November 2003 01:34 To: '[EMAIL PROTECTED]' Subject: Getting cactus error output into the report I'm using maven with the cactus plugin on Windows XP. If one of my cactus tests gets an error (it throws an exception), a stack trace is emitted into the .txt and .xml files in target/test-cactus-reports/tomcat5x. However, the report that's generated by the cactus plugin only shows the exception message. It would really be helpful to have the actual stack trace in the report. Is there any way I can configure maven and/or the cactus plugin to do this? Thanks, Daniel Rabe - 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: Getting cactus error output into the report
Ok, I've had a better look. I was right. The cactus.jsl is an exact copy of the junit-report's junit.jsl file which does not display stack trace. So I'd say you should open a bug report against the junit-report plugin and I'll make sure that I update Cactus's cactus.jsl file. Thanks -Vincent -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 08 November 2003 12:27 To: 'Maven Users List' Cc: [EMAIL PROTECTED] Subject: RE: Getting cactus error output into the report Oops. Actually this may not be true. I had forgotten there was a cactus.jsl file in the cactus plugin. I'll have a look and fix this. Thanks -Vincent -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 08 November 2003 11:56 To: 'Maven Users List' Cc: [EMAIL PROTECTED] Subject: RE: Getting cactus error output into the report Hi Daniel, It looks like it's a limitation of the Maven junit-report plugin. Could you post a JIRA improvement report for the junit-report plugin. Although I haven't tested it, I believe you'll also not see stack trace information for pure junit tests when using Maven. Thanks -Vincent -Original Message- From: Daniel Rabe [mailto:[EMAIL PROTECTED] Sent: 04 November 2003 01:34 To: '[EMAIL PROTECTED]' Subject: Getting cactus error output into the report I'm using maven with the cactus plugin on Windows XP. If one of my cactus tests gets an error (it throws an exception), a stack trace is emitted into the .txt and .xml files in target/test-cactus-reports/tomcat5x. However, the report that's generated by the cactus plugin only shows the exception message. It would really be helpful to have the actual stack trace in the report. Is there any way I can configure maven and/or the cactus plugin to do this? Thanks, Daniel Rabe - 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: How do I move maven.log?
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]
RE: war plugin : [maven.caller.call.compile-java] is not defined
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Saturday, November 08, 2003 11:54 AM To: 'Maven Users List' Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined Ok, I think I understand what you mean now. You want to have a distributed workflow instead of a centralized one. So you want to move from WKG to WKP (Well-Known Plugins). What I don't like is that it means not all plugins will be equal, some will be more equal than others ;-) It also means that 'other' plugins will be tied to all WKPs. I think I may agree with you, if the WKP are empty shells only, unlike what is currently the case. It means that instead of having one caller plugin, you'll have a caller-compile, caller-test, caller-whatever plugins... delegating to the real implementations like java:compile, aspectj:compile, etc. In the end, your proposal looks like an extension to the caller plugin, i.e. having several call plugins instead of one. It may or may not be better. I don't want to introduce a bunch of new plugins. In first place we can reuse existsing plugins (java, test) with some resonable defaults (e.g java:compile goal will call javac:compile). We are alredy providing skeletal workflow with well defined states ( I like names of the goals like java:compile etc.). but simply some of the states of our workflow are not customizable. However, I do think this workflow stuff has to be in Maven core. With the current Maven implementation, I'd say it's a tag. Actually if I find a few hours, I'll reimplement the caller plugin as a jelly tag in Maven core. I am not sure what you mean by workflow stuff has to be in Maven core. It's alredy there. Also I am not sure if we need something as fancy as caller taglib. Take a look at multiproject:install-callback goal. Such logic should be sufficient for the most of the cases. Special things might be needed when we will have to load implementor plugin from the repository. But this can be handled by maven core. [..] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classpath
Could someone point me to an example of how to setup a classpath from using the dependencies so that it can be used with the ant:java tag? TIA -ScottTavares- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath
never mind... I found it... Scott Tavares wrote: Could someone point me to an example of how to setup a classpath from using the dependencies so that it can be used with the ant:java tag? TIA -ScottTavares- - 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]
Ant Goal
Hi, I use Maven to generate an Ant file so people do not need to install Maven to build a source distribution (those crazy people :-). I recently added the 'maven.javadoc.links' property to my project.properties. The issue is that when I generate the Ant file there is no link child element of the javadoc element. I haven't looked at the implementation of the Ant plugin but I presume it only examines the project descriptor and not the associated properties file also. Is this the case? Thanks, -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Checkstyle Configuration
Hi, Is it possible to override configuration settings in the current Checkstyle plugin like it was possible when properties files were used? For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. I notice that the turbine config just redefines all of the sun settings as well as the ones they wanted to change. I think it would be a neat feature to support configuration importing. Then the turbine config could look like this: ?xml version=1.0? !DOCTYPE module PUBLIC -//Puppy Crawl//DTD Check Configuration 1.1//EN http://www.puppycrawl.com/dtds/configuration_1_1.dtd; modules import href=sun_checks.xml/ module name=TreeWalker !-- ** -- !-- Checks that are different from the sun coding conventions ones -- !-- ** -- property name=tabWidth value=4/ module name=LeftCurly property name=option value=nl/ /module module name=RightCurly property name=option value=alone/ /module module name=LineLength property name=ignorePattern value=@version/ /module module name=MemberName property name=format value=^f[A-Z][a-zA-Z0-9]*$/ /module /module /modules Modules defined in the 'importing' document override those defined in the 'imported' one. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: including source in jar
* Vikas Phonsa [EMAIL PROTECTED] [2003-11-07 21:19]: Can I have the jar goal generate a jar that includes the source code file also beside the .class files. I've been asking about creating separate debug and release build targets for some time now. A debug target would have a source jar. This would make is easy to deploy the artifacts for use with Eclipse. -- Alain Javier Guarnieri del Gesu - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle Configuration
* John Keyes [EMAIL PROTECTED] [2003-11-09 00:49]: Hi, Is it possible to override configuration settings in the current Checkstyle plugin like it was possible when properties files were used? maven.checkstyle.properties=my-checkstyle.xml For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. a) Be warned, the sun_checks.xml do not implement the sun coding standard. b) Have you seen Jalopy? http://jalopy.sourceforge.net/ There is a 'jalopy' goal. I use both. -- Alain Javier Guarnieri del Gesu - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle Configuration
Is it possible to override configuration settings in the current Checkstyle plugin like it was possible when properties files were used? maven.checkstyle.properties=my-checkstyle.xml Yes but I have to specify all of the rules again in that file. I think it should be extensible. For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. a) Be warned, the sun_checks.xml do not implement the sun coding standard. Why not? It's bad that it doesn't work as advertised. b) Have you seen Jalopy? http://jalopy.sourceforge.net/ There is a 'jalopy' goal. Yeah, but it doesn't haven any relevance to this discussion. I just like the idea of being able to import a base standard and customize that as I see fit. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle Configuration
Yes but I have to specify all of the rules again in that file. I think it should be extensible. I don't see why. Its a configuration file. Create your own configuration. It is just as easy to copy the file and edit it. Of course you can. I just think its a step backwards in comparison to the previous version. For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. a) Be warned, the sun_checks.xml do not implement the sun coding standard. Why not? It's bad that it doesn't work as advertised. Read the Sun coding standards. They don't AvoidInlineConditionals, for example. The Sun coding standard says nothing about DesignForExtension, since design is not an aspect of formatting. Correct your RedundantThrows and then there is no way to javadoc a method that might throw both an IOException and a FileNotFoundException. Loath FinalParameters. Well then the file should not be called sun_checks.xml, it is just another user configuration. The sun coding standard support should do exactly what it says on the tin and nothing more. b) Have you seen Jalopy? http://jalopy.sourceforge.net/ There is a 'jalopy' goal. Yeah, but it doesn't haven any relevance to this discussion. I just like the idea of being able to import a base standard and customize that as I see fit. It is relevent. With Jalopy your code will comply to the Sun coding standards. Is that now what you want? For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. I know how to resolve the issue, I am just highlighting an area of weakness (IMO) with the current version. Cheers, -John K - 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]
Re: How do I move maven.log?
Scott,
placing the log in ~/.maven makes sense, except when you run multiple
mavens simultaneously.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Scott Brickner [EMAIL PROTECTED] wrote on 09/11/2003 03:22:06 PM:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle Configuration
Alain, if you have an alternative checkstyle file for the sun_checks.xml, I'm happy to replace the existing one. Patches are always welcome. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Alain Javier Guarnieri del Gesu [EMAIL PROTECTED] wrote on 09/11/2003 02:30:23 PM: * John Keyes [EMAIL PROTECTED] [2003-11-09 02:02]: Is it possible to override configuration settings in the current Checkstyle plugin like it was possible when properties files were used? maven.checkstyle.properties=my-checkstyle.xml Yes but I have to specify all of the rules again in that file. I think it should be extensible. I don't see why. Its a configuration file. Create your own configuration. It is just as easy to copy the file and edit it. For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. a) Be warned, the sun_checks.xml do not implement the sun coding standard. Why not? It's bad that it doesn't work as advertised. Read the Sun coding standards. They don't AvoidInlineConditionals, for example. The Sun coding standard says nothing about DesignForExtension, since design is not an aspect of formatting. Correct your RedundantThrows and then there is no way to javadoc a method that might throw both an IOException and a FileNotFoundException. Loath FinalParameters. b) Have you seen Jalopy? http://jalopy.sourceforge.net/ There is a 'jalopy' goal. Yeah, but it doesn't haven any relevance to this discussion. I just like the idea of being able to import a base standard and customize that as I see fit. It is relevent. With Jalopy your code will comply to the Sun coding standards. Is that now what you want? For example, I would like to use the sun coding standard as the base for my coding standard and I want to change some of the settings. -- Alain Javier Guarnieri del Gesu - [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: including source in jar
Alain, where did we get with this? Last I remember, my suggest was to use the dist plugin, not the jar plugin. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Alain Javier Guarnieri del Gesu [EMAIL PROTECTED] wrote on 09/11/2003 12:45:46 PM: * Vikas Phonsa [EMAIL PROTECTED] [2003-11-07 21:19]: Can I have the jar goal generate a jar that includes the source code file also beside the .class files. I've been asking about creating separate debug and release build targets for some time now. A debug target would have a source jar. This would make is easy to deploy the artifacts for use with Eclipse. -- Alain Javier Guarnieri del Gesu - [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]
