Issue Details (XML | Word | Printable)

Key: SONARPLUGINS-35
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Freddy Mallet
Votes: 14
Watchers: 12
Operations

If you were logged in you would be able to see more operations.
Sonar Plugins

Integrate Macker, the architectural rule checking utility for Java developers

Created: 15/Feb/09 04:19 AM   Updated: 12/Nov/09 03:31 PM
Return to search
Component/s: Macker
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Related
 


 Description  « Hide

Whereas :

  • Checkstyle and PMD verify that code adheres to formatting, naming, style conventions and can detect bad programming practices : empty catch block, overide equals but not hashcode, etc.
  • And Findbugs finds potential bugs like an apparent infinite loop, method call passes null to a nonnull parameter, etc.

Macker could perfectly complement those tools by providing a way to define and check architectural rules :

  • Classes in the UI layer may not directly access the data object layer, or use classes in java.sql.
  • External systems may not access internal implementation classes (suffixed with 'Impl').
  • One functional module may access another only through its API.
  • Only classes implementing interfaces in javax.ejb, and certain framework packages, may use the EJB APIs.

Macker can so be considered as a new rules engine along with checkstyle, pmd and findbugs rules engine.

In the Configuration -> Settings, it should be possible to set the Macker's rules file. This rules file contains rulesets which are composed of rules (like PMD and Checkstyle). When loading or updating this rules file, the Macker plugin should automatically update rules in the Sonar's rules engine.



Freddy Mallet made changes - 15/Feb/09 04:20 AM
Field Original Value New Value
Component/s Macker [ 13745 ]
Freddy Mallet made changes - 15/Feb/09 04:43 AM
Description Whereas :
* Checkstyle and PMD verify that code adheres to formatting, naming, style conventions and can detect bad programming practices : empty catch block, overide equals but not hashcode, etc.
* Findbugs finds potential bugs like an apparent infinite loop, method call passes null to a nonnull parameter, etc.

