Menu
▾
▴
#76 .properties should be in user home
We have a problem with the checkstyle suppressions.
First I don't understand why we can't just put the
filename of the suppressions file. Why doesn't the
location default to the same directory as the
checkstyle config? Ok, so we use
${basedir}../maven/checkstyle.xml and that works. But
when we build with maven, basedir isn't set. And we
can't use the .properties because we'd have to put it
in CVS and that would affect all users.
If the .properties were called checkstyle.properties
(or eclipse-cs.properties) and were located in the
user's home directory, then we could set it for our
maven build without putting it in CVS. My experience
has shown that all files specifying paths that are
specific for the user should be located in the user's home.
Logged In: YES
user_id=1238882
It just doesn't work that way, because checkstyle needs a
fully qualified path to the suppressions file.
Using the properties like {basedir} helps as it avoids the
need to hardcode absolute paths into the checkstyle.xml.
Most build environments like maven or ant support to set
such properties in the build context - so I guess when
${basedir} is not set by maven by default you just need to
define it in your project.properties.
You dont necessarily need to hardcode paths, maybe
something like
basedir=${maven.src.dir}/../
will work as well.
Alternativly to ${basedir} you can consider using the
${config_loc) property thats built into the plugin (read
docs here http://eclipse-
cs.sourceforge.net/advanced_properties.html) - the property
points to the directory where the configuration file lies.
But this property must also be set in the maven context for
your configuration to work in maven too.
Please understand that I cannot deeply support you in
configuring your maven build as I am no maven expert - but
I am pretty sure you can get it to work with my hints.
Regards,
Lars Ködderitzsch
Logged In: YES
user_id=655163
First, the docs for checkstyle show a relative path and not
a full path:
http://checkstyle.sourceforge.net/config.html
"For example, the following configuration fragment directs
the Checker to use a SuppressionFilter with suppressions
file docs/suppressions.xml:
<module name="SuppressionFilter">
<property name="file" value="docs/suppressions.xml">
</property></module>
"
So either the checkstyle docs are incorrect and need to be
updated, or checkstyle can take a relative path (relative to
what? the config file I assume).
Second, for maven I am looking into it.
Finally, the real point of this feature request is to
question the usefulness of a .properties. First of all,
.properties is a bad choice for a name because it's too
common. A project can have several toosl or frameworks that
use .properties. Second, having it in the same directory as
the checkstyle configuration seems pointless. The file
should contain paths that would be specific to a given
enviornment and/or user. This should be stored in the
user's environment (ie. user's home dir). Any file in the
project's directory has to be in CVS, or copied via a script
which is sloppy.
So the point of this feature request is not to find a way to
work with maven but to signal that the .properties isn't
very easy to use, and if the docs for checkstyle are correct
and a relative path can be specified for the supressions
file, it's not necessary.
Since these issues haven't been explained I will re-open.
Logged In: YES
user_id=1238882
Yes, the checkstyle docs example is misleading as relative
paths are interpreted as relative to the JVMs working dir -
which is mostly the directory from where the VM Checkstyle
runs in was startet. In case of the plugin this is most
likely the eclipse installation directory.
You see, its quite pointless to use true relative paths.
I also cannot change this behaviour from inside the plugin
as checkstyle creates the file references with just new File
("thePropertyValue").
So the only way except using relative paths is augumenting
paths with properties, which the resolve to a absolute path
at runtime.
For the feature request on the .properties files - I could
try to load the .properties file from the users home dir
and if not found fall back to the original location (same
dir as checkstyle.xml).
The .properties file name will probably stay - its true
that .properties file are common to many tools - but, hey,
it's a very common mechanism.
Please also note that there are more features on resolving
properties in the 4.1.0 beta builds, for instance we can
now resolve properties from classpath variables set up
inside eclipse or from environment properties passed into
the eclipse VM via the -D parameter.
This is not documented yet but you will find hints in the
4.1.0 beta release notes.
Logged In: YES
user_id=1238882
Oh, and moving to feature requests as it is not a bug.
Logged In: YES
user_id=498804
The Maven relative file path is always relative to the POM
file (project.xml. pom.xml). The Eclipse relative path
seems to vary, but is not from the "root" of the project
(which would be best!). Typically the Maven POM file is
located at the root of the project.
This is the hard thing of using the Checkstyle Eclipse
plugin and the Maven plugin together.
Maven defines ${basedir} as where the POM file is. Not sure
what you mean by "${basdir} is not defined to Maven".
According to the Eclipse CS docs:
"${basedir} - gets mapped to the current project directory"
Does this work for you, placed in the checkstyle rules XML file?
<module name="SuppressionFilter">
<property name="file" value="${basedir}/path/to/CheckstyleSuppressions.xml">
</property></module>
Lastly, the X.properties file goes with the X.xml file; it
is not named ".properties" on its own, you provide a base
name matching the base name of your rules file.
Also not sure why you would want that file elsewhere (other
than needed hardcoding of paths, but you should use relative
instead so that is not necessary), and it should be source
controlled along with the Checkstyle rules file and any
suppression file.
I may be misunderstanding something you are trying to
communicate, but am hoping the above may help explain a few
things...
Logged In: YES
user_id=655163
"Maven defines ${basedir} as where the POM file is. Not sure
what you mean by "${basdir} is not defined to Maven"."
Maven defines ${basedir} for its files but not for
checkstyle. How could Maven tell checkstyle to use
c:\workspace\myproject instead of ${basedir}?
"file?
<module name="SuppressionFilter">
<property name="file" value="${basedir}/path/to/CheckstyleSuppressions.xml">
</property></module>"
This works for eclipse but not for maven. The only way we
can get it to work is to copy the file over itself having
maven use the ANT filters to replace ${basedir} with the
correct path.
I didn't understand that the .properties was named after the
name of the checkstyle config, now I see that in the docs.
But you say that file should be stored in CVS and I
disagree. let's say on my PC the project is in
C:\workspace\myproject but on my coworker's pc it's in
D:\eclipse\myproject and on the build machine
/home/maven/build/myproject. How can we have one single
file with 3 different values for the location of the
supressions file? If this file was in the user home, each
user could set it with their specific directory.
The method I described above is exactly how settings.xml in
m2 works (build.properties in maven 1). Files that specify
an environment specific to a user should NOT go into CVS.
They can't.
There are still two things I don't understand that haven't
been answered:
1 - are the checkstyle docs wrong? does it really need a
full path? I don't think so, because of this statement:
"Using External, Remote or Project Relative Configuration
you can write the properties you need to be expanded into a
.properties file that lies in the same directory as the
configuration file and has the same name. "
2 - if checkstyle can find the .properties by looking in the
same directory as the checkstyle config, then surely it
could find the supression.xml in the same directory as well.
Something doesn't make sense here.
-Michael
Logged In: YES
user_id=498804
Ah yes, understand your point on "${basedir} is not defined to
Maven" - you mean not defined in the Maven Checkstyle plugin.
For our setup, the Maven project.properties file has these
settings for the rules and suppression files:
maven.checkstyle.properties=${basedir}/src/conf/checkstyle/checkstyle.xml
maven.checkstyle.suppressions.file=${basedir}/src/conf/checkstyle/checkstylesuppressions.xml
Then, set the <module> property as you need for Eclipse CS.</module>
Does this work for you?
You consider the Eclipse CS "X.properties" file as a per
user config, and its intent is not that. It is a project
config file (just like the rules file it pairs with), hence,
source controlled for all to use.
Specifically to your point, yes different developers may
have different locations/dir paths to the root of a project.
Therefore, specify all paths either relatively, or
absolutely starting with a property variable such as
${basedir} (this allows hardcoding the paths relative to the
project root).
I understand how the Maven build.properties/settings.xml
files work, and my team has never had to use them. All of
our paths for Maven as well are specified in the manner I
describe above. This allows the utmost in happy/easy out of
box experience - developer does a "get latest" and builds.
There are no custom artifacts in the workspace needed before
the thing works.
Note that requiring a custom source file not in source
control before a build works is not a true reproducible
build! This is a failure in configuration.
1 - I don't think so. Perhaps Lars would do us a fav and
expand the docs on it.
2 - Yes, it could, but that is an enhancement request to the
Eclipse CS plugin! Checkstyle specifies things relative to
current dir. Use the ${basedir} for the prefix to your
suppressions file to absolute it from the project root.
Logged In: YES
user_id=655163
This I understand:
maven.checkstyle.properties=${basedir}/src/conf/checkstyle/checkstyle.xml
maven.checkstyle.suppressions.file=${basedir}/src/conf/checkstyle/checkstylesuppressions.xml
but not this:
"Then, set the <module> property as you need for Eclipse
CS."</module>
If I use the maven properties, I don't see how the
eclipse-cs plugin will find the supressions. If I keep the
line of code in the checkstyle config xml, then maven will
choke on it.
Logged In: YES
user_id=498804
M1 or M2?
Maven Checkstyle plugin version?
I'm on M1 with CS plugin 3.0, which uses Checkstyle 4.1.
Maven does not choke on this for me:
<module name="SuppressionFilter">
<property name="file" value="${basedir}/src/conf/checkstyle/CheckstyleSuppressions.xml">
</property></module>
Logged In: YES
user_id=1238882
How about specifying the suprression file path in the
checkstyle.xml with
${config_loc}/suppression.xml (when suppression file lies
in the same dir as the checkstyle.xml).
The plugin will automatically resolve the ${config_loc}
property to the directory the checkstyle.xml lies in.
In your maven/project.properties define the ${config_loc}
property:
config_loc=${basedir}/src/conf/checkstyle
You wouldn't need an additional checkstyle.properties file
for this.
To clarify the thing with relative paths:
Checkstyle uses the path(s) that are configured in the
configuration file (checkstyle.xml). To instantiate the
files from the path it uses new File("theConfiguredPath").
In case a relative path is configured it relativly easy to
say what happens - java treats the relative path as
relative to the JVM working dir, which is normally the dir
from where the jvm was started. In case of eclipse this is
most likely the eclipse installation dir.
There is no way how I can influence checkstyle treats
relative paths - so features like "just treat all relative
paths as relative to the project dir" are impossible to
implement.
Please point me again to the portions in the doc that are
misleading about the whole topic - at best with a
suggestion how to explain things better. As I am no native
english speaker I sometimes have a bit of a hard time
finding the easiest, most striking explanation.
Logged In: YES
user_id=1238882
Set to pending to wait for further arguments.
I think the docs are pretty clea on how to use
the .properties files for property expansion, there is even
a small example that shows how it must be done.
From the docs:
If you have more properties that need to be expanded there
is another feature for you.
Using External, Remote or Project Relative Configuration
you can write the properties you need to be expanded into
a .properties file that lies in the same directory as the
configuration file and has the same name.
For instance:
D:/path/to/my/config/myCheckConfiguration.xml
can resolve properties defined in
D:/path/to/my/config/myCheckConfiguration.properties
Expandable properties within your configuration file will
then be resolved from the corresponding .properties file.
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).