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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
