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:
(BUILD WORKFLOW )
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
child nodes of "test" node.
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
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