Definitely. As an aside, will we ever have a use-case that doesn't
involve a workflow? What about doxia:site (or whatever it is)?
Maczka Michal wrote:
>
>>-----Original Message-----
>>From: John Casey [mailto:jdcasey@commonjava.org]
>>Sent: Friday, January 21, 2005 3:37 PM
>>To: Maven 2 Developers List
>>Subject: Re: Test dependencies - another take
>>
>>
>>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.)...
>>
>
>
> To make it more clear. Workflows which I described (and in general) are
> composed from states.
> In our case those states might coresponds to another workflows (e.g.
> "release" workflow will need to execute "build" workflow) or to plugin
> goals.
> I wanted to stay abstain from the problem what actually happens in given
> node of the tree (e.g this is leaf or not, to which (if to any) plugin it is
> mapped).
> For maven core it might ve simple - when any node gets vistied stack of
> currently visible dependecies might be changed.
> So project.getDependecies() (we might add another method in this class or in
> other class) will return different list depending on the
> current location in the three which is defined by the workflow.
>
>
>
>
> Michal
>
>
|