Mailing-List: contact m2-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven 2 Developers List" <m2-dev@maven.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41DD0BE8.3010609@apache.org>
Date: Thu, 06 Jan 2005 20:59:04 +1100
From: Brett Porter <brett@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Maven 2 Developers List <m2-dev@maven.apache.org>
Subject: #2 throughs on goal interfaces
Content-Type: multipart/mixed;
 boundary="------------080002070102060105060409"

This is a multi-part message in MIME format.
--------------080002070102060105060409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

This one covers goal interfaces (eg reports), and covers off the 
jcoverage use case.

I've also attached John's thoughts on the subject which I read after 
initially taking this down, and fit in a similar way.

- Brett

--------------080002070102060105060409
Content-Type: text/plain;
 name="goal-interfaces.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="goal-interfaces.txt"

GOAL INTERFACES
===============

We've talked about the need for goal interfaces in some form for reporting, and to cover the jcoverage usecase
where you substitute surefire:test with some other execution goal.

Test Duplication
----------------

Test shouldn't need to be treated specially like it currently is in pom.xml and
testResources/testCompile.

  compiler:compile -> compiler:doCompile(sourceDirectory,outputDirectory)
  test:compile -> compiler:doCompile(testSourceDirectory,testOuputDirectory)
  cactus:compile -> compiler:doCompile(cactusSourceDirectory,cactusOutputDirectory)
  modello:compile -> compiler:doCompile(generatedModelloSourceDirectory,outputDirectory)

Likewise for the resources.

The goals that other plugins depend on should be test:compile, test:resources and test:test, not surefire:*

Pluggable Implementations
-------------------------

Given test:test as the goal to be called, it must be possible to provide alternative implementations.
In fact, the default test:test goal shouldn't have an implementation.

To do this with metadata, we can introduce @abstract, @implements, @defaultImpl.

- test:test declares itself @abstract to ensure that it is not defined as the implementation.
- surefire:test declares @implements test:test as a valid implementation. Others might be junit:test, testng:test, etc.
- test:test can specify @defaultImpl surefire:test so there is a default.

Other requirements
- all metadata must match, and are inherited. This includes inputs and outputs, as well as prereqs and other metadata.
- additional metadata can also be provided, or inherited metadata overridden.
- can select the implementation from the POM. This is like the <roles/> discussed by John Casey. An alternative syntax could be:
  <unitTest>
    <implementation>surefire:test</implementation>
    ...
  </unitTest>
  - John's includes plugin name and version - goal name is all that should really be necessary though
  - John's would need a way to specify default implementations for roles
- the user can also set something globally - eg to set clover:report to always be the coverage report used.
- multiple implementations might be possible and run sequentially, as long as the input and output do not affect each other.
  The user and POM in specifying implementations need to be able to add, remove and override previous definitions.

Refer to the jcoverage example for more details.

Multiple languages
------------------

compile -> resources -> test -> jar
and a goal "build" that would run jar if the type was jar, or a different goal based on pom.type.

Instead, we could have:
compile -> resources -> test -> build
where each stage is implemented based on the type/language in use.

For compile, it is probably best that this is handled by the compiler component. compiler:compile should still work as usual
if the source language is c# by building to the output directory, resources are copied in the same way, and build would
build an assembly.

test would need to run nunit by default instead of surefire:test. There are two alternatives here:
- a test component could be implemented that can delegate to the implementation, selecting an appropriate default
  based on implementation
- goal implementations could be used, and several defaults provided, with a conditional on the POM. This makes assembling the
  DAG more complicated, so I prefer the previous option.


--------------080002070102060105060409
Content-Type: text/plain;
 name="jcoverage-usecase.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="jcoverage-usecase.txt"

USE CASE: JCOVERAGE
===================

PROBLEM STATEMENT
=================

Where a certain goal (or set of goals) need to be attained before another,
the user may want to specify them, but there may also need to be a default.
eg: jcoverage:report by default depends on surefire:test but the user may
choose to run cactus:test under jcoverage instead.

jcoverage:instrument should still be run first (as specified by jcoverage:report),
so the user can not just preGoal jcoverage:report (as then it will be
done before instrumentation). Additionally, the results of instrumentation need to be
passed on to the executed code before the report is generated.

Additionally, what is instrumented may also need to be augmented or replaced. eg
instrument compiled source by default, but maybe cactus compiled sources instead,
or as well as the main sources.

ie the default order should be:
  jcoverage:instrument -> outputDirectory
  surefire:test(projectClasses = outputDirectory)
  jcoverage:report
but can be
  jcoverage:instrument -> outputDirectory
  cactus:test(projectClasses = outputDirectory)
  jcoverage:report
How is this done? probably, jcoverage:report defines predecessors:
  jcoverage:instrument
  jcoverage:execute(instrumentedClasses)
  jcoverage:report

by default jcoverage:execute uses surefire:test, but may later be overridden
to use cactus:test.
 
One alternative that arises is whether should cactus be defining the jcoverage
integration in this instance instead?

HOW ADDRESSED
=============

