From various posts over the last month or two I got the impression that there is quite a bit of EMMA usage in traditional makefiles. I find it a little surprising (I thought by now the entire world has migrated to ANT).
On the other side of the spectrum, there has been keen demand for a Maven plugin, even though Maven is just going through its release candidate stages and the rumor has it that Maven has been pretty unstable so far.
For me, it's kind of an interesting observation. I am guessing there is usage both in the corporate world (where builds tend to be large and have a lot of legacy inertia in them) and individual/student/open source world (where using the latest and greatest build processor is an easy decision). If so, EMMA is on its way to achieve one of its goals :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-11
Hi Vlad,
Ya, I'm one of the Makefile users. Nothing against Ant, really, it's just that I haven't found a day to spend on learning ant and re-writing stuff. I'm increasingly feeling like an "old fogey," as Ant has certainly been stylish for quite some time now. I'll no doubt make the switch soon --- Just in time to remain old-fashioned, I guess, as Maven will then be the "next great thing," and my co-workers can continue to ridicule me.
Still, I certainly appreciate that you support command-line/Makefile usage.
Cheers,
--Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't mean to cast makefile usage in any bad light (you are definitely not the only user of EMMA command line tools). Command line rules! I personally find it super-convenient to come into a project I haven't worked on before, run a quick "java emma instr" just before the tests and see what's what.
ANT used to be touted as a build solution free from make's "tab problem". However, in all the years of using nmake and gnumake I don't think I'd experienced that problem more than twice. With ANT, I've had a ton of missing >'s or closing tags or whatever. And once you include an entity or two, most XML parsers get thrown off as far as mapping parsing errors to line numbers is concerned.
However, ANT improved things by providing a large collection of code snippets (tasks) that could do useful things in a predictable (and mostly platform-independent) manner.
But I guess ANT still imposes too little structure on things. Maven seems to be the next step towards removing flexibility and making things even more standard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
maven is used in our company for the build/release process of our projects.
the projects are :
- legacy java programs... only maintained
- or new applications :
developped, junit tested, code coveraged, documented,...
how do we use maven / what we like in maven :
- auto download of dependencies
- aggregated site, documentation portail
- reports on code convention, code metrics,...
- enable the supervisor to run junit and test that the app works... we don't trust developpers ;)
- test dependencies modification before impacting every developpers.
maven also generates build.xml compatible with the corresponding maven project ( download of dependencies,build, snapshot jar)
these build.xml files are used in wasd by our developpers.
if you want to see a great project using maven in extremely complete way : check http://muleumo.org/
this guy is really impressive... (subprojects, reports, documentation,...)
Stphan
note :
yes maven is only in RC... and there's some problems with great project, windows platform,... (command line too long for javadoc, problem with cvsnt,ibm jvm...)
Rem : the name of the solution : plugin's nightmare ;)
but once solved, it's really easy for every one to add reports like emma ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In hindsight, prioritizing a Maven plugin for EMMA over an Eclipse plugin has been a mistake. I am certainly not moving EMMA's own build to Maven any time soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To offer a different perspective - at my company we've got 50+ developers on 5 active development projects, 10 java applications in production (Jini, J2EE, and plain ol server side java) and and about all of it built using maven. Don't get me wrong - builds with Ant, IDEs, and makefiles haven't disappered, but the golden code is all built with maven. This ensure unit test execution, PMD quality metrics (we've developed our own rules), a single application dashboard of unit test coverage (temporarily using clover), pass rates, complexity scores, jdpend analysis, and an aggregation of multi-project documentation. (we had to augment that, but it took less than a couple of weeks by starting with maven ).
Yes, maven may not be the best artifact assembler, but all of the other capabilities we get by working through its kinks has been invaluable to improving the quality of our solutions. and the management of our projects.
I'm eagerly awaiting an emma maven plugin.
- Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We got things working.
We're modifying the plugin. It's not good to bytecode enrich everytime we compile. The only time we want bytecode enrichment is when we're executing our unit tests. Or, even better, only when generating a unit test coverage report.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you're right, instrumenting all the time is not a good strategy. The next point release of the plugin will support a mode where the original .class files are backed up, then restored after test:test.
In the meantime, you can avoid this issue by not having EMMA enabled in project.properties, and enabling it using emma:on instead.
Also note that emma:report does not require EMMA to be enabled in project.properties.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From various posts over the last month or two I got the impression that there is quite a bit of EMMA usage in traditional makefiles. I find it a little surprising (I thought by now the entire world has migrated to ANT).
On the other side of the spectrum, there has been keen demand for a Maven plugin, even though Maven is just going through its release candidate stages and the rumor has it that Maven has been pretty unstable so far.
For me, it's kind of an interesting observation. I am guessing there is usage both in the corporate world (where builds tend to be large and have a lot of legacy inertia in them) and individual/student/open source world (where using the latest and greatest build processor is an easy decision). If so, EMMA is on its way to achieve one of its goals :)
Hi Vlad,
Ya, I'm one of the Makefile users. Nothing against Ant, really, it's just that I haven't found a day to spend on learning ant and re-writing stuff. I'm increasingly feeling like an "old fogey," as Ant has certainly been stylish for quite some time now. I'll no doubt make the switch soon --- Just in time to remain old-fashioned, I guess, as Maven will then be the "next great thing," and my co-workers can continue to ridicule me.
Still, I certainly appreciate that you support command-line/Makefile usage.
Cheers,
--Bob
Bob,
I didn't mean to cast makefile usage in any bad light (you are definitely not the only user of EMMA command line tools). Command line rules! I personally find it super-convenient to come into a project I haven't worked on before, run a quick "java emma instr" just before the tests and see what's what.
ANT used to be touted as a build solution free from make's "tab problem". However, in all the years of using nmake and gnumake I don't think I'd experienced that problem more than twice. With ANT, I've had a ton of missing >'s or closing tags or whatever. And once you include an entity or two, most XML parsers get thrown off as far as mapping parsing errors to line numbers is concerned.
However, ANT improved things by providing a large collection of code snippets (tasks) that could do useful things in a predictable (and mostly platform-independent) manner.
But I guess ANT still imposes too little structure on things. Maven seems to be the next step towards removing flexibility and making things even more standard.
maven is used in our company for the build/release process of our projects.
the projects are :
- legacy java programs... only maintained
- or new applications :
developped, junit tested, code coveraged, documented,...
how do we use maven / what we like in maven :
- auto download of dependencies
- aggregated site, documentation portail
- reports on code convention, code metrics,...
- enable the supervisor to run junit and test that the app works... we don't trust developpers ;)
- test dependencies modification before impacting every developpers.
maven also generates build.xml compatible with the corresponding maven project ( download of dependencies,build, snapshot jar)
these build.xml files are used in wasd by our developpers.
if you want to see a great project using maven in extremely complete way : check http://muleumo.org/
this guy is really impressive... (subprojects, reports, documentation,...)
Stphan
note :
yes maven is only in RC... and there's some problems with great project, windows platform,... (command line too long for javadoc, problem with cvsnt,ibm jvm...)
Rem : the name of the solution : plugin's nightmare ;)
but once solved, it's really easy for every one to add reports like emma ;)
Here is an interesting critique of Maven by someone who's tried it and backed out: http://howardlewisship.com/blog/2004/05/moving-away-from-maven.html
In hindsight, prioritizing a Maven plugin for EMMA over an Eclipse plugin has been a mistake. I am certainly not moving EMMA's own build to Maven any time soon.
To offer a different perspective - at my company we've got 50+ developers on 5 active development projects, 10 java applications in production (Jini, J2EE, and plain ol server side java) and and about all of it built using maven. Don't get me wrong - builds with Ant, IDEs, and makefiles haven't disappered, but the golden code is all built with maven. This ensure unit test execution, PMD quality metrics (we've developed our own rules), a single application dashboard of unit test coverage (temporarily using clover), pass rates, complexity scores, jdpend analysis, and an aggregation of multi-project documentation. (we had to augment that, but it took less than a couple of weeks by starting with maven ).
Yes, maven may not be the best artifact assembler, but all of the other capabilities we get by working through its kinks has been invaluable to improving the quality of our solutions. and the management of our projects.
I'm eagerly awaiting an emma maven plugin.
- Dave
It's not perfect (yet), but the current version of the plugin has just been released.
The instructions for adding the plugin to a build are in the file release notes: http://sourceforge.net/project/shownotes.php?group_id=108932&release_id=271370
I am sure Dilum will appreciate any feedback you might have.
We got things working.
We're modifying the plugin. It's not good to bytecode enrich everytime we compile. The only time we want bytecode enrichment is when we're executing our unit tests. Or, even better, only when generating a unit test coverage report.
Hi David,
you're right, instrumenting all the time is not a good strategy. The next point release of the plugin will support a mode where the original .class files are backed up, then restored after test:test.
In the meantime, you can avoid this issue by not having EMMA enabled in project.properties, and enabling it using emma:on instead.
Also note that emma:report does not require EMMA to be enabled in project.properties.