Hello fellow developers. Vlad has asked me to lead the design and implementation of a Maven/EMMA plugin to me. I wanted to open my design goals for comments, and invite thoughts comments on feature selection.
The driving goals for this plugin are:
G1. Ease of use out of the box and a smooth learning curve: a new user should be able to get a coverage report by simply adding a <report .../> snippet.
G2. Flexibility to choose when to use the tool
G3. Absolute customizability: anything that EMMA allows you to do should be exposed by the plugin
G4. Support but not enforce process. For example, have the ability to fail a build if coverage is below minimum requirements
G5. Design to fit into various Maven use cases. People use Maven to perform some sophisticated builds - WARs, EARs etc. Such user groups should not have to figure out how to apply EMMA individually. Instead, we should document and encapsulate the logic.
I will open a parallel thread for discussing specific features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
G1 easy game... perhaps need emma uploaded on ibiblio to be really ease of use.
G5 seems to be the harder part...
for example, ear testing requires deployement on ejb container. So :
- emma must be for example in the classpath of the appserver.
- we cannot use a replacement of the test:test goal : ear:ear is after test:test... but we need ear to deploy and run the test. perhaps you should take a look at cactus (how to integrate the emma plugin with container).
G6 : great documentation with a sample project(s) will helps for "publicity" and smooth learning curve. (see xdoc and pdf plugin)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Absolutely. The first thing we're building are a set of representative sample projects. One will be really simple to show it working. The rest will exhibit EMMA being used in various typical (and important) scenarios. This is one of the key aspects of hitting G5.
Thank you for your involvement. If I may impose upon you further, though:
What kinds of projects do you/are you planning to use EMMA + Maven? How do you want to run your coverage tests and get the reports? Do you furnish project managers or administrative personnel with summaries of these reports?
I think the key thing about Maven is that it tries to address most of the aspects of performing a build and maintaining a project website. So I am interested in the stakeholder's of EMMA's reports within this context.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the project use :
- hibernate
xdoclet, ejb(websphere),db2(as400), swt client
the code and junits are designed to
- enforce the use of Interface
- be run outside a container (with a transactional aspect like Spring (java.lang.proxy))
- the junit only covers the server-side.
Dashboard seems to be a useful addition to Mavens reporting. We can incorporate it into the maven-emma plugin development roadmap. The documentation on authoring aggregators (http://maven.apache.org/reference/plugins/dashboard/authoring.html) gives us a good start; we can parse values out of the XML report Emma generates.
One stumbling block for this is if we usually want HTML reports the aggregators parsing would become much harder/uglier against the HTML report. The obvious solution to this is for the plugin to generate both HTML and XML reports.
This leads to a major annoyance Ive run across with developing the plugin Ive not found an elegant way to write reusable goals. Ive seen code that goes and modifies the POMs plugins properties directly, but nothing as clean as approaches like Ant 1.6s PreSetDef (http://ant.apache.org/manual/CoreTasks/presetdef.html).
Development on the plugin continues slowly. The current implementation simply substitutes the compiled classes in target/classes with instrumented classes. So if Emma is enabled, coverage statistics are generated when the test:test goal is run. If the plugin is listed in the reports, it forces an instrumented run. Currently, Im working on adding to the various instrumentation strategies.
Ive not made the plugin publicly available yet because of quality and completeness. Im of the opinion that Emma enjoys the following it has because of its original releases polish. Although Vlad outshines pretty much everyone I know on this front, I want to build the plugin upto a comparable standard before giving it exposure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just downloaded the plugin and it looks and works great. The only missing thing is a maven exposed property(ies) to define filter includes/excludes. I had written my own plugin several months ago, but yours is better except for this.
Thanks,
Chad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello fellow developers. Vlad has asked me to lead the design and implementation of a Maven/EMMA plugin to me. I wanted to open my design goals for comments, and invite thoughts comments on feature selection.
The driving goals for this plugin are:
G1. Ease of use out of the box and a smooth learning curve: a new user should be able to get a coverage report by simply adding a <report .../> snippet.
G2. Flexibility to choose when to use the tool
G3. Absolute customizability: anything that EMMA allows you to do should be exposed by the plugin
G4. Support but not enforce process. For example, have the ability to fail a build if coverage is below minimum requirements
G5. Design to fit into various Maven use cases. People use Maven to perform some sophisticated builds - WARs, EARs etc. Such user groups should not have to figure out how to apply EMMA individually. Instead, we should document and encapsulate the logic.
I will open a parallel thread for discussing specific features.
G1 easy game... perhaps need emma uploaded on ibiblio to be really ease of use.
G5 seems to be the harder part...
for example, ear testing requires deployement on ejb container. So :
- emma must be for example in the classpath of the appserver.
- we cannot use a replacement of the test:test goal : ear:ear is after test:test... but we need ear to deploy and run the test. perhaps you should take a look at cactus (how to integrate the emma plugin with container).
G6 : great documentation with a sample project(s) will helps for "publicity" and smooth learning curve. (see xdoc and pdf plugin)
Absolutely. The first thing we're building are a set of representative sample projects. One will be really simple to show it working. The rest will exhibit EMMA being used in various typical (and important) scenarios. This is one of the key aspects of hitting G5.
Thank you for your involvement. If I may impose upon you further, though:
What kinds of projects do you/are you planning to use EMMA + Maven? How do you want to run your coverage tests and get the reports? Do you furnish project managers or administrative personnel with summaries of these reports?
I think the key thing about Maven is that it tries to address most of the aspects of performing a build and maintaining a project website. So I am interested in the stakeholder's of EMMA's reports within this context.
i don't know... if you know but Maven 1.0 is Released !
the project use :
- hibernate
xdoclet, ejb(websphere),db2(as400), swt client
the code and junits are designed to
- enforce the use of Interface
- be run outside a container (with a transactional aspect like Spring (java.lang.proxy))
- the junit only covers the server-side.
to avoid the ejb container but to be able to test some specific "ejb" features.
we use mockrunner and mock ejb ( http://mockrunner.sourceforge.net/ http://mockejb.sourceforge.net/ )
what's the status of the developpement ?
Perhaps emma maven plugin can be "compatible" with an interesting plugin : dashboard.
http://maven.apache.org/reference/plugins/dashboard/
This plugin can consolidate different metrics in a single page : for multiple plugin and multiple project.
a sample report is here : http://oness.sourceforge.net/dashboard-report.html
it supports pmd, checkstyle, simian, clover,...
perhaps we can try to create a custom aggregator : http://maven.apache.org/reference/plugins/dashboard/authoring.html
Stphan
Dashboard seems to be a useful addition to Mavens reporting. We can incorporate it into the maven-emma plugin development roadmap. The documentation on authoring aggregators (http://maven.apache.org/reference/plugins/dashboard/authoring.html) gives us a good start; we can parse values out of the XML report Emma generates.
One stumbling block for this is if we usually want HTML reports the aggregators parsing would become much harder/uglier against the HTML report. The obvious solution to this is for the plugin to generate both HTML and XML reports.
This leads to a major annoyance Ive run across with developing the plugin Ive not found an elegant way to write reusable goals. Ive seen code that goes and modifies the POMs plugins properties directly, but nothing as clean as approaches like Ant 1.6s PreSetDef (http://ant.apache.org/manual/CoreTasks/presetdef.html).
Development on the plugin continues slowly. The current implementation simply substitutes the compiled classes in target/classes with instrumented classes. So if Emma is enabled, coverage statistics are generated when the test:test goal is run. If the plugin is listed in the reports, it forces an instrumented run. Currently, Im working on adding to the various instrumentation strategies.
Ive not made the plugin publicly available yet because of quality and completeness. Im of the opinion that Emma enjoys the following it has because of its original releases polish. Although Vlad outshines pretty much everyone I know on this front, I want to build the plugin upto a comparable standard before giving it exposure.
I just downloaded the plugin and it looks and works great. The only missing thing is a maven exposed property(ies) to define filter includes/excludes. I had written my own plugin several months ago, but yours is better except for this.
Thanks,
Chad