Vincent Massol wrote:
BTW, is there a Java API to programmatically call a goal/phase?
Not presently. I'm not sure we want to go down the attainGoal path
again, but there may be a case (eg, the release plugin currently
executes m2 outright - that's more like maven:maven than attainGoal
though). Given the current design, I think we can avoid it, and avoid
the complexity it might bring in having to establish a project yourself,
etc.
BTW, for the record, one other use case that I've met in real life and that
the current plugins in m1 do not support is the mix between AspectJ and
Clover.
If done in the right order, this should work. I'd need to understand the
case more though - maybe a separate mail is needed to discuss it.
So clover:check gets bound to a verification phase, executes
the new lifecycle, configured by an xml file to do the binding.
I don't understand the "configured by an xml file to do the binding" but I
guess that's the way to define a custom lifecycle. But do we need a new
lifecycle? Cannot we just rerun the existing one using the goal/phase
defined in the POM?
You can bind them yourself, and manage the output paths as long as you
know it won't have any side effects on the original build, but it also
means you'll need different goals for check during lifecycle
(non-forking) and check during report (forking) and standalone check
(forking). I'm apprehensive, because I'm not sure clover can anticipate
everything else participating in the lifecycle well enough (the case I
keep coming back to is a byte code enhancer being used), so better to
keep it entirely separate. I got from your original response that you
were ok doing this and we'd look for improvements in 2.1 based on
experiences from a more widely used 2.0.
Why not let the user decide as we've agreed above by letting him/her define
the goal/phase to run in the POM?
They can definitely do that, as long as they know it will probably end
up in the packaged output (which may be what they want). It is more work
though, having to specify all the goals needed.
Or are you suggesting that we don't bind
the CloverCheckMojo to a verification phase but rather to the test phase? If
so, I don't see the rationale. I still hold that the clover check is akin to
a functional test and should happen after the integration-tests phase.
Right, but in the end I agreed with you and stuck with that.
I think we still need an "activated" config element but for a different
reason: simply to tell the clover plugin if a check should be performed on
percentage coverage. Users may want to generate reports but not perform a
check. We could name the config element "activateCheck" rather than
"activate".
The check doesn't make sense in a report any more, they are separate
goals, so I don't think it is needed.
What we would really need is a full parallel target tree.
Yes, that's right, but how this may or may not work is not clicking in
my mind yet. I'd like to see working examples with what we have and use
that as a base.
Alternatively we could possibly make clover part of the profile. So you
would have a profile that builds the project with clover on, using the main
tree and another profile (for production) that builds the project without
clover. As the generated artifacts go in the local repository we should also
separate them according to profiles. For example if you build a jar with JDK
1.4 and with JDK 1.5 you should name them differently. Something like:
<artifactId>-<version>-<profilename>.<extension>.
It sounds to me it would be a better way rather than duplicating the source
and buildt trees.
In term of continuous build you would run the main profile often and then,
say every few builds, you would run the clover profile (or vice-versa). Of
course that means that people building your project would use the main
profile by default and would need to specify the extra flag on the command
line to run the clover/jcoverage/etc profile.
The advantage would be speed. The downside would be several build profiles
that are not executed together. But that's already true for different JDKs,
etc.
WDYT?
You've lost me a bit here, it seems a bit more solution that problem.
What are you trying to do? I don't get how clovered artifacts in the CI
repo help anyone on the receiving end...
Just for some background info, you can already do profiles per jdk and
modify the final name. You should be able to deploy them to the repo
with a different classifier (not in the code yet though).
Activation is by inclusion in the POM. I think execution of these goals
would either have no configuration in the POM, or at least no executions
listed (just using the plugin configuration to set what would be used
from the command line).
You're talking about the goal/phase config here, right?
Yep
You'll need to give me some pointers for how to do this "overlaid lifecycle
mapping". Again, is this required? Cannot we simply rerun the existing
lifecycle?
I think this is all explained now, let me know if not.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
