Re: Test dependencies - another take

from
[Brett Porter]

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.

Cheers,
Brett
Maczka Michal wrote:

Probably Jason will soon describe his idea regarding processing workflows in
m2.
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)
install
deploy
release
site
publish (publish site)
test
For example "build" workflow can have (among others) the following branches:
(BUILD WORKFLOW )
----- 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
iterated.
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:
<dependency>
....
<scope>test<scope>
</dependency>
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
workflow.
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