I definitely agree that we should scope dependencies to a particular
"step" in the build workflow (i.e. testing), but I do not agree that
this scoping should simply get tied to a particular plugin. It raises
two questions in particular: which particular testing plugin (this is
not what you intended, brett, I know...), and more importantly, what if
a particular plugin provides mojos/goals for each type of workflow you
might follow with a project (WAR plugin, EAR plugin both have 'build',
'install', 'deploy' f.e.)...
I'm not sure it's as simple as tying it to a plugin, and I believe is
just another pointer to the need for a generically specified workflow
for common build types. In other words, scoped dependencies should
declare themselves as 'test', 'package', 'compile', etc. and these steps
should then be mapped to specific goals according to project type, user
preference, etc. The goal fills a role, and dependencies are associated
with a role...
We're probably on the same page, but it occurs to me that we're
struggling with some of the nomenclature a bit. If this is what either
of you were saying in your emails, I beg pardon.
Brett Porter wrote:
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
I have an idea which might be compatible with his intentions ( I am
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
defined by the given workflow:
build (builds jar, war etc)
publish (publish site)
For example "build" workflow can have (among others) the following
(BUILD WORKFLOW )
| ... ----- test
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
any of child nodes of "test" node.
| . ----- TEST
With this in place we are able to select dependecy which will be
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
IMO this is as simple as it can get and most if not all - (I have to
about it bit more) of the requirements defined in m2 use cases and
releated to test dependecies