Has there been a change to the custom PMD ruleset file format in recent years - and if so, how do I migrate? - pmd

I have a rule file that fails to be recognized by the PMD-IntelliJ plugin.
The plugin's author suggested I might be using an outdated custom ruleset (file) format version.
That's quite possible, the ruleset file is ages old, and so far was only used with Eclipse and its PMD plugin.
I am currently a bit short of time, so I was hoping someone could
let me know if there has been a format change to the custom PMD ruleset file formats in the last couple of years.
have a look at an excerpt from our rules file (posted below) and tell me what they think the file format version we use is; and
point me to an explanation of how to migrate to the most recent version.
I don't know anything about PMD so far, and just want to get this to work in IntelliJ. Medium-term, I plan on learning about it, but right now, I'm basically hoping for a quick fix... :)
P.S.: This is a cross-post from the PMD forums...
<?xml version="1.0" encoding="UTF-8"?>
<ruleset name="exampleruleset">
<description>foo bar</description>
<rule name="DoubleCheckedLocking"
message="Double checked locking is not thread safe."
class="net.sourceforge.pmd.rules.DoubleCheckedLocking"
externalInfoUrl="http://example.com/wiki/PMDRuleDoubleCheckedLocking">
<priority>1</priority>
</rule>
</ruleset>

It seems you are using a rule from PMD 4.x. With the switch to PMD 5 there have been a lot of incompatible changes like restructuring the packages.
It looks like, you just want to execute one rule, which is DoubleCheckedLocking. I agree with this suggestion to just reference the rule, like:
<?xml version="1.0"?>
<ruleset name="Custom ruleset"
xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
<description>This ruleset checks my code for bad stuff</description>
<rule ref="rulesets/java/basic.xml/DoubleCheckedLocking"/>
</ruleset>
The default priority of this rule is already "1", so there is no need to override the priority.
See also How to make a new rule set and the available rules.

Related

Why is Saxon throwing an error with the CentOS-distributed saxon.jar, but not with the saxon code from sourceforge?

