0% found this document useful (0 votes)
110 views9 pages

Rulesets Index Integrated: M M M M

Checkstyle is a static analysis tool that checks Java code for potential issues like bugs, unused code, suboptimal code, and overly complex expressions. It can be integrated with many IDEs and build tools. PMD is a similar tool that finds common programming flaws by examining Java bytecode. Maven is a build tool that can be used to manage Java projects through its project object model and plugins.

Uploaded by

webdiwa
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
110 views9 pages

Rulesets Index Integrated: M M M M

Checkstyle is a static analysis tool that checks Java code for potential issues like bugs, unused code, suboptimal code, and overly complex expressions. It can be integrated with many IDEs and build tools. PMD is a similar tool that finds common programming flaws by examining Java bytecode. Maven is a build tool that can be used to manage Java projects through its project object model and plugins.

Uploaded by

webdiwa
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

c  scans Java source code and looks for potential problems like:

M cossible bugs - empty try/catch/finally/switch statements


M ead code - unused local variables, parameters and private methods
M uboptimal code - wasteful tring/tringBuffer usage
M 3vercomplicated expressions - unnecessary if statements, for loops that could be while
loops
M uplicate code - copied/pasted code means copied/pasted bugs

You can a  a


   , and you can get an overview of all the rules at the
rulesets index page.

c  is integrated with Jeveloper, Eclipse, JEdit, JBuilder, BlueJ, CodeGuide, NetBeans/un


Java tudio Enterprise/Creator, IntelliJ IEA, Textcad, aven, Ant, Gel, JCreator, and Emacs.

¦ 
 is a development tool to help programmers write Java code that adheres to a
coding standard. It automates the process of checking Java code to spare humans of this boring
(but important) task. This makes it ideal for projects that want to enforce a coding standard.

Checkstyle is highly configurable and can be made to support almost any coding standard. An
example configuration file is supplied supporting the un Code Conventions. As well, other
sample configuration files are supplied for other well known conventions.

A good example of a report that can be produced using Checkstyle and aven can be seen here.

¦    
             
      
                       
  

             ¦           
 
                

Checkstyle is most useful if you integrate it in your build process or your development
environment. The distribution includes:

M An Ant task.
M A command line tool.

¦ 
 is a free Java tool that calculates the percentage of code accessed by tests. It can
be used to identify which parts of your Java program are lacking test coverage. It is based on
jcoverage.
M Can be executed from ant or from the command line.
M Instruments Java bytecode after it has been compiled.
M Can generate reports in HT  or X .
M hows the percentage of lines and branches covered for each class, each package, and for
the overall project.
M hows the cCabe cyclomatic code complexity of each class, and the average
cyclomatic code complexity for each package, and for the overall product.
M Can sort HT  results by class name, percent of lines covered, percent of branches
covered, etc. And can sort in ascending or decending order.

Apache Maven      


 
    
       
       
  !"# " 
          
 
  
       
 

aven, a Yiddish word meaning p p


   , was originally started as an attempt
to simplify the build processes in the Jakarta Turbine project. There were several projects each
with their own Ant build files that were all slightly different and JARs were checked into CV.
We wanted a standard way to build the projects, a clear definition of what the project consisted
of, an easy way to publish project information and a way to share JARs across several projects.

The result is a tool that can now be used for building and managing any Java-based project. We
hope that we have created something that will make the day-to-day work of Java developers
easier and generally help with the comprehension of any Java-based project.

‘  


aven's primary goal is to allow a developer to comprehend the complete state of a development
effort in the shortest period of time. In order to attain this goal there are several areas of concern
that aven attempts to deal with:

M "       


M       
 

M    $     

M          
 
M       
   

‘   


 

While using aven doesn't eliminate the need to know about the underlying mechanisms,
aven does provide a lot of shielding from the details.
c      

aven allows a project to build using its project object model (c3 ) and a set of plugins that
are shared by all projects using aven, providing a uniform build system. 3nce you familiarize
yourself with how one aven project builds you automatically know how all aven projects
build saving you immense amounts of time when trying to navigate many projects.

c     


  

aven provides plenty of useful project information that is in part taken from your c3 and in
part generated from your project's sources. For example, aven can provide:

M ¦      
    
    
M ¦     
M "  
M     
M M         

The following are the key features of aven in a nutshell:

