You might have noticed - or even been disappointed - by the slow rate of recent updates to this project.
After nearly 13 years of maintaining eclipse-cs I noticed that I am losing interest and updating this project is becoming a chore. Also I have been taking up different interest in my spare time, like playing guitar or getting a bit back in shape - which leaves even less time.
If you're interested in keeping this project afloat and more regularly updated - and want to lend a hand - please send me a personal message or reply to this forum post.
-- Lars
Last edit: Lars Koedderitzsch 2017-12-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Eric. There is effort required for actually updating the plugin to the latest Checkstyle version. Most of the time the bulk of work is hunting down Checkstyle changes which require metadata changes using the Checkstyle release notes.
The build itself is automated via Maven/Tycho, however, getting a release out is a multi-stepped, non-automated process.
For instance updating the plugin from 8.0 to 8.5 took me about a day of work for updating and releasing. If I had updated to all intermediary Checkstyle versions, that work would have been more spread out, of course.
One of these days I'll write a step by step checklist for updating/releasing the plugin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What about having an organizational (not individual) account at github to host the sources? This works well for a lot of projects and allows more easy contributions by others than the Sourceforge system. I just created https://github.com/eclipsecs as a placeholder to showcase this. However, I will happily transfer ownership of that account to you (or delete it, if you want to do something similar on your own).
Just to be clear: I do not intend to become a new lead for this project. I'm willing to contribute some time however, and I guess you will find more additional like-minded contributors, if this project moves to github.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lars, I am willing to help with bug fixes and releases. If you don't want to write up the release steps, you could demonstrate everything in my WebEx channel and I could record it and write the steps from that. That way I could ask questions along the way and possibly have stuff repeated for clarity. Let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Lars,
thanks a lot for your help through may years to keep project up todate.
I could recommend to move source to github - https://github.com/checkstyle , to our organization . You and Eric and Bananeweizen could have RW access to repository to keep it moving, any other contributors are welcome too. I already did suh a proposal to you few years ago ;) . I managed to setup good practices in development workflow in checkstyle repo and amount of Pull requests is far above I can process, but we keep going ....
This will help us to keep all sources(plugins) neaby main project(checkstyle).
We already host sonar plugin under our organization.
Checkstyle core library is very tiny, we will not be able to do support of eclise-cs without help from community, any contributors are welcome. But we can host code and help with updates to new checkstyle versions.
Last edit: Roman Ivanov 2018-01-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Roman - thanks and agreed, hosting eclipse-cs sources under the Checkstyle organisation in Github would be the best course. I'll send you a private message shortly.
@Richard - interesting, although I am unsure how this can help with eclipse-cs metadata maintenance. As I understand I would still need to meticulously check all changes in a Checkstyle release, whether they have any relevance for the metadata.
Ideally Checkstyle itself would expose this metadata (e.g. via annotations) to integration providers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am unsure how this can help with eclipse-cs metadata maintenance. As I understand I would still need to meticulously check all changes in a Checkstyle release, whether they have any relevance for the metadata.
Could you give an example of something you think would have to be manually done and couldn't be automated? I can only speak from my experience with sevntu's eclipse-cs files.
Even if you can't automate everything, doing some should alleviate some of the stress.
I imagine sevntu metadata is maintained alongside the checks, so whenever you change something (add a property, new check etc.) you will update the eclipse-cs metadata accordingly?
For eclipse-cs this is not the case. Instead once in a while I need to check all changes in Checkstyle for their relevance to the metadata.
For example: a new check is added a check gets a new property an existing property is changed - for instance changes to allowed or default tokens addition of new message keys
* or the removal of any of the above
I am not sure the Checkstyle xdocs contain all the necessary informations and even if it does it would be somewhat backwards. I feel rather Checkstyle itself should expose all the necessary metadata and docs should be generated from that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I feel rather Checkstyle itself should expose all the necessary metadata
I agree but we had a discussion about this and we have not come to a conclusion on what data should be in the metadata and how it should be stored.
One point of discussion was: https://github.com/checkstyle/regression-tool/issues/29
I suggest you bring it up again in an issue in main project and keep asking for a solution from us.
I imagine sevntu metadata is maintained alongside the checks, so whenever you change something (add a property, new check etc.) you will update the eclipse-cs metadata accordingly?
Yes, but it is not a manual process like you might imagine. We always forget to update documentation. Instead, we are required to enter these changes by CI through the JUnit or else the build will fail and the fix will not be allowed to be merged.
As long, as Checkstyle is part of the classpath in the JUnit, you can use classpath scanning and reflection to get almost any data you need and automate the building of the metadata.
a new check is added
a check gets a new property
changes to allowed or default tokens
addition of new message keys
removal of any of the above
The JUnit can handle all of these cases right now.
Eric Milles and Bananeweizen you are very welcome to become contributors/maintainers of eclipse-cs please create issues on github to request RW access and start sharing knowledge transfer from Lars.
Fact eclipse-cs is hosted under checkstyle organization does not mean that checkstyle maintainers could maintain it too.
Checkstyle core library have about 20 active PRs each day, that waiting to be merged or other feedback. Checkstyle team can not keep up even with core project.
Please be welcome to be part of team.
Last edit: Roman Ivanov 2018-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great solution with moving to the checkstyle organization, and much better than my initial suggestion. I've deleted the temporary eclipsecs organization account on github to not cause any confusion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's my fifty cents on maintaining CS / ECLIPSE-CS metadata:
I maintain a CS extension called "cs-contrib", and face the same challenge: Provide metadata about my extension to CS and ECLIPSE-CS, and keeping that in sync with the implementation.
For exactly this purpose I developed the JAVADOC doclet
It looks at the classes declared in a set of packages (in my case: de.unkrig.cscontrib.checks and de.unkrig.cscontrib.filters) and checks which of these classes are annotated with @de.unkrig.csdoclet.annotation.Rule and which of their members that are annotated with @Messageor @*RuleProperty. Then it analyzes the members' signatures, the annotations and their arguments, and the members' doc comments.
Hey there!
You might have noticed - or even been disappointed - by the slow rate of recent updates to this project.
After nearly 13 years of maintaining eclipse-cs I noticed that I am losing interest and updating this project is becoming a chore. Also I have been taking up different interest in my spare time, like playing guitar or getting a bit back in shape - which leaves even less time.
If you're interested in keeping this project afloat and more regularly updated - and want to lend a hand - please send me a personal message or reply to this forum post.
-- Lars
Last edit: Lars Koedderitzsch 2017-12-20
Hi Lars. Thanks for all your hard work over the years. I have been using eclipse-cs for many years now.
Just wondering how much effort is required (aka how much is automated in terms of operations)?
Hey Eric. There is effort required for actually updating the plugin to the latest Checkstyle version. Most of the time the bulk of work is hunting down Checkstyle changes which require metadata changes using the Checkstyle release notes.
The build itself is automated via Maven/Tycho, however, getting a release out is a multi-stepped, non-automated process.
For instance updating the plugin from 8.0 to 8.5 took me about a day of work for updating and releasing. If I had updated to all intermediary Checkstyle versions, that work would have been more spread out, of course.
One of these days I'll write a step by step checklist for updating/releasing the plugin.
What about having an organizational (not individual) account at github to host the sources? This works well for a lot of projects and allows more easy contributions by others than the Sourceforge system. I just created https://github.com/eclipsecs as a placeholder to showcase this. However, I will happily transfer ownership of that account to you (or delete it, if you want to do something similar on your own).
Just to be clear: I do not intend to become a new lead for this project. I'm willing to contribute some time however, and I guess you will find more additional like-minded contributors, if this project moves to github.
Lars, I am willing to help with bug fixes and releases. If you don't want to write up the release steps, you could demonstrate everything in my WebEx channel and I could record it and write the steps from that. That way I could ask questions along the way and possibly have stuff repeated for clarity. Let me know.
Hi Lars,
thanks a lot for your help through may years to keep project up todate.
I could recommend to move source to github - https://github.com/checkstyle , to our organization . You and Eric and Bananeweizen could have RW access to repository to keep it moving, any other contributors are welcome too. I already did suh a proposal to you few years ago ;) . I managed to setup good practices in development workflow in checkstyle repo and amount of Pull requests is far above I can process, but we keep going ....
This will help us to keep all sources(plugins) neaby main project(checkstyle).
We already host sonar plugin under our organization.
Checkstyle core library is very tiny, we will not be able to do support of eclise-cs without help from community, any contributors are welcome. But we can host code and help with updates to new checkstyle versions.
Last edit: Roman Ivanov 2018-01-01
I assume you mean the metadata files that define checks, properties, and they descriptions, values, etc... like \net.sf.eclipsecs.checkstyle\metadata...
Have you though of automating most of it? Sevntu automates it's eclipse-cs files using junits that tell when something is wrong or missing in the file. We use reflection and our inner utils to identify checks and their properties.
See: https://github.com/sevntu-checkstyle/sevntu.checkstyle/blob/master/sevntu-checks/src/test/java/com/github/sevntu/checkstyle/internal/ChecksTest.java#L76-L90
@Roman - thanks and agreed, hosting eclipse-cs sources under the Checkstyle organisation in Github would be the best course. I'll send you a private message shortly.
@Richard - interesting, although I am unsure how this can help with eclipse-cs metadata maintenance. As I understand I would still need to meticulously check all changes in a Checkstyle release, whether they have any relevance for the metadata.
Ideally Checkstyle itself would expose this metadata (e.g. via annotations) to integration providers.
Could you give an example of something you think would have to be manually done and couldn't be automated? I can only speak from my experience with sevntu's eclipse-cs files.
Even if you can't automate everything, doing some should alleviate some of the stress.
The most complete documentation we have is in the xdocs where we have another junit to make sure it has required sections, all properties documented with descriptions and default values and such.
https://github.com/checkstyle/checkstyle/blob/master/src/test/java/com/puppycrawl/tools/checkstyle/internal/XdocsPagesTest.java#L253
Last edit: Richard 2018-01-02
I imagine sevntu metadata is maintained alongside the checks, so whenever you change something (add a property, new check etc.) you will update the eclipse-cs metadata accordingly?
For eclipse-cs this is not the case. Instead once in a while I need to check all changes in Checkstyle for their relevance to the metadata.
For example:
a new check is added
a check gets a new property
an existing property is changed - for instance changes to allowed or default tokens
addition of new message keys
* or the removal of any of the above
I am not sure the Checkstyle xdocs contain all the necessary informations and even if it does it would be somewhat backwards. I feel rather Checkstyle itself should expose all the necessary metadata and docs should be generated from that.
I agree but we had a discussion about this and we have not come to a conclusion on what data should be in the metadata and how it should be stored.
One point of discussion was: https://github.com/checkstyle/regression-tool/issues/29
I suggest you bring it up again in an issue in main project and keep asking for a solution from us.
Yes, but it is not a manual process like you might imagine. We always forget to update documentation. Instead, we are required to enter these changes by CI through the JUnit or else the build will fail and the fix will not be allowed to be merged.
As long, as Checkstyle is part of the classpath in the JUnit, you can use classpath scanning and reflection to get almost any data you need and automate the building of the metadata.
The JUnit can handle all of these cases right now.
To get list of checks (new and old), we scan the classpath. https://github.com/sevntu-checkstyle/sevntu.checkstyle/blob/master/sevntu-checks/src/test/java/com/github/sevntu/checkstyle/internal/CheckUtil.java#L111
Once we have the class object, we use reflection to get it's property names. https://github.com/sevntu-checkstyle/sevntu.checkstyle/blob/master/sevntu-checks/src/test/java/com/github/sevntu/checkstyle/internal/ChecksTest.java#L393
From there, you can instantiate the object pretty easily and use more reflection to get property values.
What it can't handle are descriptions and default values. Descriptions are maintained through the Javadocs and xdocs. Default values are a new addition, and will be added with PR https://github.com/checkstyle/checkstyle/pull/5402 . I will be adding these reflection methods to our production area so other projects can use them instead of rewriting them https://github.com/checkstyle/checkstyle/issues/5415.
You can see the benefits of this junit when we first started using it to validate our metadata: https://github.com/sevntu-checkstyle/sevntu.checkstyle/commit/46a33f8ad4da433fda0a6df21d1693cfab8975a9#diff-9384125e21f8807f29f0b2b0ad791a94
We had missing checks, messages, and properties. Everything was found by the junit.
FYI the move of eclipse-cs sources to Github as a first measure is a go, see https://github.com/checkstyle/eclipse-cs
Thanks to @Bananeweizen for suggesting and to @Roman for taking it under the wings of the Checkstyle organisation at Github
Eric Milles and Bananeweizen you are very welcome to become contributors/maintainers of eclipse-cs please create issues on github to request RW access and start sharing knowledge transfer from Lars.
Fact eclipse-cs is hosted under checkstyle organization does not mean that checkstyle maintainers could maintain it too.
Checkstyle core library have about 20 active PRs each day, that waiting to be merged or other feedback. Checkstyle team can not keep up even with core project.
Please be welcome to be part of team.
Last edit: Roman Ivanov 2018-01-03
Great solution with moving to the checkstyle organization, and much better than my initial suggestion. I've deleted the temporary eclipsecs organization account on github to not cause any confusion.
Here's my fifty cents on maintaining CS / ECLIPSE-CS metadata:
I maintain a CS extension called "cs-contrib", and face the same challenge: Provide metadata about my extension to CS and ECLIPSE-CS, and keeping that in sync with the implementation.
For exactly this purpose I developed the JAVADOC doclet
http://unkrig.de/w/Cs-doclet
that generates the following files from the extension's source code:
de/unkrig/cscontrib/checks/checkstyle-metadata.properties
de/unkrig/cscontrib/checks/checkstyle-metadata.xml
de/unkrig/cscontrib/checks/messages.properties
de/unkrig/cscontrib/filters/checkstyle-metadata.properties
de/unkrig/cscontrib/filters/checkstyle-metadata.xml
de/unkrig/cscontrib/filters/messages.properties
de/unkrig/cscontrib/ui/quickfixes/messages.properties
It looks at the classes declared in a set of packages (in my case:
de.unkrig.cscontrib.checksandde.unkrig.cscontrib.filters) and checks which of these classes are annotated with@de.unkrig.csdoclet.annotation.Ruleand which of their members that are annotated with@Messageor@*RuleProperty. Then it analyzes the members' signatures, the annotations and their arguments, and the members' doc comments.It also generates a JAVADOC-like HTML documentation, which you can marvel at here: http://cs-contrib.unkrig.de/csdoc/
The ANT scripts that run JAVADOC with the doclet can be found here:
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib.core/build.ant
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib_dist/build.ant
Example:
From the class
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib.core/src/de/unkrig/cscontrib/checks/NameSpelling.java
, the cs-doclet generates the "CSDOC" page
http://cs-contrib.unkrig.de/csdoc/checks/NameSpelling.html
, and the necessary entries in
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib.core/src/de/unkrig/cscontrib/checks/checkstyle-metadata.properties
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib.core/src/de/unkrig/cscontrib/checks/checkstyle-metadata.xml
https://svn.code.sf.net/p/loggifier/code/trunk/de.unkrig.cs-contrib.core/src/de/unkrig/cscontrib/ui/quickfixes/messages.properties
Fully automated in my release process.