Status and future plans
Brought to you by:
vlad_r
Menu
▾
▴
I am still new to some SourceForge features and it will take time to learn to use them effectively. I noticed that by default SourceForge creates 3 public forums and one or two mailing lists for every project. I've browsed a few existing projects and noticed that they soon get overwhelmed by user requests that can come through so many different channels (there's also the tracker and other facilities) and eventually some forums get discontinued. My plan is to start small and grow as needed.
At the moment this project has been limited to a single forum for general usage and other discussions (anonymous posting allowed) and a single mailing list. I've set up the forum as the primary means for users to get EMMA support. As usage grows, we will switch to SF tracker to keep things organized.
Future EMMA feature enhancements being considered:
- design reports to be more pluggable
- develop a "diff" coverage report
- make the XML report more useful for integration
- research Java 1.5 metadata as a possible means for annotating methods and classes with user-customizable coverage directives (exclusion, etc)
- if there is user demand, develop a socket runtime control API to get coverage dumps without having to shut the JVM down
- prepare for .class format changes in Java 1.5
The immediate project maintenance plans are:
- EMMA needs users outside of Trilogy and Trilogy customers (so that features are driven by the dev community at large): some EMMA "marketing" is required. Post suggestions on various options here.
- a number of small enhancements are pending for the 2.0 branch; there are some small features (-Demma.properties JVM option, etc) that are doc'ed but not really fully implemented yet.
- the doc build is a bit of a complicated mess now, a mixture of ANT tasks, docbook XSLTs, and Perl commands. I need to move the doc build to CVS.
- the testsuite is now entirely whitebox and is also not in the CVS. This needs major reorganization.
Just a little hint for (maybe) making the doc build easier -> look into Maven. It excels in that area!
Regards,
Stig
Interesting. But can Maven generate PDF? DocBook is a decent single-source publishing solution, albeit with a steep learning curve...
Mave has a plugin for SimpleDocbook.
http://maven.apache.org/reference/plugins/docbook/index.html
Maven can format the whole site in PDF, too.
http://maven.apache.org/reference/plugins/docbook/index.html
/peter (pnb@scancoin.se)
Hi,
if you want more exposure (which I think would be great) I think the way to go is to make EMMA a plugin to Maven (besides using maven to build EMMA;). That would expose EMMA to all maven users and give a great deal of feedback and help, I think.
/peter
Got it. I am now getting convinced (thanks to user feedback) that Maven integration should be higher priority.
Hi Vladimir,
As of now we need to bring down the JVM to take the coverage reports. Can we expect a feature that enables the users to generate reports without bringing down the JVM in future releases?
Cheers,
Hari
Yes. As I have mentioned before, this has been on my own list of enhancements and was conditioned on getting some external user demand. You are like the second or third person asking for it, so this is now an official feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=977714&group_id=108932&atid=651900
This requires some work, so will probably get implemented in a future minor (2.x) release, not in a build update.
the plugin for maven is on his way... the tests looks good.
there are two plugin implementations
- one made by me and inspired of the jblanket plugin. ( pre-post goal for junit,...)
- the other made by Rafal Groszewski wich replace/wrap the test goal.
I'm also writing an installation guide and faq for my plugin in the hope of a release.
i'm currently taking contact with the author of the jblanket plugin and see the license terms (GNU GENERAL PUBLIC LICENSE normaly).
When it will be ok perhaps you could integrate the maven plugin in the emma site or in a stand alone project (perhaps license problem with CPL and GPL).
What do you think Vlad ?
Stphan Mestach
First of all, thanks for doing this. I am quite convinced that maven integration is an important feature request and so I think we should move the discussion to my tracker thread for it: http://sourceforge.net/tracker/index.php?func=detail&aid=961998&group_id=108932&atid=651900
Secondly, I need to understand whether a separate .jar distribution is necessary for maven support and how maven version matching works etc. If maven could be supported by, say, emma_maven.jar (that is in turn dependent on emma.jar) that would be analogous with how ANT is supported now (not sure if it has been a wise decision but I am trying to keep emma.jar size as small as possible and keep both command-line and ANT users happy). My plan is to avoid creating a separate SF project but either expand the current emma-xxx.zip and emma-xxx-lib.zip file offerings or add a new one to the current project.
Finally, I will be very leery of adding anything *GPL* to the codebase. I am not a GPL zealot and find CPL a much better license for both open-source and commercial worlds. I know for a fact that GPL and CPL are not compatible.
Hi Vladimir,
Is there any way to find out the number of times each and every line of code has been executed using eMMA after a number of tests?
Cheers,
Hari
No. I had a feature like that in EMMA's predecessor and noone ever really cared for that data.
I removed it because it would add profiling information to what is an otherwise pure code coverage tool and because counting execution times increases coverage overhead. Additionally, gathering profiling information induced by tests is not representative of the hot spots in a real product deployment anyway.