I have an existing CentOS 7 server (setup by someone else, of course) running Saxon. If I run:
/usr/bin/java net.sf.saxon.Transform -s:input.xml -xsl:input.xsl -o:output.xml
...it works perfectly.
On a new server, I've installed Saxon via "yum install saxon". If I attempt the same command, it fails with the error:
Error at HTML on line 19 column 38 of 2.xsl:
XTSE0150: Simplified stylesheet: xsl:version attribute is missing
Failed to compile stylesheet. 1 error detected.
If I download the latest Saxon from sourceforge.net/projects/saxon, redirect my CLASSPATH from the yum-installed saxon.jar (dated 2014!) to the jar files from sourceforge, the transform works perfectly.
So, I have a FIX for the problem (i.e. use the latest from sourceforge, not CentOS's out-dated version) but I'm still curious as to what's going on.
Is this simply some old bug that's fixed in a newer release? Or maybe I'm missing supporting files that are in the sourceforge-derived jars, but not in the yum-derived files? Or something else???
For what it's worth, here's the head of my XSLT file. The error is specifically pointing at the end of the xsl:stylesheet tag, although there is clearly a "version=" setting in that config:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:oai-pmh="http://www.openarchives.org/OAI/2.0/"
xmlns:oai_qdc="http://worldcat.org/xmlschemas/qdc-1.0/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:dcmitype="http://purl.org/dc/dcmitype/"
xmlns:edm="http://www.europeana.eu/schemas/edm/"
xmlns:oclcdc="http://worldcat.org/xmlschemas/oclcdc-1.0/"
xsi:schemaLocation="http://worldcat.org/xmlschemas/qdc-1.0/
http://worldcat.org/xmlschemas/qdc/1.0/qdc-1.0.xsd
http://purl.org/net/oclcterms
http://worldcat.org/xmlschemas/oclcterms/1.4/oclcterms-1.4.xsd"
exclude-result-prefixes="xs"
version="2.0"
xmlns="http://www.loc.gov/mods/v3">
Given that the code works perfectly fine with the alternate Saxon install, I don't believe that there's a problem with the code. It's something else, but I don't know what...
You can find out which version of Saxon is in a particular JAR file by doing
java -cp saxon.jar net.sf.saxon.Version
and this would be a lot more useful than just telling us where you installed it from.
The error message suggests to me that the "stylesheet" being used is actually not a stylesheet at all, but an ordinary XML document. (Saxon sees that the root element isn't xsl:stylesheet, so it decides it must be a simplified stylesheet; then it looks for the xsl:version attribute, finds that there isn't one, and complains).
I don't know exactly what's wrong here, but the application is using an invocation of Saxon that works with one release and doesn't work with the other. There haven't been many incompatible changes to the command line interface over the 20 years of Saxon's life, but there have been a few, and I suspect one of these Saxon versions is very old indeed.
AFTERTHOUGHT
There's another clue which I missed on first reading: the error message refers to a file called 2.xsl. From the supplied information, we can't see what 2.xsl is. It must be the file that appears to be a stylesheet but isn't... But why does it have a different name? Certainly the fact that your file has the end of the start tag at line 19, and so does this mystery file, appears significant. Perhaps there's some script that's being executed before Saxon actually gets invoked, and that creates 2.xsl?

Use TeamCity 9 REST API to turn on Versioned Settings

I like to turn on Versioned Settings for my TeamCity projects, so that it commits its configuration in XML to the source control. However now I am seeking to do some automation around project creation leveraging the REST API. However, I can't figure out a way to turn on Versioned Settings via this API. Does anyone know how to do this? Is it supported?
This is not a direct and full answer yet, because it does not use the REST API, but this is an (admittedly hacky) way to accomplished the same thing in an automated way—and perhaps it will lead to a way to do it more properly through the API. Turns out that the file which stores this configuration is config\projects\<project-id>\pluginData\plugin-settings.xml under the TeamCity Data Directory. The documentation, under the section on Direct Modifications of Configuration Files says,
The files under the config directory can be edited manually (unless explicitly noted). The changes will be taken into account without the server restart. TeamCity monitors these files for changes and rereads them automatically when modifications or new files are detected. Bear in mind that it is easy to break the physical or logical structure of these files, so edit them with extreme caution. Always back up your data before making any changes.
Please note that the format of the files can change with newer TeamCity versions, so the files updating procedure might need adjustments after an upgrade.
I found that if I write this XML to said configuration file
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<versionedSettings rootId="Bitbucket" enabled="true" showChanges="true" buildSettings="PREFER_VCS" />
</settings>
then it not only registered the setting, but actually went ahead and did the initial commit of the settings. That's a win, though I still wish I could do it through a more stable API. Note: this XML will be different depending on the precise setup of your version settings—this represents my preferred configuration.
If anyone knows how to take this to the next level by doing it through the API I would still appreciate it.
If it is an option to upgrade to TeamCity 10 (which it is for me), it appears that TeamCity 10 supports this though the REST API! I will confirm that it solved what I needed after doing the upgrade.

How can I deploy an upgrade of my product which contains a file with version lower than the already deployed file?

I have a msi component which deploys a file MyFile.dll. I have a test machine in which my product already deployed MyFile.dll, which has version 09.99.99.99.
Now I'm writing a major upgrade which will deploy a new version of MyFile.dll with version 05.23.76.123. After execution on the test machine, MyFilee.dll is removed... I need to change or repair to correctly deploy it.
How can I force the deployment of MyFile.dll regardless of its injected version number?
PS: This is happening on our test machines only. The product we delivered to our users has files with version numbers consistent with release history.
There are several ways in Windows Installer to do this but they all have their complications. IMO I would just rebuild the same source code as the old DLL but with a newer higher version and keep it simple.
This is perfectly possible. As said here, you may specify the REINSTALLMODE property and set it to "amus" or "dmus" depending on whether you want to always overwrite files or simply overwrite files with different version:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
Note that you'll get this warning when compiling your installer though:
warning LGHT1076: ICE40: REINSTALLMODE is defined in the Property table. This may cause difficulties.
Downgrading a file isn't really straightforward and has issues. As pointed out earlier, you can change the component GUIDs and get this to work. However, it really depends on where your RemoveExistingProducts is sequenced. If its sequenced at a point where the older product is removed and the newer product is installed, then it might work.
There is not really a straight forward and documented way. All the available options are just hacks.
Is this just for your test environment?
If yes, then you could use REINSTALLMODE="amus" in the property table and achieve what you are looking to.
However, this is just for your testing and is not advised to be suggested to your end users.
Regards,
Kiran Hegde

why is my eclipse RCP product locked and can't be updated?

I am building an Eclipse RCP-based product, and I am running into an issue where when I try to use the built-in p2 UI to install updates to the product, I get an error message in the dialog that "Insufficient access privileges to apply this update."
I have debugged into Eclipse and found that the 'root cause' is that there is a p2 .profile file that has xml that includes this snippet:
<iuProperties id='com.datical.db.ui.product' version='1.33.0.201412032223'>
<properties size='4'>
<property name='org.eclipse.equinox.p2.internal.inclusion.rules' value='STRICT'/>
<property name='org.eclipse.equinox.p2.type.root' value='true'/>
<property name='org.eclipse.equinox.p2.type.lock' value='3'/>
<property name='org.eclipse.equinox.p2.base' value='true'/>
</properties>
</iuProperties>
The relevant line is the one that says <property name='org.eclipse.equinox.p2.type.lock' value='3'/>
I'm not sure what I am doing wrong - I think I must have something awry in my product definition or my feature definition or in my install process that is causing this line to be there.
When I step through the Eclipse code (our target environment is 3.7/Indigo) I see that the profile is being written inside org.eclipse.equinox.internal.p2.engine:SurrogateProfileHandler:addSharedProfileBaseIUs (which is private static.) That is called from SurrogateProfileHandler:createProfile
The product's p2 repository is being built using the tycho plugins, version 0.15.
We finally discovered another piece of information that may be relevant. We were using a custom OSGI directory name. When we removed that, everything started working as expected.
It seems that you have a shared install where the product you would like to update is (potentially) used by many installations as a base - and therefore cannot be updated.
This kind of problem goes beyond what can be answered well on stackoverflow because you'd really need to provide an example project and exact steps to reproduce the problem.
The most plausible cause for the symptoms you are seeing is some kind of file system permission problem. This documentation mentions that you need write permission to the installation directory for running Eclipse with -initialize. Maybe you are lacking some permissions making some of the -initialize procedure fail and leave the installation in an inconsistent state.

Using Haml & Sass with Eclipse

Are there any plugins for eclipse that add syntax highlighting and other niceties for editing Haml and Sass? Google searches only seem to point to a dead project on lucky-dip.net.
Note: it's Sass I'm most interested in. A solution for using just Sass (or something similar to it like less) in Eclipse would suit my needs.
Also, I'm developing for Google App Engine (Java), using the App Engine plugin for Eclipse. So switching to another IDE isn't an option.
Update: So I've got syntax highlighting now using Pascal's answer and I've installed Ruby and Compass to compile sass into css.
However I'm aware that the syntax of sass will be changing with 2.4 so I'd still like to get the Haml and Sass Editors that come with Aptana to work. When I tried to use them they threw an exception and wouldn't display the files. I'd be interested to know if that's because I misconfigured Aptana or is an actual bug in the editors.
I'd also be very interested in any way of compiling Sass that integrated with Ecplise so that I didn't have to run something separate from it. (or a way of putting Sass/Compass in the Ecplise build process.)
Well, what about Aptana? According to the Haml/Saas Syntax Highlighting in Aptana/Eclipse blog post:
Recently, I have been using Haml in
some my Rails projects. It simply
makes your views clean and readable.
One issue I had was syntax
highlighting in my favorite IDE,
Aptana Studio. The Haml syntax
highlighting support has been stopped
a while ago and more issues have
raised after Aptana recent updates.
After some research, I found a
solution posted by Max Kostovetski, a
member of Haml Google group. Now, to
the steps:
Download the following files to your hard drive:>
http://haml.googlegroups.com/web/haml_lexer.lxr
http://haml.googlegroups.com/web/haml.col
http://haml.googlegroups.com/web/sass_lexer.lxr
http://haml.googlegroups.com/web/sass.col
From AptanaEclipse "Window" menu, select "Preferences..."
In the the preferences window, select "Editors" > "Generic Text"
Press "Add..." to add new file extensions: *.haml and *.sass
For each of the new extensions, click it and press "Browse..." to
select the proper lexer file (*.lxr)
For colorization, press "Import..." to import the *.col files
Press "OK"
Enjoy you Haml views
PS: Refer to the original blog post as it provides up-to-date links.
Note: this can be used with the Aptana RadRails Eclipse plugin as well as Aptana Studio
UPDATE: At the time of writing, RadRails and Studio seems to support Haml and Sass so it might now be unnecessary to follow the steps above.
To compile SaaS in an "integrated" way inside Eclipse, you could maybe just use an External Tool (Run > External Tools). Another more elaborated option would be to add a "Program Builder" to your project's Builders like in this blog post. Of course, the described solution would require to be adapted to Saas but the principles behind it seems to apply. Caution: I didn't implement it myself, it's just an idea and I'm not even sure it makes sense.
Notice that latest EclipseColorer actually supports both HAML&SASS. It may be a good alternative choice if you don't need a full featured Aptana IDE, but just looking for an editor.
EclipseColorer also gives you better syntax mixin support: other languages inside of HAML are highlighted with respect of their syntax (mixins for ruby, javascript, css, even sass).
While it doesn't appear that there are any HAML or SASS syntax highlighters yet, you may want to consider doing something along the lines of bringing VIM (which does have support for HAML syntax highlighting) into Eclipse via a few available plugins. Eclim might be a possibility (although, I have not used it - just trying to offer other alternatives).
Another options is to take an already existing Eclipse syntax highlighting plug-in and add syntax highlighting for Sass and/or HAML. Something like the Eclipse Colorer may be worth looking into.
I know this is an old question, but for anyone new to SASS aond Compass like me, I just installed Aptana Studio 3 and it now has support for .scss, .sass, and .haml. Enjoy.
Aptana causes too many problems for me, so after lots of searching (which turned up this thread), I found
LiClipseText (https://marketplace.eclipse.org/content/liclipsetext)
It is a plugin that provides, amongst other things, syntax highlighting for SASS/SCSS files. It seems to work, and has "Syntax Highlighting (LiClipse, TextMate or SublimeText based)" so is probably quite configurable (I have not played around with it much, but the basic syntax highlighting feature is working for me, which is more than the Eclipse WST CSS editor could do for SCSS files).
It is the open-sourced editor component of the commercial LiClipse plugin (https://marketplace.eclipse.org/content/liclipse) which I have not used.
I found Colorer plugin in Igor's answer interesting, yet I use .scss file extention and it only works for .sass files. Here's how to make it support .scss file extension:
First install the plugin as normal. Select Install New software in Help menu in Eclipse and add the following repository: http://colorer.sf.net/eclipsecolorer. Now select this repository and you should see the Eclipse Colorer install option. There is no drag-install option AFAIK.
After install, goto Colorer plugin folder inside Eclipse's plugin directory. In my case that's eclipse/plugins/net.sf.colorer_0.9.9/. There you'll have to modify 3 files:
colorer/hrc/common.jar
colorer/hrc/proto.hrc
/plugin.xml
Before doing any of the below instruction, please backup all files in the folder in order to restore them if anything goes wrong.
Modifying common.jar
Extract common.jar to an empty folder. This is done as any normal tar.gz file. Once extracted you'll have to modify 2 files in it:
duplicate lines 53 and 53 in inet/haml.hrc and change it to scss. The result should be like below:
<block start='/^((\s\s)*):(sass)/' end='/^\M (\s*$|\y1\s)?! /ix' region='def:Insertion' region01='def:Outlined'
region00='def:PairStart' region10='def:PairEnd' content-priority='low' scheme='sass:sass'/>
<block start='/^((\s\s)*):(scss)/' end='/^\M (\s*$|\y1\s)?! /ix' region='def:Insertion' region01='def:Outlined'
region00='def:PairStart' region10='def:PairEnd' content-priority='low' scheme='scss:scss'/>
now copy inet/sass.hrc to inet/scss.hrc and change the relevant lines. The resulting scss.hrc should be like below:
<?xml version="1.0" encoding='Windows-1251'?>
<!DOCTYPE hrc PUBLIC "-//Cail Lomecb//DTD Colorer HRC take5//EN"
"http://colorer.sf.net/2003/hrc.dtd">
<hrc version="take5" xmlns="http://colorer.sf.net/2003/hrc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://colorer.sf.net/2003/hrc http://colorer.sf.net/2003/hrc.xsd">
<type name="scss">
<annotation>
<documentation>
SCSS Sassy CSS
</documentation>
<contributors><![CDATA[
Igor Russkih irusskih at gmail dot com
]]></contributors>
</annotation>
<region name="ClassSelector" parent="def:TypeKeyword"/>
<region name="IDSelector" parent="def:Keyword"/>
<region name="IncludeMixin" parent="def:Label"/>
<scheme name='PropertyNames'>
<regexp match="/(\$)([\w\d\-]+)/" region='def:Var'/>
<inherit scheme='css:PropertyNames'/>
</scheme>
<scheme name="PropertyWrapper">
<block start="/~/" end="/(:|\s|$)/" scheme="PropertyNames" region10="def:Symbol"/>
<regexp match="/(\$)([\w\d\-]+)/" region='def:Var'/>
<inherit scheme="css:Property"/>
</scheme>
<scheme name="scss">
<!-- property value after colon -->
<block start="/\M([\$\w\d\-]+)\s*(:)/" end="/\M([\x22\x27]|$)/"
scheme="PropertyWrapper" region02="def:Symbol"
/>
<block start="/(:)\s*\M([\w\d\-]+)?/" end="/\M([\x22\x27]|$)/"
scheme="PropertyWrapper" region02="def:Symbol"
/>
<regexp match="/^ \s* \M[\.\#\=\#\!] (?{def:Outlined}[\w\d\-]+ ) /x" />
<regexp match="/ \. (?{ClassSelector}[\w\d\-]+ ) /x" />
<regexp match="/ \# (?{IDSelector}[\w\d\-]+ ) /x" />
<regexp match="/ [\=\+] (?{IncludeMixin}[\w\d\-]+ ) /x" />
<regexp match="/[\(\)&apos;"]/" region='def:Symbol'/>
<regexp match="/\/\/.*$/" region='def:Comment'/>
<regexp match="/\#(import|extend|mixin)/" region='def:Keyword'/>
</scheme>
</type>
</hrc>
<!-- ***** BEGIN LICENSE BLOCK *****
- Version: MPL 1.1/GPL 2.0/LGPL 2.1
-
- The contents of this file are subject to the Mozilla Public License Version
- 1.1 (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
- http://www.mozilla.org/MPL/
-
- Software distributed under the License is distributed on an "AS IS" basis,
- WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
- for the specific language governing rights and limitations under the
- License.
-
- The Original Code is the Colorer Library.
-
- The Initial Developer of the Original Code is
- Igor Russkih <irusskih at gmail dot com>
- Portions created by the Initial Developer are Copyright (C) 2010
- the Initial Developer. All Rights Reserved.
-
- Contributor(s):
-
- Alternatively, the contents of this file may be used under the terms of
- either the GNU General Public License Version 2 or later (the "GPL"), or
- the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
- in which case the provisions of the GPL or the LGPL are applicable instead
- of those above. If you wish to allow use of your version of this file only
- under the terms of either the GPL or the LGPL, and not to allow others to
- use your version of this file under the terms of the MPL, indicate your
- decision by deleting the provisions above and replace them with the notice
- and other provisions required by the LGPL or the GPL. If you do not delete
- the provisions above, a recipient may use your version of this file under
- the terms of any one of the MPL, the GPL or the LGPL.
-
- ***** END LICENSE BLOCK ***** -->
after this, run the following command in the folder where you extract common.jar to recreate the jar file:
jar cf common.jar *
then substitute the original jar file by this one.
Other files
Now, include scss extension in /plugin.xml line 37:
extensions="xml,xsd,xsl,dtd,hrc,hrd,html,htm,xhtml,rhtml,erb,yml,haml,sass,scss,css,asp,aspx,jsp,fo,svg,dbk,docbook,jhtml,jspf,php,php3,php4,phtml,sgm,sgml,shtm,shtml"
And finally, duplicate lines 200-203 in colorer/hrc/proto.hrc. The result should be like below:
<prototype name="sass" group="inet" description="SASS">
<location link="jar:common.jar!inet/sass.hrc"/>
<filename>/\.(sass)$/i</filename>
</prototype>
<prototype name="scss" group="inet" description="SCSS">
<location link="jar:common.jar!inet/scss.hrc"/>
<filename>/\.(scss)$/i</filename>
</prototype>
After this restart eclipse and you should have syntax highlighting for .scss files.