Re: History/trends in reports
[Sorry this post is a bit late, my email's had some trouble] Keeping a history of metrics is an excellent idea. We've been using a tool called Hackystat, in conjunction with Maven and our daily CruiseControl build, to gather and report on our metrics history. Hackystat has a few important differences from both MavenHistory and XRadar, which I'll try to list out to the best of my ability. You can get more info at their website. 1. Hackystat is tool-agnostic. It allows you to collect information from a variety of development tools. This includes Maven, Ant, Eclipse, JBuilder, Emacs, and the command-line. Some of these collection tools, or sensors, are fairly small and straight forward (e.g. Ant and Maven). You could likely add sensors to a new build tool without much effort. This is good if you want to keep your history reporting even if you change your build process. 2. Hackystat provides tools for developers and for projects. a. If you choose, you can send sensor information to a Hackystat server about some IDE activities -- JUnit tests run in the IDE, files changed, editor active time. As a developer, you can then choose whether to contribute your metrics to the project summary or not. The Hackystat tools can provide you with feedback and reports on your work across projects. b. A nightly build account can be setup to collect metrics about the project that don't relate to any individual. These include code size, tests run, test coverage % and other such static analysis metrics. The project tools can provide reports based on this information alone, or across all invited developers that choose to participate in sending their more fine-grained metrics. The developer always retains control of his/her metrics information, and can revoke that right from the project at any time -- privacy is an important consideration in this tool. 3. Hackystat is extensible. You can extend Hackystat in several ways. You can add new sensors for your tools to collect one of several existing types of generic metrics (like a Build event, Activity event, or UnitTest event). You can create new types of metrics (e.g. MyNewMetric event), and write a tool sensor to collect it (perhaps a Maven plugin.jelly reads an XML file that contains MyNewMetrics). And you can create new Analysis templates for the web application. There's also an easy way to customize and filter your views of many of the existing metrics -- you define your own charts using simple syntax like: JavaCoverage, (JavaCoverage-CoveredMethods, JavaCoverage-UncoveredMethods) . This will create one graphic with two charts. The first has to total coverage %, and the second shows two data lines, both the number of methods covered and the number of methods not covered by tests. 4. Hackystat is a server-based application. Sensors use SOAP to send data to the server. You can choose to drop the WAR file on your own internal JSP/Servlet server, or to use their public Hackystat server -- free for use by anyone. I'd suggest using the internal server in the long run. It's nice to use the public server for a short time to see how data is collected and reported. 5. Hackystat has an active set of 7 committers at the moment. Because some of them are paid, you're _extremely_ likely to see this project continue well into the future. It's a project that's been in the works since at least 2001 (perhaps before), and it's got a bright future. This is a metrics system you can build a long term solution on. The best place to find information is probably the developer site. http://hackydev.ics.hawaii.edu/ http://hackydev.ics.hawaii.edu/ When we began using Hackystat we were using Ant as our build system. We switched to Maven, and they didn't have any sensors for Maven so I recently wrote some. I'm in the process of contributing them to Hackystat -- I've spoken with them and they're excited to have the Maven addition and see some natural connections between Maven and Hackystat. I'll post instructions on how to install the Maven plugins and use them once the contribution is complete. Hopefully that provides a decent overview of Hackystat for anyone interested in using it to keep a metrics history. Thanks, Tim A lot later than promised and still not quite as neat as I wanted it to be: http://mavenhistorical.sourceforge.net Matt. -Original Message- From: Morris, Jason [IT] [mailto:[EMAIL PROTECTED] Sent: 19 July 2004 15:00 To: Maven Users List Subject: RE: History/trends in reports I'll second (or third!) this proposal - I'd love to be able to track quality metrics from reports such as Checkstyle, jdepend etc over time. They always come in handy during appraisal season :-) Jason -Original Message- From: Jerome Lacoste [mailto:[EMAIL PROTECTED] Sent: 19 July 2004 13:33 To: Maven Users List Subject: RE: History/trends in reports On Mon, 2004-07-19 at 11:52 +0100, Matt Read wrote: A colleague and I are actually working on a plugin right
Re: Snapshot Repository
We looked at the same problem, but decided on an entirely different solution. We don't have developers upload their snapshots to the central repository. We setup CruiseControl to run an hourly build of each project (if changes happened) on the same machine as the central Maven repository. The central build runs 'maven jar:install-snapshot' and then all developers use either the snapshot from their machine (if it's more recent), or the central snapshot. At most, developers wait an hour for a new snapshot. If we need it more quickly, we force a build through CC's web JMX interface, and the snapshot's available immediately. That way developers never upload to the central server, and when a release comes arouns then an admin can do that. --Tim On Mon, 12 Jul 2004 19:29:34 -0400, Paul Spencer [EMAIL PROTECTED] wrote: I can think of two solutions: 1) Have 2 repositories. One for snapshots and one for releases. A project's configuration files, (project.xml, project.properties, and build.properties) to write to the snapshot directory. The release process would involve changing the configuration to write to the release repository. maven.repo.remote = http://www.foo.com/snapshot, http://www.foo.com/release, http://www.ibiblio.org/maven 2) Make the release version readonly in the repository. This will prevent the file from being overwritten. Paul Spencer Amato Massimiliano (UBM) wrote: Hello, We are in the process of setting up a remote repository for our group and we have a problem, we want to allow developers to upload snapshot release to the central repository but we want not to allow them to upload final release. This is due to the fact that we have a central configuration for maven and it could happen that a developer could ovverride by mistake a release with a wrong one. Basically we would like to have 2 separate directories, one for the final release where only the administrator can write and another one public where all the developers can upload their snapshot. I don't think this is supported right now in Maven but i'd like to know if anyone had ever thought about it since i think it could be a common problem. Any idea if this will be implemented in the future releases? Also since we need to make it work any suggestion on how we could do it? We were thinking about rewriting the artifact plugin in order to change the directory if the version is a snapshot Thanks for your help Max Massimiliano Amato Risk Technologies UniCredit Banca Mobiliare - www.ubm.it Via Tommaso Grossi, 10 20121 Milano MI tel. +39 02 88628093 - fax +39 02 72929309 The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to and must not disclose, copy, distribute, or retain this message or any part of it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] JBlanket plugin 1.0.0503 release
The JBlanket team is pleased to announce the JBlanket plugin 1.0.0503 release! http://csdl.ics.hawaii.edu/Tools/JBlanket/maven-plugin/ JBlanket is a method coverage tool for Java programs. It modifies the byte code to measure coverage during the execution of JUnit test cases. Requiring a green bar when unit tests run is an easy policy to state and to measure. At the end of the day either all tests passed or not. Many have adopted that mantra. It's power is in its simplicity. Code coverage policy should be that simple. Achieving a 100% coverage rate using a statement level tool usually requires large amounts of effort. Instead of a simple coverage policy, what usually evolves is the general acceptance of a coverage rate that's high enough for us, or abandonment of coverage measures altogether. This easily leaves a wide net of functionality uncovered by automated tests. Intuitively, some code is worth more effort to test than others. JBlanket strikes a great balance. It leverages the simplicity of the green bar coverage policy by using simple heuristics to make the coverage measure meaningful and practical. First, only method coverage is measured. Second, you can choose to categorically ignore methods that aren't worth the effort of testing -- like one-line methods. This makes it easier to maintain 100% coverage, and keep up the culture of quality. Then, statement level tools can help check specific classes or problem areas. The plugin has been tested with Maven 1.0-rc3. It can be installed through Maven: maven plugin:download -DartifactId=maven-jblanket-plugin -DgroupId=jblanket -Dversion=1.0.0503 Check out the documentation for how to enable JBlanket for your project http://csdl.ics.hawaii.edu/Tools/JBlanket/maven-plugin/enable.html Enjoy! Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