hierarchy:
 report
   |
   v
 coverage:report (alias of coverage:coverage)
   |
   v
 coverage:execute 
   |
   v
 coverage:instrument 

coverage:report implementations:
 - jcoverage:report and/or
 - clover:report and/or
 - fleece:report (default)
(list as specified by POM, or overriden by user)

jcoverage:report has @prereq of jcoverage:instrument, which implements coverage:instrument, satisfying the 
coverage:instrument prereq
  - this seems unnecessarily complicated: see QUESTION below.

coverage:execute defaults to surefire:test (as specified by coverage:execute goal)
user specifies cactus:cactus as the implementation. cactus:cactus does not implement coverage:execute, so
  coverage:execute must specify that this is allowed (eg @signatureonly - match the signature only, not
  require direct implementation). Not sure if this is possible in a Java scenario - cactus:cactus may have to
  implement the CoverageExecute interface. The signature still needs to matched anyway to ensure the instrumented
  classes can be passed to cactus to use for execution

in POM:
<reports>
  <jcoverage xmlns="jcoverage">
    <execute>cactus:test</execute>
  </jcoverage>
</reports>

what about coverage info for tests instead of normal?
- this is a parameter to jcoverage to simply set the input and output differently for instrument

<reports>
  <jcoverage xmlns="jcoverage">
    <instrument>build</instrument>
    <instrument>test</instrument>
    <instrument>cactus</instrument>
    <execute>cactus:test</execute>
  </jcoverage>
</reports>

so jcoverage:instrument would take a list of stages to instrument (default to just build), and use
 input = #pom.build.sourceDirectory, output = #pom.build.outputDirectory/jcoverage-classes
 input = #pom.test.sourceDirectory, output = #pom.test.outputDirectory/jcoverage-classes
 input = #pom.cactus.sourceDirectory, output = #pom.cactus.outputDirectory/jcoverage-classes

QUESTION: at this point, I question whether we have the coverage:execute and coverage:instrument mojo's with
implementations, or does jcoverage:report look after it all internally?
  - At present, I don't believe we have a method for calling mojos, just prereq'ing them, required for execute
  - instrument could be integrated however into the "jcoverage" mojo
  - prereqs (or callouts) allow better hooks
  - For now, retain above definition
  - implementation of goals seems unnecessarily complicated (eg coverage:instrument, and especially arbitrary goals
    where signatures need to be matched)


--------------080002070102060105060409
Content-Type: message/rfc822;
 name="[RESEND] thoughts about testing, reporting,
 and other roles in the POM andmaven.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="[RESEND] thoughts about testing, reporting,
 and other roles in the POM andmaven.eml"

X-From_: jdcasey@codehaus.org  Fri Sep 10 02:18:53 2004
Received: from minotaur.apache.org (minotaur.apache.org [209.237.227.194])
	by mail.tpgi.com.au (8.12.10/8.12.10) with SMTP id i89GIpQN019347
	for <blporter@tpg.com.au>; Fri, 10 Sep 2004 02:18:52 +1000
Received: (qmail 39534 invoked by uid 1717); 9 Sep 2004 16:18:51 -0000
Delivered-To: brett@locus.apache.org
Received: (qmail 39527 invoked from network); 9 Sep 2004 16:18:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Sep 2004 16:18:51 -0000
Received: (qmail 29529 invoked by uid 500); 9 Sep 2004 16:18:51 -0000
Delivered-To: apmail-brett@apache.org
Received: (qmail 29526 invoked by uid 99); 9 Sep 2004 16:18:51 -0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from [63.208.196.171] (HELO outbound.mailhop.org) (63.208.196.171)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Sep 2004 09:18:49 -0700
Received: from [192.42.92.26] (helo=[192.168.2.103])
	by outbound.mailhop.org with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.20)
	id 1C5RdH-000IUp-6Z; Thu, 09 Sep 2004 12:18:47 -0400
Message-ID: <41408266.9070709@codehaus.org>
Date: Thu, 09 Sep 2004 12:18:46 -0400
From: John Casey <jdcasey@codehaus.org>
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brett Porter <brett@apache.org>, Jason van Zyl <jvanzyl@maven.org>,
        John Casey <jdcasey@codehaus.org>
Subject: [RESEND] thoughts about testing, reporting, and other roles in the
 POM and maven
