Re: atypical plugin use cases
On Feb 18, 2008 8:03 PM, Brett Porter [EMAIL PROTECTED] wrote: On 19/02/2008, at 3:15 AM, John Casey wrote: Things like: - running the tests twice by necessity Having being burned by this little foible... I often see people complain that the code coverage tools runs the unit tests twice. I often see people want to only run the tests once... We have had the following: * Unit tests that only pass on a multi-processor system when running with code coverage tools (due to synchronization problems. the code coverage's instrumented byte code by necessity has to synchronize updating method coverage, which forces the vm's to pick up some variable changes that it would not ordinarily see) * Unit tests that only fail when running with code coverage tools (one example is the tests we wrote after we found the synchronization logic error in our code) Then there is the fun of is the code coverage valid if the unit tests fail? I say that the coverage is valid if all the un-instrumented tests pass, but if the instrumented tests fail you need to examine the failures case by case. My rule of thumb is to _always_ run the tests twice, once with coverage and once without. The test failure during the second (instrumented) execution should not fail the build. - not being able to reuse the enhanced classes easily - lack of consistency between build time checks and reporting
Re: atypical plugin use cases
On 19/02/2008, at 9:50 PM, Stephen Connolly wrote: My rule of thumb is to _always_ run the tests twice, once with coverage and once without. The test failure during the second (instrumented) execution should not fail the build. Yes, this is the recommendation I always make too, to ensure purity in testing the code. Then ideally you would run them just once to generate code coverage reports, checks, etc on the instrumented code. Even this is more cumbersome to configure than it should be. But a lot of people only want to run them once anyway :) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: atypical plugin use cases
On Feb 17, 2008, at 3:48 PM, Brett Porter wrote: - decent integration of code coverage plugins (we never got this forked lifecycle quite right) Can you shed some more light on this? Do we have specific test cases that we can put into the build? I'll have to read over the rest of your post a little more carefully before I can form a coherent response, but I wanted to ask this before I forgot about it. ;-) Thanks, -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: atypical plugin use cases
On 19/02/2008, at 3:15 AM, John Casey wrote: On Feb 17, 2008, at 3:48 PM, Brett Porter wrote: - decent integration of code coverage plugins (we never got this forked lifecycle quite right) Can you shed some more light on this? Do we have specific test cases that we can put into the build? Vincent would probably happily give you a list from when he worked on the clover plugin :) Things like: - running the tests twice by necessity - not being able to reuse the enhanced classes easily - lack of consistency between build time checks and reporting It all kind of works, but I generally find configuring it is less pleasant than necessary and less flexible than it could be. I'll have to read over the rest of your post a little more carefully before I can form a coherent response, but I wanted to ask this before I forgot about it. ;-) Cool, thanks :) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: atypical plugin use cases
The Parent POM section reads a bit confusingly because it uses Ahead
both times, but you've switched the order of the POMs :)
I'm trying to understand what the real scenario is where there is a
child POM that doesn't declare it's parent? Could that just be
declared as a build failure/warning? I think modules really needs to
reflect the hierarchical relationship - and it's an easier problem to
attack than to change the order if that scenario is used.
With regards to the assembly - we probably need to look at some
alternative ways to attack that problem.
For me, the main things I think we should focus on with plugin
lifecycle are:
- assembly lifecycle (perhaps related to the aggregator changes you
propose)
- decent integration of code coverage plugins (we never got this
forked lifecycle quite right)
I'm not sure about the aggregator changes - I realise the problems you
describe, but will need to give it more thought - I think more digging
on the proposed solutions will be needed, referring to an example as I
had trouble visualising it from your description (I may just need more
coffee :).
Build introspection is a good thing, some thoughts:
- this would enable guarded mojo execution too
- I don't think legacy mojos is a big deal - you just miss some
information you never had - just need to make sure that things assume
the information is always partial (since plugin devs will be lazy
sometimes too) - as long as it still provides correct results (or
correct based on knowledge given) I think this is ok.
- I think annotations are a good idea, possibly with additional
interfaces so that you can code the conditional logic necessary if the
annotations don't suffice (so, a combo of the two proposals)
- I think an alternative way to look at this might be to structure
mojo execution such that you can essentially run it in dry run (so you
can run the whole build, just not affect anything). This would
unfortunately significantly affect mojo design, however - but worth
thinking about how it might help for the more complicated logic cases.
Given all this, I think the 3 proposals can actually be split up into
separate documents.
Thanks John!
Cheers,
Brett
On 14/02/2008, at 9:34 AM, John Casey wrote:
Hi,
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current setup.
I have proposals to address most of the issues, but I'd love to hear
what you would propose...or even tell me about plugin-design issues
that I haven't thought of.
I'd really like to take a whack at the bigger problems for 2.1, but
if that doesn't happen, 2.2 is a fine target for me, as long as we
start the discussion now. We have a lot of experience with what
works and what doesn't from 2.0.x, so let's take advantage of that
to see what we got wrong, and how we can correct it.
The page is here:
http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
Thanks in advance,
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: atypical plugin use cases
On Wed, Feb 13, 2008 at 11:52 PM, Dan Fabulich [EMAIL PROTECTED] wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic
plugin
use cases, things like aggregation and use of ${reactorProjects}, that
we're
running into under the current setup. I have proposals to address most
of the
issues, but I'd love to hear what you would propose...or even tell me
about
plugin-design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation would be
an atypical case. IMO, almost every reporting plugin needs to do
aggregation (or at least be able to do it). checkstyle, clover, docck,
javadoc, jxr, pmd, surefire-report all need aggregation somehow or other.
-Dan
However, IMHO they should implement the aggregation as a separate goal.
Re: atypical plugin use cases
That's not really the point. The point is that these behaviors
require exceptional logic to the main build process inside Maven.
They're a deviation of the normal once-per-project mojo, which is
geared to operate on the current project.
If you wanted to draw attention to something that doesn't fit the
'atypical' heading, I'd say that build introspection is a much better
target. Almost any sort of integration with Maven will need to be
able to extract this sort of information, and forcing a build to get
that information is a bad way to go.
If you really want to spend the time, and have a better title, feel
free to rename the document. I have no problems with that; I'm more
concerned with solving the problems I talk about in the document's
content.
-john
On Feb 13, 2008, at 6:52 PM, Dan Fabulich wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current
setup. I have proposals to address most of the issues, but I'd
love to hear what you would propose...or even tell me about plugin-
design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation
would be an atypical case. IMO, almost every reporting plugin
needs to do aggregation (or at least be able to do it).
checkstyle, clover, docck, javadoc, jxr, pmd, surefire-report all
need aggregation somehow or other.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: atypical plugin use cases
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic plugin
use cases, things like aggregation and use of ${reactorProjects}, that we're
running into under the current setup. I have proposals to address most of the
issues, but I'd love to hear what you would propose...or even tell me about
plugin-design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation would be
an atypical case. IMO, almost every reporting plugin needs to do
aggregation (or at least be able to do it). checkstyle, clover, docck,
javadoc, jxr, pmd, surefire-report all need aggregation somehow or other.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
