Question About Reactor Operation

["Allison, Bob" <ro...@qwest.com>]

(I was going to try to find the reactor code in my SVN tree before
asking this, but can't seem to find it :-(  )

General Info:  Our Maven 1.0.2 development tree consists of three
directory levels:  The top level has global goals and properties, the
mid-level directories are artifact-specific (portlet, webapp, library,
...) and contains goals and properties related to the particular type of
artifact being produced (this includes alias-type goals which allow the
developer to type "maven install" in any project and get the right goal
executed), the bottom-layer directories contain artifact-generating
projects.

I was wondering if there has been any thought towards being able to
optionally filter the projects that the reactor is going to run.  I have
three use cases that I have working to various degrees in Maven 1.0.2:

Use Case 1:  There are a number of project directories which do not
produce artifacts (the top level and all mid-level directories, for
example) as well as a few projects which are samples and should not be
included in the production deliverables.

Use Case 2:  When generating documentation, I need to include the top
level and mid-level directories in order to get the lower-level projects
documented.  I also want some of the samples to be included in the
product documentation.

Use Case 3:  Because of some constraints in the portal server we are
using, we need to combine a few of the portlets into a single web
application.  We would like to keep the portlets in individual projects
and be able to deploy the portlet either by itself or as part of a
combined web application.

In case 2, I filter the list of projects by replacing the
"multiproject:projects-init" goal with one that has all of the original
code plus some additional code to remove projects that do not have one
of the use case properties set to true (case 1 is
"productname.production", case 2 is "productname.document", case 3 is
"productname.one-app").  For the other two cases, I wrote my own search
goal and provide the reactor with a list of projects.

It would be really nice to be able to create a plugin which can contain
a method that the reactor calls after finding the project but before
starting to work on it; the method could return a true/false to indicate
whether or not the project passes the filter.  To make this transparent
to plugins that don't need this functionality, we would need a concrete
implementation of the method in AbstractMojo which always returns true
(unfortunately, this doesn't help those which choose to implement the
interface rather than extend the abstract base class).

I have not yet been able to spend the required amount of time to start
building a plugin, so I do not understand how things work well enough to
know if this is even a reasonable request.  If this is not feasible, I
understand and will do my best to rearrange how we are doing things (or
stick with 1.0.2 for a while longer).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Question About Reactor Operation

[Brett Porter <br...@apache.org>]

Hi,

Allison, Bob wrote:

>(I was going to try to find the reactor code in my SVN tree before
>asking this, but can't seem to find it :-(  )
>  
>
It's in DefaultMaven presently (it may have moved to the
DefaultLifecycleExecutor in part, I haven't looked since the recent
aggregation changes).

>Use Case 1:  There are a number of project directories which do not
>produce artifacts (the top level and all mid-level directories, for
>example) as well as a few projects which are samples and should not be
>included in the production deliverables.
>  
>
Set these to packaging "pom".

>Use Case 2:  When generating documentation, I need to include the top
>level and mid-level directories in order to get the lower-level projects
>documented.  I also want some of the samples to be included in the
>product documentation.
>  
>
We're working on a proposal for having the site become reactor aware out
of the box.

>Use Case 3:  Because of some constraints in the portal server we are
>using, we need to combine a few of the portlets into a single web
>application.  We would like to keep the portlets in individual projects
>and be able to deploy the portlet either by itself or as part of a
>combined web application.
>  
>
This should be done by creating a web application subproject that
depends on the portlet projects.

>In case 2, I filter the list of projects by replacing the
>"multiproject:projects-init" goal with one that has all of the original
>code plus some additional code to remove projects that do not have one
>of the use case properties set to true (case 1 is
>"productname.production", case 2 is "productname.document", case 3 is
>"productname.one-app").  For the other two cases, I wrote my own search
>goal and provide the reactor with a list of projects.
>  
>
I didn't catch how this acheieved what you were doing for the site?

>It would be really nice to be able to create a plugin which can contain
>a method that the reactor calls after finding the project but before
>starting to work on it; the method could return a true/false to indicate
>whether or not the project passes the filter.  To make this transparent
>to plugins that don't need this functionality, we would need a concrete
>implementation of the method in AbstractMojo which always returns true
>(unfortunately, this doesn't help those which choose to implement the
>interface rather than extend the abstract base class).
>  
>
I'm not sure this is necessary: you can simply check what you need to
know about the project at the start of the execute() method and return
successfully if you don't deal with it.

What you might be wanting is when it works in an aggregate mode, which
works differently - the plugin goal is run at the top level with a
selection of projects instead of being run on the subprojects - in this
case you can again filter the project list in the execute() method.

Interesting idea, but I'd probably want to look at more use cases and
check whether they are already covered or not.

Thanks,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org