[email protected]
[Top] [All Lists]

Re: Test dependencies - another take

Subject: Re: Test dependencies - another take
From: Brett Porter
Date: Fri, 21 Jan 2005 21:05:26 +1100
There should be no problem with this. AFAICT this is identical to what I included in my last set of emails, though I concluded that there was no need for a "per-goal" dependency, and instead limited to a particular plugin as you have done.

This really is quite trivial as you say - it will just fall into place with whatever we do regarding the other goal resolutions.


Maczka Michal wrote:

Probably Jason will soon describe his idea regarding processing workflows in
I have an idea which might be compatible with his intentions ( I am not sure
about it) but addresses different requirements: limiting the visibility of dependencies (e.g. test, compile etc).

My observation are the following:

In most of the case users will be executing a collection of goal which are
defined by the given workflow:

build (builds jar, war  etc)
publish (publish site)

For example "build" workflow can have (among others) the following branches:

----- xxx
------ compile
|           java:compile
| ... ----- test
         -- surefire:test
                 -- test:compile
                 -- test:copy-resources
---- yyy

So as you can see:

a) we can have multiple workflows (e.g. build, release)
b) workflows can use other workflows (e.g. "release" can use "build" and
"build" can use "compile" and "test")

Any workflow spans the tree of nodes which can be iterated using DFS
algorithm (dfs defines the order in those trees).
In order to execute the full workflow entire tree (all nodes) must be

My idea is that this can be nicely aligned with scoping of dependencies.

Dependencies can be labelled with  the <scope> tag

The value of this tag will relate to the node in the tree spanned by the workflow nodes

So for example if we do something like:


This dependency will be visible only when we are visiting the node "test" or
any of child nodes of "test" node.

----- xxx
------ compile
|           java:compile
| . ----- TEST
         -- SURFIRE:TEST
                 -- TEST:COMPILE
                 -- TEST:COPY-RESOURCES
---- yyy

With this in place we are able to select dependecy which will be visible for
a single plugin/goal
(e.g <scope>test:compile</scope>) or for multiple plugins/goals which are
going to be invoked during the execution of sub-workflow
(e.g. <scope>test</scope>)

If scope tag is not used a dependency will be visible for all states of the

IMO this is as simple as it can get and most if not all - (I have to think
about it bit more) of the requirements defined in m2 use cases and releated to test dependecies
are satisfied.


<Prev in Thread] Current Thread [Next in Thread>