Content-Type: multipart/mixed;
 boundary="------------020508050104090606050800"
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 192.42.92.26
X-Report-Abuse-To: abuse@dyndns.org (see
 http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: jdcasey
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
X-TPG-Antivirus: Passed
X-Status: 
X-Keywords: 
X-UID: 28

This is a multi-part message in MIME format.
--------------020508050104090606050800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Resending, because I incorrectly inlined the rafb.net stuff...

I'm going to patch the log of a conversation Jason and I had this
morning regarding how to address issues like the jcoverage use case
mentioned last night. I'll paste the contents from rafb.net/paste inline
instead of simply providing links. I thought it might be useful to send
this out for everyone to think on, before we meet again.

Cheers,
john

Log follows:

[09/09/2004 11:48 AM] [INFO] Channel view for ``#maven2'' opened.
[09/09/2004 11:48 AM] -->| YOU have joined #maven2
[09/09/2004 11:48 AM] <jason> howdy
[09/09/2004 11:48 AM] <jdcasey> hi
[09/09/2004 11:48 AM] <jdcasey> I have an idea for the jcoverage problem
we were discussing last night
[09/09/2004 11:50 AM] <jdcasey> h/o
[09/09/2004 11:53 AM] <jdcasey> what about bringing a little more of the
component-role style of control to the pom?
[09/09/2004 11:53 AM] <jason> don't know what you mean
[09/09/2004 11:54 AM] <jdcasey> well, I was thinking that what we really
want is to say "run the tests" and then produce a report on the result,
or whatever, right?
[09/09/2004 11:54 AM] <jdcasey> so the "run the tests" could be a matter
of doing a lookup() on all providers of the "test" role
[09/09/2004 11:55 AM] <jdcasey> in the super-model, you could provide
something like:
[09/09/2004 11:56 AM] <jason> so essentially registration like the
reports in m1?
[09/09/2004 11:57 AM] <jdcasey> http://rafb.net/paste/results/QFYbvO10.html

============================== From rafb.net/paste =====================
<project>
      .
      .
      .

      <roles>
          <role>
             <name>test</name>
             <providers>
                 <provider>
                     <plugin>surefire</plugin>
                     <version>1.0</version>
                     <goal>surefire:test</goal>
                 </provider>
             </providers>
          </role>
      </roles>
</project>
========================================================================

[09/09/2004 11:57 AM] <jdcasey> like that, but expanded for different
things other than reports
[09/09/2004 11:58 AM] -->| kschrader (~kschrad@69.55.236.120) has joined
#maven2
[09/09/2004 11:58 AM] <jdcasey> and there would be some sort of role
executor that standardized the calling semantics
[09/09/2004 11:58 AM] <jdcasey> that could expose some goal, and
jcoverage:report could depend on the exposed goal name
[09/09/2004 12:00 PM] <jason> right, i think some form of registration
is the way to go for things like that
[09/09/2004 12:00 PM] <jason> i agree
[09/09/2004 12:00 PM] <jason> on the mechanism i'm not sure but what you
have there looks like a good start to something extensible
[09/09/2004 12:00 PM] <jdcasey> override looks like:
[09/09/2004 12:00 PM] <jdcasey> http://rafb.net/paste/results/1ou1N421.html

============================== From rafb.net/paste =====================
<project>
      .
      .
      .

      <roles>
          <role>
             <name>test</name>
             <providers>
                 <provider>
                     <plugin>dbunit</plugin>
                     <version>1.0</version>
                     <goal>dbunit:test</goal>
                 </provider>
                 <provider>
                     <plugin>cactus</plugin>
                     <version>1.0</version>
                     <goal>cactus:test</goal>
                 </provider>
             </providers>
          </role>
      </roles>
</project>
========================================================================

[09/09/2004 12:00 PM] <jason> the reports could definitely use something
like that
[09/09/2004 12:01 PM] <jdcasey> having the role executor expose a
standard goal name would make prereqs easy for plugins
[09/09/2004 12:01 PM] <jdcasey> we could even export it all as a plugin
of sorts, in that the xxx: part would be maven: or some other reserved
namespace
[09/09/2004 12:01 PM] <jdcasey> maven:runTests or something
[09/09/2004 12:02 PM] <jdcasey> and we could mash together the
<role><name>test</name>...</role> into <test>...</test>
[09/09/2004 12:02 PM] <jason> how about we slate that this for the next
discussion after the lifecycle stuff?
[09/09/2004 12:03 PM] |<-- kschrader has left irc.codehaus.org (Ping
timeout)
[09/09/2004 12:03 PM] <jason> a universal registration for things like
compilation, testing and all that jazz would make changes in the future easy
[09/09/2004 12:03 PM] <jdcasey> alright. I'll save this conversation log
and email it out for food for thought, rather than put it in the APT
[09/09/2004 12:03 PM] <jdcasey> true
[09/09/2004 12:03 PM] <jason> the reports impl is not that good b/c of
jelly but the idea is sound
[09/09/2004 12:04 PM] <jason> forces a pattern and makes it easy to hook
into the pipeline
[09/09/2004 12:04 PM] <jason> definitely a good idea
[09/09/2004 12:04 PM] <jdcasey> the reports impl would definitely need a
rewrite
[09/09/2004 12:04 PM] <jdcasey> cool
[09/09/2004 12:04 PM] <jdcasey> lemme snag this conversation log and
email it out.
[09/09/2004 12:04 PM] <jason> yah, it would just use the new
registration stuff, what's in m1 can go in the garbage
[09/09/2004 12:04 PM] <jdcasey> absolutely


--------------020508050104090606050800
Content-Type: text/x-vcard; charset=utf-8;
 name="jdcasey.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="jdcasey.vcf"

begin:vcard
fn:John Casey
n:Casey;John
email;internet:jdcasey@commonjava.org
x-mozilla-html:FALSE
version:2.1
end:vcard


--------------020508050104090606050800--


--------------080002070102060105060409--