[Macker|http://www.innig.net/macker/] could perfectly complement those tools by providing a way to define and check architectural rules :
* Classes in the UI layer may not directly access the data object layer, or use classes in java.sql.
* External systems may not access internal implementation classes (suffixed with 'Impl').
* One functional module may access another only through its API.
* Only classes implementing interfaces in javax.ejb, and certain framework packages, may use the EJB APIs.

Macker can so be considered as a new rules engine along with checkstyle, pmd and findbugs rules engine.

In the Configuration -> Settings, it should be possible to set the Macker's rules file. This rules file contains rulesets which are composed of rules (like PMD and Checkstyle). When loading or updating this rules file, the Macker plugin should automatically update rules in the Sonar's rules engine.
Freddy Mallet made changes - 15/Feb/09 04:44 AM
Description Whereas :
* Checkstyle and PMD verify that code adheres to formatting, naming, style conventions and can detect bad programming practices : empty catch block, overide equals but not hashcode, etc.
* Findbugs finds potential bugs like an apparent infinite loop, method call passes null to a nonnull parameter, etc.

[Macker|http://www.innig.net/macker/] could perfectly complement those tools by providing a way to define and check architectural rules :
* Classes in the UI layer may not directly access the data object layer, or use classes in java.sql.
* External systems may not access internal implementation classes (suffixed with 'Impl').
* One functional module may access another only through its API.
* Only classes implementing interfaces in javax.ejb, and certain framework packages, may use the EJB APIs.

Macker can so be considered as a new rules engine along with checkstyle, pmd and findbugs rules engine.

In the Configuration -> Settings, it should be possible to set the Macker's rules file. This rules file contains rulesets which are composed of rules (like PMD and Checkstyle). When loading or updating this rules file, the Macker plugin should automatically update rules in the Sonar's rules engine.
Whereas :
* Checkstyle and PMD verify that code adheres to formatting, naming, style conventions and can detect bad programming practices : empty catch block, overide equals but not hashcode, etc.
* And Findbugs finds potential bugs like an apparent infinite loop, method call passes null to a nonnull parameter, etc.

[Macker|http://www.innig.net/macker/] could perfectly complement those tools by providing a way to define and check architectural rules :
* Classes in the UI layer may not directly access the data object layer, or use classes in java.sql.
* External systems may not access internal implementation classes (suffixed with 'Impl').
* One functional module may access another only through its API.
* Only classes implementing interfaces in javax.ejb, and certain framework packages, may use the EJB APIs.

Macker can so be considered as a new rules engine along with checkstyle, pmd and findbugs rules engine.

In the Configuration -> Settings, it should be possible to set the Macker's rules file. This rules file contains rulesets which are composed of rules (like PMD and Checkstyle). When loading or updating this rules file, the Macker plugin should automatically update rules in the Sonar's rules engine.
Freddy Mallet made changes - 15/Feb/09 04:46 AM
Link This issue is related to SONAR-465 [ SONAR-465 ]
Freddy Mallet made changes - 15/Feb/09 04:54 AM
Assignee Freddy Mallet [ freddy.mallet ]
Freddy Mallet made changes - 15/Feb/09 04:55 AM
Link This issue is related to SONAR-501 [ SONAR-501 ]
Mike Nereson added a comment - 05/Mar/09 11:07 PM

I am the project lead of Architecture Rules at http://architecturerules.org. We are an alternative to Macker. I admire the sonar project and have wanted to develop a plugin to get into sonar since I discovered this project.

Architecture Rules can detect cyclic dependencies and, when rules are defined, can assert that certain packages do not depend on certain other packages. We can also tell you exactly what every package depends on. We also support wild cards.

I think that in order to be utilized by sonar, we need to finish one of the last remaining major features for our 3.0 release. That feature is an XML output of the findings of our tool. I imagine that sonar would need to utilize this XML to generate its output. You can read about our 3.0 roadmap at http://blog.architecturerules.org/30-roadmap/

I think we might be a better fit. We also have a maven 2 plugin which I believe will fit right into sonar. If you'd like to pursue this option, I can tailor our xml output to your needs since we have not written this output yet. Please let me know what you think.

Thank you for your consideration.


Freddy Mallet added a comment - 06/Mar/09 04:53 PM

Hi Mike, truly speaking we were discussing about Architecture Rules no longer than 3 days with Simon . As your project is alive and Macker's source code hasn't changed since 2003, we would prefer doing something with Architecture Rules. Nevertheless, I'm a bit disappointed by the dependency on JDepends for two reasons :

  • Like Macker, JDepends doesn't evolve any more, there isn't any users community or tracker
  • JDepends works at package level but doesn't provide any way to drill down to class level. So when you get a violation, you don't have any way to know between which classes are the violations ?

Don't want to disturb your roadmap, but I'm pretty sure jdepends can be totally rewritten in a matter of days with help of BCEL library. You could then provide the same features than Mackers does and we could even imagine to extend use of Architecture Rules to implement a DSM system ...

What's your feeling about that Mike ?


Mike Nereson added a comment - 07/Mar/09 02:56 PM

Freddy, I'm glad to hear that you found Architecture Rules before I brought it to you. Regarding the liveliness of Macker and JDepend, I should be up front you you guys that our project has been dead in the water for the past six months. I have been engaged in some classes and my team mates have also been busy, but I still want to grow our project.

Regarding JDepend, you are the third project lead to point out the short comings of JDepend. I believe its time to migrate our code base to something else, be it our own code, or a new and more versatile third party tool.

I brought Architecture Rules to you because I think that one way to grow our user base is to integrate into other products, such as Sonar and Hudson. I also think that we need to add additional features, such as DSM analysis.

Given all that, I can't do this alone, so I need to take this back to my team. I feel that we need to finish our 3.0 road map (which is just about done) and start to identify the next few releases, some of which would cater to sonar integration, and some of which would finish some of existing targets. It would look something like

3.0 listener support, xml output
3.1 maven 2 report
3.2 remove jdepend
3.3 DSM analysis
3.4 add DSM to maven 2 report

This discussion will take place on our dev list, I'd encourage you to join it if you'd like to help shape the discussion. Let me know that interests you and I will add you. Thanks.


Alexander von Zitzewitz added a comment - 15/Oct/09 07:52 PM

Help is on the way - the SonarJ Sonar plugin will be published in November 2009. We will also provide a free license to look at structural issues like the level of cyclic dependencies and metrics to estimate the effort to repair the structure. It would be interested to see these metrics on your Nemo instance.

Combined with a commercial license of SonarJ you will be able to see all architecture violations down to the code line.

More info: http://www.hello2morrow.com/products/sonarj


Stephan Kleine added a comment - 16/Oct/09 09:12 AM

The same is already possible with Architecture Rules which is is, contrary to your SonarJ stuff, 100% free. So please be so kind and keep the advertising out of a bugtracker. Thanks.


Alexander von Zitzewitz added a comment - 12/Nov/09 03:31 PM

The SonarJ plugin is now available. You can use it with our free Structure Analysis license or with your existing SonarJ-Report license.

Here is the plugin page: http://docs.codehaus.org/display/SONAR/SonarJ+Plugin

@Stephan:

This is a feature request. Some people might find it helpful to know, that a solution is available. Moreover we give free licenses to non-commercial projects and most open source projects.