M imple project setup that follows best practices - get a new project or module started in
seconds
M Consistent usage across all projects means no ramp up time for new developers coming
onto a project
M uperior dependency management including automatic updating, dependency closures
(also known as transitive dependencies)
M Able to easily work with multiple projects at the same time
M A large and growing repository of libraries and metadata to use out of the box, and
arrangements in place with the largest 3pen ource projects for real-time availability of
their latest releases
M Extensible, with the ability to easily write plugins in Java or scripting languages
M Instant access to new features with little or no extra configuration
M Ant tasks for dependency management and deployment outside of aven
M odel based builds: aven is able to build any number of projects into predefined output
types such as a JAR, WAR, or distribution based on metadata about the project, without
the need to do any scripting in most cases.
M Coherent site of project information: Using the same metadata as for the build process,
aven is able to generate a web site or cF including any documentation you care to
add, and adds to that standard reports about the state of development of the project.
Examples of this information can be seen at the bottom of the left-hand navigation of this
site under the "croject Information" and "croject Reports" submenus.
M Release management and distribution publication: Without much additional
configuration, aven will integrate with your source control system such as CV and
manage the release of a project based on a certain tag. It can also publish this to a
distribution location for use by other projects. aven is able to publish individual outputs
such as a JAR, an archive including other dependencies and documentation, or as a
source distribution.
M ependency management: aven encourages the use of a central repository of JARs and
other dependencies. aven comes with a mechanism that your project's clients can use to
download any JARs required for building your project from a central JAR repository
much like cerl's CcAN. This allows users of aven to reuse JARs across projects and
encourages communication between projects to ensure that backward compatibility issues
are dealt with. We are collaborating with the folks at Ibiblio who have graciously allowed
the central repository to live on their servers.

‘  ‘  


  

‘p
pppp pp
p 
  

First, download aven and follow the installation instructions. After that, type the following in a
terminal or in a command prompt:

mvn --version

It should print out your installed version of aven, for example:

Maven version: 2.0.8


Java version: 1.5.0_12
OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"

epending upon your network setup, you may require extra configuration. Check out the Guide
to Configuring aven if necessary.

¦  c 




3n your command line, execute the following aven goal:

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -


DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

ëp 
p ‘p
pp p  
 
 p ‘p


p 
 
pp 
pp
  
 p 
pp
     p
p       p 
     p    
p p    
   p 
pp

You will notice that the 


p goal created a directory with the same name given as the
artifactId. Change into that directory.

cd my-app
Under this directory you will notice the following standard project structure.

