Pages

08 June, 2012

Sonar Setup...Instructions(MySql)

 Step By Step Procedure to Configure Sonar for MYSQL:

Please follow the link to configure the Sonar with MySql:

http://docs.codehaus.org/display/SONAR/Installing+Sonar

Step1:Download Sonar 2.11 From Website

Step2: Copy The Folder and Extract the Folder

Step3: Down Load and Install  MYSQL(5.1) server

And create the database for the same.(for creating sample database please click https://github.com/SonarSource/sonar/blob/master/sonar-application/src/main/assembly/extras/database/mysql/create_database.sql)

Step4:    In D:/sonar-2.11\conf\sonar.properties file 
Uncomment below code: For MySql

 sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
sonar.jdbc.driverClassName: com.mysql.jdbc.Driver
sonar.jdbc.validationQuery: select 1


Then Start the Sonar and check the log file:

to Start the Sonar:

D:/sonar-2.11\bin\windows-x86-32/StartSonar.bat

run the StartSonar.bat from console.

And also copy the extensions folder with customized rules.xml
under the D:\sonar-2.11 directory(overwrite the extension folder)

Then........

Download the sonar-runner-1.3 form WebSite

Copy the sonar-runner-1.3 zip folder and extract the same.

Then Edit the D:\sonar-runner-1.3\conf\sonar-runner.properties

i.e Uncomment the MySql code.

And Create the sonar-project.properties file and put this file under D:\sonar-runner-1.3\bin directory.



D:\sonar-2.11\conf\sonar.properties:

#-------------------------------------------------------- # To use an environment variable, use the following syntax : ${env:NAME_OF_ENV_VARIABLE} # For example : # sonar.jdbc.url: ${env:SONAR_JDBC_URL} # # # See also the file conf/wrapper.conf for JVM advanced settings #--------------------------------------------------------- #--------------------------------------------------------- # WEB SETTINGS - STANDALONE MODE ONLY # These settings are ignored when the war file is deployed to a JEE server. #--------------------------------------------------------- # Listen host/port and context path (for example / or /sonar). Default values are 0.0.0.0:9000/. #sonar.web.host: 0.0.0.0 #sonar.web.port: 9000 #sonar.web.context: / # Log HTTP requests. Deactivated by default. #sonar.web.jettyRequestLogs: ../../logs/jetty-yyyy_mm_dd.request.log # Apache mod_jk connector. Supported only in standalone mode. # Uncomment to activate AJP13 connector. #sonar.ajp13.port: 8009 #----------------------------------------------------------------------- # DATABASE # # IMPORTANT : the embedded database Derby is used by default. # It is recommended for tests only. Please use an external database # for production environment (MySQL, Oracle, Postgresql, SQLServer) # #----------------------------------------------------------------------- #----- Credentials # Permissions to create tables and indexes must be granted to JDBC user. # The schema must be created first. sonar.jdbc.username: sonar sonar.jdbc.password: sonar #----- Embedded database Derby # Note : it does accept connections from remote hosts, so the # sonar server and the maven plugin must be executed on the same host. # Comment the following lines to deactivate the default embedded database. #sonar.jdbc.url: jdbc:derby://localhost:1527/sonar;create=true #sonar.jdbc.driverClassName: org.apache.derby.jdbc.ClientDriver #sonar.jdbc.validationQuery: values(1) # directory containing Derby database files. By default it's the /data directory in the sonar installation. #sonar.embeddedDatabase.dataDir: # derby embedded database server listening port, defaults to 1527 #sonar.derby.drda.portNumber: 1527 # uncomment to accept connections from remote hosts. Ba default it only accepts localhost connections. #sonar.derby.drda.host: 0.0.0.0 #----- MySQL 5.x/6.x # Comment the embedded database and uncomment the following properties to use MySQL. The validation query is optional. #sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8 #sonar.jdbc.driverClassName: com.mysql.jdbc.Driver #sonar.jdbc.validationQuery: select 1 sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8 sonar.jdbc.driverClassName: com.mysql.jdbc.Driver sonar.jdbc.validationQuery: select 1 #----- Oracle 10g/11g # To connect to Oracle database : # # - It's recommended to use the latest version of the JDBC driver (either ojdbc6.jar for Java 6 or ojdbc5.jar for Java 5). # Download it in http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html # - Copy the driver to the directory extensions/jdbc-driver/oracle/ # - Comment the embedded database and uncomment the following properties. The validation query is optional. # #sonar.jdbc.url: jdbc:oracle:thin:@localhost/XE #sonar.jdbc.driverClassName: oracle.jdbc.driver.OracleDriver #sonar.jdbc.validationQuery: select 1 from dual # Uncomment the following property if multiple Sonar schemas are installed on the same server # (for example with different versions). # In that case, use the same property during project analysis (-Dsonar.hibernate.default_schema=<schema>) #sonar.hibernate.default_schema: sonar #----- PostgreSQL 8.x, 9.x # Uncomment the following properties to use PostgreSQL. The validation query is optional. #sonar.jdbc.url: jdbc:postgresql://localhost/sonar #sonar.jdbc.driverClassName: org.postgresql.Driver #sonar.jdbc.validationQuery: select 1 # If the PostgreSql database contains several schemas, the following property must define the schema to be used #sonar.jdbc.postgreSearchPath: public #----- Microsoft SQLServer # The Jtds open source driver is available in extensions/jdbc-driver/mssql. More details on http://jtds.sourceforge.net # The validation query is optional. #sonar.jdbc.url: jdbc:jtds:sqlserver://localhost;databaseName=SONAR;SelectMethod=Cursor #sonar.jdbc.driverClassName: net.sourceforge.jtds.jdbc.Driver #sonar.jdbc.validationQuery: select 1 #----- Connection pool settings sonar.jdbc.maxActive: 25 sonar.jdbc.maxIdle: 5 sonar.jdbc.minIdle: 2 sonar.jdbc.maxWait: 5000 sonar.jdbc.minEvictableIdleTimeMillis: 600000 sonar.jdbc.timeBetweenEvictionRunsMillis: 30000 #--------------------------------------------------------- # UPDATE CENTER #--------------------------------------------------------- # The Update Center requires an internet connection to request http://update.sonarsource.org # It is activated by default: #sonar.updatecenter.activate=true # HTTP proxy (default none) #http.proxyHost= #http.proxyPort= # NT domain name if NTLM proxy is used #http.auth.ntlm.domain= # SOCKS proxy (default none) #socksProxyHost= #socksProxyPort= # proxy authentication. The 2 following properties are used for HTTP and SOCKS proxies. #http.proxyUser= #http.proxyPassword= #--------------------------------------------------------- # NOTIFICATIONS #--------------------------------------------------------- # Delay (in seconds) between processing of notification queue sonar.notifications.delay=60



sonar-project.properties:

# required metadata sonar.projectKey=my2:project sonar.projectName=AQM_LIB sonar.projectVersion=1.0   # path to source directories (required) #sources=D:\\Projects\\Cloud-Migration-POC\\Cust-Supp-Artf\\AQMLatest_SourceCode\\AQM_LIB_5.0 sources=D:\\WorkSpace\\GWTProj\\cloud_migration\\aqm_lib\\src\\java #D:\WorkSpace\GWTProj\cloud_migration\aqm_lib   # path to test source directories (optional) #tests=testDir1,testDir2   # path to project binaries (optional), for example directory of Java bytecode #binaries=binDir   # optional comma-separated list of paths to libraries. Only path to JAR file and path to directory of classes are supported. #libraries=path/to/library.jar,path/to/classes/dir     # Uncomment those lines if some features of java 5 or java 6 like annotations, enum, ...  # are used in the source code to be analysed sonar.java.source=1.5 sonar.java.target=1.5     # Uncomment this line to analyse a project which is not a java project.  # The value of the property must be the key of the language. #sonar.language=cobol   # Advanced parameters my.property=value

1.Run Sonar And
2.Then run the sonar-runner-1.3\bin\sonar-runner.bat  from console.
3.type http://localhost:9000 in browser
and click on configuration....


D:\SANA_S\Soft\sonar-runner-1.3\conf\sonar-runner.properties file:

#----- Default Sonar server #sonar.host.url=http://localhost:9000 #----- PostgreSQL #sonar.jdbc.url=jdbc:postgresql://localhost/sonar #sonar.jdbc.driver=org.postgresql.Driver #----- MySQL sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&amp;characterEncoding=utf8 sonar.jdbc.driver=com.mysql.jdbc.Driver #----- Oracle #sonar.jdbc.url=jdbc:oracle:thin:@localhost/XE #sonar.jdbc.driver=oracle.jdbc.driver.OracleDriver #----- Global database settings #sonar.jdbc.username=sonar #sonar.jdbc.password=sonar #----- Default directory layout #sources=src/main/java #tests=src/test/java #binaries=target/classes sonar.sourceEncoding=UTF-8


Related Sites:

BY

SANA


Sonar (Software Quality)


What is Sonar ?

Sonar is an open source Platform used by development teams to manage source code quality. Sonar has been developed with a main objective in mind: make code quality management accessible to everyone with minimal effort.
As such, Sonar provides code analyzers, reporting tools, defects hunting modules and TimeMachine as core functionality. But it also embarks a plugin mechanism enabling the community to extend the functionality (more than 35 plugins available), making Sonar the one-stop-shop for source code quality by addressing not only developers but also managers needs.
In terms of languages, Sonar support analysis of Java in the core, but also of Flex (ActionScript 3), PHP, PL/SQL and Cobol through plugins (Open Source or commercial) as the reporting engine is language agnostic.
Since version 2.0, Sonar enables to cover quality on 7 axes and so to report on:
  • Duplicated code
  • Coding standards
  • Unit tests
  • Complex code
  • Potential bugs
  • Comments
  • Design and architecture
Sonar can be used for one-off audits, but has been designed to support global continuous improvement strategy on code quality in a company and therefore can be used as a shared central repository for quality management.
Product Version: Sonar 2.0
Licence: LGPL V3
Why should you manage source code quality?
A well-written program is a program where the cost of implementing a feature is constant throughout the program's lifetime -- Itay Maman
As a quick intro, this is the best definition of source code quality I could find. It gets even stronger when put the other way around: a badly written program is a program where the cost of implementing a feature grows throughout time.
That sounds bad, doesn't it?
We have all seen situations where a new project starts whose objective is to develop from scratch an application in a leading-edge technology. Everything goes very fast; first, second, third release and then all of a sudden, the team's velocity starts to decrease. Fourth release is postponed for the third time, fixing something breaks something else…
What is happening here? Given the symptoms, we can make an assumption that the team is suffering from technical debt amongst other things and that stakeholders are not aware of it and can therefore not deal with it.
But this will most probably get resolved as the project is new, has visibility and therefore somebody is going to take care of it (at least we can hope so).
But this example was only a starter, as we, IT people, do not work most of our time on applications whose development started less than 6 months ago! Our job is mainly made of upgrades to existing applications. That is where most of the money is spent in IT, where there is less visibility, where often there is a big yearly envelop to do as much as we can, where there are people who are key because they are the only ones able to understand the code, where we have no idea how long a change is going to take, where regressions are frequent and people are scared to make changes. And there is basically no attention whatsoever from the business on that, just do it!
Managing source code quality is all about optimizing ROI as it is going to give you visibility and therefore more control on:
  1. how hard maintenance is going to be, what can we expect
  2. the fact that things are not getting worse
  3. the fact that some attention should be given to critical part of the system, to increase for example coverage by unit tests, suppress cycles, remove duplications
Further more it gives a backup for developers to raise their hand when they believe some refactoring is required that would add a bit to a change but would have good ROI.
How to manage source code quality?
There are seven technical axes that should be looked at when doing source code analysis of a project and Sonar is able to support the management of all seven. In the Sonar team, we like to call them the 7 deadly sins of the developer:
  • non respect of coding standards and best practices
  • lacking comments in the source code, especially in public APIs
  • having duplicated lines of code
  • having complex component or/and a bad distribution of complexity amongst components
  • having no or low code coverage by unit tests, especially in complex part of the program
  • leaving potential bugs
  • having a spaghetti design (package cycles…)
The first step when doing source code quality management is really to define which of those axes are important to you and to what extend. Then based on the current situation, a plan should be established to reach the target level (that might be simply to keep a high level of quality). Very important is to start small and go bigger when it gets fully adopted by the whole development team.
Now, let's have a look at how to use Sonar in this approach.
Quality profiles
Sonar enables to manage multiple quality profiles in order to adapt the required level to the type of project (only support, new project, critical application, technical lib…). Managing a profile consists of:
activate / deactivate / weight coding rules
define thresholds on metrics for automatic alerting
define project / profile association
Dashboards
Sonar contains 2 dashboards that give the big picture to get hints where there might be issues and to compare projects:
  1. a consolidated view that shows all projects
  2. a project dashboard is also available at modules and packages level
Hunting Tools
To confirm that what seems to be an issue is really an issue, Sonar offers a hunting toolset that enables to go from overview to smallest details:
  • drill down on every measure displayed to see what is behind
  • classes clouds to find less covered classes by unit tests
  • hotspots to have on a page the most and the least files
  • and a multi-entry (duplication, coverage, violations, tests success…) source viewer to confirm the findings made with the hunting tools
TimeMachine
No doubt that knowing where an application stands is very important. But even more important is to know and understand its evolution. Indeed, what is it worth to know that there is 20% of code coverage by unit tests? Is it good or bad? Is the answer different if two months ago it was 15% or 25%? TimeMachine enables to watch the evolution and replay the past, especially as it records versions of the project
How does Sonar work?
Sonar is made of a fairly simple and flexible architecture that consists of three components:
  • A set of source code analyzers that are grouped in a Maven plugin and are triggered on demand. The analyzers use configuration stored in the database. Although Sonar relies on Maven to run analysis, it is capable to analyze Maven and non-Maven projects.
  • A database to not only persist the results of the analysis, the projects and global configuration but also to keep historical analysis for TimeMachine. 5 database engines are currently supported : Oracle, MySQL, Derby (demo only), PostgreSQL and MS SQLServer
  • A web reporting tool to display code quality dashboards on projects, hunt for defects, check TimeMachine and to configure analysis.
As part of its analyzers, Sonar core embarks best of breed tools to find coding rules violations (PMD, Checkstyle), detect potential bugs (Findbugs) and measure coverage by unit tests (Cobertura, Clover). But what makes Sonar truly unique is Squid, its own code analyzer that not only parses source code but also byte code and mixes the results.
Since analysis is run through a Maven plugin, Sonar can be launched easily in "Continuous Integration" environments.
Use case on Apache commons-collection project
A pre-requisite to run Sonar is to have Java and Maven installed on the box. Once this is the case, you can run Sonar in 5 simple steps:
1. Download the distribution from http://sonar.codehaus.org/downloads/ and unzip it
2. Open a console and start the server:
> $SONAR_HOME\bin\windows-x86-32\StartSonar.bat on windows
> $SONAR_HOME/bin/[OS]/sonar.sh on other platforms
3. Open a console where you want to checkout the source and run:
4. Run mvn install sonar:sonar in the same directory
The home page of the application shows the list of projects under quality control with a few configurable metrics.
To zoom in, you can simply click on the project and get its dashboard
From there you have access to a series of hunting tools amongst which:
The hotspot to find out about the files that have "the most" or "the least" …
But also, any metric in the dashboard is clickable to jump to behind the scene and get a view of the metric by underlying component
Each hunting tool eventually brings the hunter to the source code where the preys are highlighted

The Sonar Ecosystem

There is a very dynamic ecosystem around Sonar
  • An active community made of 300+ people on the user mailing list and 150+ people on the development mailing list
  • 35+ plugins on the forge (http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/) that are divided into four categories
  • Integration with external tools such as Jira, Hudson, Bamboo, GateIn, AnthillPro, Crowd
  • Direct extension of core functionality by adding new behavior, calculate advanced metrics or consolidate projects, add new metrics
  • Add coverage of languages such as PL/SQL, ActionScript3
  • Integration with IDEs to get defects information on the code when it is edited
  • 3,000+ downloads per month
  • A core development team led by SonarSource (http://www.sonarsource.com)

Conclusion

After the massive adoption of continuous integration engines and Tests Driven Development practices, managing source quality looks like the natural next step for development teams in their effort of industrialization. Sonar enables to reach this objective with few efforts and with fun.
In 2010, the Sonar platform is going to continue to evolve, the main axes of development being covering new languages and improving integration with IDEs.