
|
If you were logged in you would be able to see more operations.
|
|
|
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.
|
|
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.
- 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. |
Show » |
Sort Order:
made changes - 15/Feb/09 04:20 AM
| Field |
Original Value |
New Value |
|
Component/s
|
|
Macker
[ 13745
]
|
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.
|
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.
|
made changes - 15/Feb/09 04:46 AM
|
Link
|
|
This issue is related to SONAR-465
[ SONAR-465
]
|
made changes - 15/Feb/09 04:54 AM
|
Assignee
|
Freddy Mallet
[ freddy.mallet
]
|
|
|
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.