4:34 p.m.
Hi all,
This email is just a info for everyone and a feedback of what being worked.
The main idea/architecture of this plugin is that you just write/add
individual Plexus Components that implements the QSChecker interface and
returns the result.
The result is written as a HTML file using maven-reporting.
More info: https://github.com/rafabene/qstools
Today I implemented the Layout 2 but I'll need to add an extra
information (the project artifactId) as a top level grouper.
I tried to execute the QSTools Report and it's plugins (checkstyle for
example) as a aggregator, but it become confusing since checkstyle (and
maybe other checks) running as an aggregator doesn't point the file
name, but the Java class.
So I'll have to change the implementation to not run it as aggregator,
but run the checks recursively and the layout will be something like this:
*- Project ArtifactId*
- file1.java
CheckerName X
violation message
line 1 (link to source)
CheckerName X
violation message
line 35 (link to source)
CheckerName Y
another violation message
3 (link to source)
- file2.java
CheckerName X
violation message
line 10 (link to source)
CheckerName Y
another violation message
line 15 (link to source)
*-Another Project\Subproject ArtifactId*
- file1.java
CheckerName X
violation message
line 1 (link to source)
CheckerName X
violation message
line 35 (link to source)
CheckerName Y
another violation message
3 (link to source)
- file2.java
CheckerName X
violation message
line 10 (link to source)
CheckerName Y
another violation message
line 15 (link to source)
Em 19/02/13 20:46, Rafael Benevides escreveu:
Hi all,
Today I worked with maven-report-plugin to generate the output of the
verification.
The source is here: https://github.com/rafabene/qstools
I want your opinion on what's the best report layout ?
Layout Option 1
(grouped by checker them file)
*CheckerName X
*- file1.java
violation message
line 1
violation message
line 35
- file2.java
violation message
line 10
*CheckerName Y*
- file1.java
another violation message
line 3
- file2.java
another violation message
line 15
------------------------------------------------------------------------
Layout Option 2
(grouped by file)
- file1.java
CheckerName X
violation message
line 1
CheckerName X
violation message
line 35
CheckerName Y
another violation message
3
- file2.java
CheckerName X
violation message
line 10
CheckerName Y
another violation message
line 15
Thanks for any comments.
Em 14/02/13 18:25, Rafael Benevides escreveu:
> Hi all,
>
> JDF is growing each day. As a consequence, keep the quickstarts
> consistent is becoming a hard work.
>
> To mitigate this and help the maintenance of the quickstart and also
> to help the contributors to see if their quickstarts are ready to
> review, we are planning and starting the development of a tooling for
> quickstart automation.
>
> This tool will make use of some other well know and opensource
> projects like PMD (pmd.sf.net), checkstyke (checkstyle.sf.net), Maven
> Enforcer plugin, etc to attend the following requirements:
>
> * Validating quickstart POM files:
> o Check for the License header (checkstyle headers
> <http://checkstyle.sourceforge.net/config_header.html>)
> o Check for proper spacing and Indentation (trycheckstyle
> <http://checkstyle.sourceforge.net/>-whitespace rule
>
<http://checkstyle.sourceforge.net/config_whitespace.html>andindentation
> rule
> <http://checkstyle.sourceforge.net/config_misc.html#Indentation>)
> o Check and verify if all quickstarts are using the same/latest
> BOM versions
> o Verify is it using the standard properties names (We will
> provide the standard properties name)
> o Check for non bom versions (and identify if we should create
> a new BOM)
> o Check javascript and css versions
> o Check for duplicate properties and dependencies
> o Check the pom.xml elements order
> o Create scripts to update versions (quickstart, boms, etc)
> o When a new quickstart is added, if it has a pom.xml file,
> make sure the <module> is defined in one of the following
> profiles: default, requires-postgres, complex-dependencies,
> requires-full, requires-xts, non-maven.
>
> * Validating quickstart README files:
> o Check for the required metadata tags in README (Level,
> Author, Target Product, etc)
> o Verify the quickstart name in the README matches the folder
> name and the project name
>
> * Validating quickstart source code
> o Check the quantity of comments in the code (evaluatePMD
> <http://pmd.sourceforge.net/pmd-5.0.2/rules/java/comments.html>)
>
> * General validation (desired):
> o If a quickstart with a source other than the current
> repository is modified, create an alert of some sort so we
> can notify the upstream repository of the change.
> o When we update a BOM property version in the quickstarts, we
> need to make the same changes in the archetypes.
> o Also, if there is a code fix in the kitchensink or
> kitchensink-ear, we need to make the same fix in the
> archetype code and check other quickstarts based on the same
> archetype to see if they need the fixes applied.
>
>
> If you have some comments, I will be glad to hear you.
>
> Thanks
> --
> Rafael Benevides | Senior Software Engineer
> Red Hat Brazil
> +55-61-9269-6576
>
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
>
> _______________________________________________
> jdf-dev mailing list
> jdf-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jdf-dev