my-app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- com
| `-- mycompany
| `-- app
| `-- App.java
`-- test
`-- java
`-- com
`-- mycompany
`-- app
`-- AppTest.java

The src/main/java directory contains the project source code, the src/test/java directory contains
the test source, and the pom.xml is the project's croject 3bject odel, or c3 .

 

The pom.xml file is the core of a project's configuration in aven. It is a single configuration file
that contains the majority of information required to build a project in just the way you want. The
c3 is huge and can be daunting in its complexity, but it is not necessary to understand all of
the intricacies just yet to use it effectively. This project's c3 is:

Îproject xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
ÎmodelVersion>4.0.0Î/modelVersion>
ÎgroupId>com.mycompany.appÎ/groupId>
ÎartifactId>my-appÎ/artifactId>
Îpackaging>jarÎ/packaging>
Îversion>1.0-SNAPSHOTÎ/version>
Îname>Maven Quick Start ArchetypeÎ/name>
Îurl>http://maven.apache.orgÎ/url>
Îdependencies>
Îdependency>
ÎgroupId>junitÎ/groupId>
ÎartifactId>junitÎ/artifactId>
Îversion>3.8.1Î/version>
Îscope>testÎ/scope>
Î/dependency>
Î/dependencies>
Î/project>

[  
 

You executed the aven goal p   !


p , and passed in various parameters to that goal.
The prefix p   is the plugin that contains the goal. If you are familiar with Ant, you may
conceive of this as similar to a task. This goal created a simple project based upon an archetype.
uffice it to say for now that a 
is a collection of p with a general common purpose.
For example the jboss-maven-plugin, whose purpose is "deal with various jboss items".

   


mvn package

The command line will print out various actions, and end with the following:

...
[INFO] ----------------------------------------------------------------------
--
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------
--
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006
[INFO] Final Memory: 3M/6M
[INFO] ----------------------------------------------------------------------
--

Unlike the first command executed (p   !


p ) you may notice the second is simply a
single word - p p . Rather than a goal, this is a p . A phase is a step in the build lifecycle,
which is an ordered sequence of phases. When a phase is given, aven will execute every phase
in the sequence up to and including the one defined. For example, if we execute the 
phase, the phases that actually get executed are:

6 
%  & 
  & 
'  & 
(  & 
) 


You may test the newly compiled and packaged JAR with the following command:

java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App

Which will print the quintessential:

Hello World!

- ‘ 

   

Although hardly a comprehensive list, these are the most common p lifecycle phases
executed.
M validateá               
  
M compileá 
           
M testá    
             
  *    
 $          
M packageá    
           
    + 
M integration-testá                 
   
     
M verifyá              
 $ 
M installá                            
 
M deployá          
            

                

There are two other aven lifecycles of note beyond the p list above. They are

M cleaná         

M siteá     


       

chases are actually mapped to underlying goals. The specific goals executed per phase is
dependant upon the packaging type of the project. For example, p p executes p!p if the
project type is a JAR, and p! p is the project type is - you guessed it - a WAR.

An interesting thing to note is that phases and goals may be executed in sequence.

mvn clean dependency:copy-dependencies package

This command will clean the project, copy dependencies, and package the project (executing all
phases up to p p , of course).

½   


mvn site

This phase generates a site based upon information on the project's pom. You can look at the
documentation generated under target/site.

[   c‘

c3 stands for "croject 3bject odel". It is an X  representation of a aven project held in


a file named pom.xml. When in the presence of aven folks, speaking of a project is speaking in
the philosophical sense, beyond a mere collection of files containing code. A project contains
configuration files, as well as the developers involved and the roles they play, the defect tracking
system, the organization and licenses, the UR of where the project lives, the project's
dependencies, and all of the other little pieces that come into play to give code life. It is a one-
stop-shop for all things concerning the project. In fact, in the aven world, a project need not
contain any code at all, merely a pom.xml.


 

This is a listing of the elements directly under the c3 's project element. Notice that
modelVersion contains 4.0.0. That is currently the only supported c3 version for aven 2,
and is always required.

Îproject xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
ÎmodelVersion>4.0.0Î/modelVersion>

Î!-- The Basics -->


ÎgroupId>...Î/groupId>
ÎartifactId>...Î/artifactId>
Îversion>...Î/version>
Îpackaging>...Î/packaging>
Îdependencies>...Î/dependencies>
Îparent>...Î/parent>
ÎdependencyManagement>...Î/dependencyManagement>
Îmodules>...Î/modules>
Îproperties>...Î/properties>

Î!-- Build Settings -->


Î uild>...Î/ uild>
Îreporting>...Î/reporting>

Î!-- More Project Information -->


Îname>...Î/name>
Îdescription>...Î/description>
Îurl>...Î/url>
ÎinceptionYear>...Î/inceptionYear>
Îlicenses>...Î/licenses>
Îorganization>...Î/organization>
Îdevelopers>...Î/developers>
Îcontri utors>...Î/contri utors>

Î!-- Environment Settings -->


ÎissueManagement>...Î/issueManagement>
ÎciManagement>...Î/ciManagement>
ÎmailingLists>...Î/mailingLists>
Îscm>...Î/scm>
Îprerequisites>...Î/prerequisites>
Îrepositories>...Î/repositories>
ÎpluginRepositories>...Î/pluginRepositories>
Îdistri utionManagement>...Î/distri utionManagement>
Îprofiles>...Î/profiles>
Î/project>
 


The c3 contains all necessary information about a project, as well as configurations of plugins
to be used during the build process. It is, effectively, the declarative manifestation of the "who",
"what", and "where", while the build lifecycle is the "when" and "how". That is not to say that
the c3 cannot affect the flow of the lifecycle - it can. For example, by configuring the maven-
antrun-plugin, one can effectively embed ant tasks inside of the c3 . It is ultimately a
declaration, however. Where as a uild.xml tells ant precisely what to do when it is run
(procedural), a c3 states its configuration (declarative). If some external force causes the
lifecycle to skip the ant plugin execution, it will not stop the plugins that are executed from doing
their magic. This is unlike a uild.xml file, where tasks are almost always dependant on the
lines executed before it.

Îproject xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
ÎmodelVersion>4.0.0Î/modelVersion>

ÎgroupId>org.codehaus.mojoÎ/groupId>
ÎartifactId>my-projectÎ/artifactId>
Îversion>1.0Î/version>
Î/project>

You might also like