maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Test dependencies - another take
Date Fri, 21 Jan 2005 10:05:26 GMT
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
>are satisfied.
>
>
>Michal
>
>
>  
>


Mime
View raw message