Version 1.2.0 released. See Subversion
Thursday, May 26, 2005
Monday, May 23, 2005
BDT - Build Development Tools
Wednesday, May 18, 2005
Maven & multiple source trees
Have a look at an interesting article about Maven and multiple source trees in Michael Nielsen's Blog: http://weblogs.java.net/blog/michael_n/archive/2005/05/maven_multiple.html
Build Environment Systems
When ever you start a new project you'll find out, that you have to ship the software at a certain point :-) and to do that there are many tasks involved:
Beside this, if your delivery will be tested by some testing folks on the customer side, they'll flood your bug tracking system, because some bugs will look quite different every time. And you won't hire some new people just to sort out the same bugs, would you? ;-)
To address these needs, most Java projects are using Ant. Ant is a quasi standard for building Java applications. The Apache Ant project describes itself as: Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.
In Ant you can define targets and within the targets you have different tasks. The targets once more can have dependencies to other targets. If you are not familiar with Ant, have a look at "Writing a Simple Buildfile" tutorial from the Ant project. This will give you a good introduction.
If you start using Ant, you figure out, that you are doing the same things again and again. For example: your application is based on several components and you would like to compile each of them independently. You'll start writing a compile target for every component and at a certain point you'll try to refactor your build files so you can use one compile target for all your components.
I invested quite some time in my build files and started to use them in different projects. So I started to use my own build environment components. I'm not quite sure, if this is the right approache, since there are many projects out there which are doing the same thing... but usually much more sophisticated...
These projects are using Ant or extending it and building a set of predefined targets to use:
Another Apache project, addressing the need of a good build environment system is Maven. Maven itself is much more sophisticated than Ant and they use a different aproach. Maven is built around a project object model and is providing a huge set of goals (in Ant terms these would be targets). Beside this, Maven is able to deal with dependencies in your project.
Currently the Maven team is working on Version 2.0 of Maven. If you are interested in Maven 2.0 have a look at the project site: http://maven.apache.org/maven2/.
It's very much recommended, that you invest enough time in your build environment and that you maintain it as good as possible. You should keep in mind, that your build scripts are a part of your software and you should treat it with the same respect as your source code.
Some people might think, that a fully automated build environment is to expensive. But if you have a closer look at all the details and all the knowledge lying in your build environment and in your build process, you'll see that the positive aspects outweigh.
To understand the importance of a good build environment, you also should read the article of Martin Fowler about Continuous Integration.
- deliver the application as a zip file including a batch or shell script to execute it
- deliver the application with all the necessary deployment descriptors, security role assignments, etc., so the application can be deployed
- deliver an installer for one or many operating systems
- deliver it in any kind your customer would like to have it
- pack all the necessary libs for your application
- generate a working classpath (sometimes not that easy...)
- generate all the documentations
- generate the batch and shell scripts
- generate some testdata
- create the installer build files
- etc.
Beside this, if your delivery will be tested by some testing folks on the customer side, they'll flood your bug tracking system, because some bugs will look quite different every time. And you won't hire some new people just to sort out the same bugs, would you? ;-)
To address these needs, most Java projects are using Ant. Ant is a quasi standard for building Java applications. The Apache Ant project describes itself as: Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.
In Ant you can define targets and within the targets you have different tasks. The targets once more can have dependencies to other targets. If you are not familiar with Ant, have a look at "Writing a Simple Buildfile" tutorial from the Ant project. This will give you a good introduction.
If you start using Ant, you figure out, that you are doing the same things again and again. For example: your application is based on several components and you would like to compile each of them independently. You'll start writing a compile target for every component and at a certain point you'll try to refactor your build files so you can use one compile target for all your components.
I invested quite some time in my build files and started to use them in different projects. So I started to use my own build environment components. I'm not quite sure, if this is the right approache, since there are many projects out there which are doing the same thing... but usually much more sophisticated...
These projects are using Ant or extending it and building a set of predefined targets to use:
- http://antlion.sourceforge.net/
- http://antworks.sourceforge.net/
- http://invicta.sourceforge.net/
- http://www.javagen.com/jam/index.html
- http://www.jayasoft.fr/org/modules/ivy/overview.php?
Another Apache project, addressing the need of a good build environment system is Maven. Maven itself is much more sophisticated than Ant and they use a different aproach. Maven is built around a project object model and is providing a huge set of goals (in Ant terms these would be targets). Beside this, Maven is able to deal with dependencies in your project.
Currently the Maven team is working on Version 2.0 of Maven. If you are interested in Maven 2.0 have a look at the project site: http://maven.apache.org/maven2/.
It's very much recommended, that you invest enough time in your build environment and that you maintain it as good as possible. You should keep in mind, that your build scripts are a part of your software and you should treat it with the same respect as your source code.
Some people might think, that a fully automated build environment is to expensive. But if you have a closer look at all the details and all the knowledge lying in your build environment and in your build process, you'll see that the positive aspects outweigh.
To understand the importance of a good build environment, you also should read the article of Martin Fowler about Continuous Integration.
Monday, May 16, 2005
FindBugs 0.8.8 - Code Analyzer
The FindBugs Java code analysis tool project has released version 0.8.8 with many feature enhancements. Those include detection for duplicate code in if/else statements, new function calls, increased detection of impossible casts, statistics saving, and more.
PMD 3.1
Tom Copeland had announced the release of version 3.1 of his Java code analyzer PMD. "It includes eight new rules, a slew of bug fixes, and better support for JDK 1.5. Several rules were optimized, for example, UnusedModifer now runs about ten times faster." A full change log is available.
Apache Maven 2.0 Alpha 2
The Apache Maven development team has announced the release of version 2.0 Alpha 2 of the software project management tool. "This release is expected to be much more architecturally stable, making early adoption a possiblity. At this point, there are still only the core plugins available."
Eclipse 3.1 Milestone 7
The Eclipse IDE project has released its seventh milestone for version 3.1. "M7 is the final milestone build of the Eclipse Platform 3.1 development cycle, and marks the official start of the 3.1 endgame." M7 features undo and redo features for refactoring, and many UI tweaks.
Sunday, May 08, 2005
New Visual Tutorials - eclipse-tutorial.dev.java.net
I've added three new Visual Tutorials to eclipse-tutorial.dev.java.net and modified the help plugin.
- Create a new class with Fields and a Constructor
- Refactoring, Rename a Field and a Method
- How to use the Update Manager
Enjoy!
Saturday, May 07, 2005
Application Server Matrix
TheServerSide.com is providing an Application Server Matrix. Have a look at http://www.theserverside.com/reviews/matrix.tss
Friday, May 06, 2005
Update site available for eclipse-tutorial.dev.java.net
The update site for eclipse-tutorial.dev.java.net is now available on the project site:
- https://eclipse-tutorial.dev.java.net/update
Thursday, May 05, 2005
Static Code Analysis
If you would like to improve the quality of your code you can use a set of open source tools to achieve that. For Java there are many different tools, covering different aspects of static code analysis.
Please keep in mind, that automated static code analysis, never gives you a 100% answer about the quality of your code. From my point of view, it's more about getting some indications if your code has more or less options for improvements. Believe me, most of the time, there are more options for improvements then you would think of...
Code Conventions - CheckStyle
Let's start with the basic need of code conventions. If you start a new project you would like to have some conventions how the code has to be written. There are some Java code conventions provided by Sun, but you don't want to check them manually, do you?
To ensure, that your code is written according to your conventions, you can use CheckStyle. Run your checks with Ant or a command line tool.
It's highly recommended to use Ant or Maven to do the checks, since you would like to have a complete build cycle with different tools.
Code Reviews - Hammurapi, PMD
Usually there are some development guidelines, best practices or just how-to's while your working on a project, a framework or an application. These guidelines try to improve the quality of your software. But how do you check, if people follow these guidelines? Usually you do code reviews and try to find obvious mistakes. But unfortunately code reviews are very time consuming and expensive.
You can automatize certain aspects of the review process, by checking your code with tools like Hammurapi or PMD. Both tools provide rules which are organized in different groups, like: database connection pool, EJB, exception handling, and many more. Have a look at the project sites to get an overview of all the available rules.
If you have some special guidelines, which are important for your project, but not available in Hammurapi or PMD, you can write your own rules. Both tools are providing a simple interface to add new, project specific rules.
Common Bugs - FindBugs
There are many different type of bugs, you can write :-) and many times they follow a certain pattern. With FindBugs you can analyze your code and it'll check it according to a huge set of possible bugs, based on patterns.
Once again, there is no guarantee, you'll find all the bugs or it'll even point you to some code fragments which don't have a bug at all.
Testing - JUnit, TestNG
Testing is one of the most important aspects of quality. If you don't write test cases for your software, you don't know, what you are developing. Testing is a necessary precondition for refactoring. If you refactor your code, without test cases, you can't tell, if you changed something in the functionality or not.
A quasi standard testing tool is JUnit. It's a simple testing framework for unit testing. There is a huge set of tools, using JUnit as a core to test different aspcets, like HTTPUnit, Cactus or StrutsTestCase.
In the last few months an other testing framework got a lot of attention, it's called TestNG. Since JUnit has many limitations, there is a need for a more flexible testing framework.
Coverage - Corbertura, JCoverage, EMMA
While writing unit tests for your software, you would like to know, how much of your code is covered by your tests. There are quite many tools, which try to address this need. Have a look at Corbertura, JCoverage or EMMA for a start.
Many times the coverage tools are used for analyzing the test coverage of your software. An other nice aspect would be, to analyze the code which has been used during the execution of your application. These could show you, which code has been "touched" during the exectution and if you have to do some bug fixing, you would see, if a certain class is used quite often or seldom.
Test Quality - Jester
To find out, how robust your test classes and methods are, you can use Jester to test your test code.
Build Environment - Ant, Maven
As mentioned above, you should atomize your build environment. I think, the quasi standard to do this is Ant. Another very nice tool, is Maven. Both are providing the possibility to atomize a complex set of task.
Contiunous Integration - CruiseControl
Finally, you would like to analyze your code as often as possible. Now we are talking about continuous integration. Please take the time and read the article of Martin Fowler about continuous integration, I belive it's a must for every developer!
A great tool, to set up an continuous integration environment is CruiseControl. There are some other tools, but I won't mention them here.
Please keep in mind, that automated static code analysis, never gives you a 100% answer about the quality of your code. From my point of view, it's more about getting some indications if your code has more or less options for improvements. Believe me, most of the time, there are more options for improvements then you would think of...
Code Conventions - CheckStyle
Let's start with the basic need of code conventions. If you start a new project you would like to have some conventions how the code has to be written. There are some Java code conventions provided by Sun, but you don't want to check them manually, do you?
To ensure, that your code is written according to your conventions, you can use CheckStyle. Run your checks with Ant or a command line tool.
It's highly recommended to use Ant or Maven to do the checks, since you would like to have a complete build cycle with different tools.
Code Reviews - Hammurapi, PMD
Usually there are some development guidelines, best practices or just how-to's while your working on a project, a framework or an application. These guidelines try to improve the quality of your software. But how do you check, if people follow these guidelines? Usually you do code reviews and try to find obvious mistakes. But unfortunately code reviews are very time consuming and expensive.
You can automatize certain aspects of the review process, by checking your code with tools like Hammurapi or PMD. Both tools provide rules which are organized in different groups, like: database connection pool, EJB, exception handling, and many more. Have a look at the project sites to get an overview of all the available rules.
If you have some special guidelines, which are important for your project, but not available in Hammurapi or PMD, you can write your own rules. Both tools are providing a simple interface to add new, project specific rules.
Common Bugs - FindBugs
There are many different type of bugs, you can write :-) and many times they follow a certain pattern. With FindBugs you can analyze your code and it'll check it according to a huge set of possible bugs, based on patterns.
Once again, there is no guarantee, you'll find all the bugs or it'll even point you to some code fragments which don't have a bug at all.
Testing - JUnit, TestNG
Testing is one of the most important aspects of quality. If you don't write test cases for your software, you don't know, what you are developing. Testing is a necessary precondition for refactoring. If you refactor your code, without test cases, you can't tell, if you changed something in the functionality or not.
A quasi standard testing tool is JUnit. It's a simple testing framework for unit testing. There is a huge set of tools, using JUnit as a core to test different aspcets, like HTTPUnit, Cactus or StrutsTestCase.
In the last few months an other testing framework got a lot of attention, it's called TestNG. Since JUnit has many limitations, there is a need for a more flexible testing framework.
Coverage - Corbertura, JCoverage, EMMA
While writing unit tests for your software, you would like to know, how much of your code is covered by your tests. There are quite many tools, which try to address this need. Have a look at Corbertura, JCoverage or EMMA for a start.
Many times the coverage tools are used for analyzing the test coverage of your software. An other nice aspect would be, to analyze the code which has been used during the execution of your application. These could show you, which code has been "touched" during the exectution and if you have to do some bug fixing, you would see, if a certain class is used quite often or seldom.
Test Quality - Jester
To find out, how robust your test classes and methods are, you can use Jester to test your test code.
Build Environment - Ant, Maven
As mentioned above, you should atomize your build environment. I think, the quasi standard to do this is Ant. Another very nice tool, is Maven. Both are providing the possibility to atomize a complex set of task.
Contiunous Integration - CruiseControl
Finally, you would like to analyze your code as often as possible. Now we are talking about continuous integration. Please take the time and read the article of Martin Fowler about continuous integration, I belive it's a must for every developer!
A great tool, to set up an continuous integration environment is CruiseControl. There are some other tools, but I won't mention them here.
Subscribe to:
Posts (Atom)