After doing some experimentation, I think I have a means to accomplish what I want without altering the way the reactor works.
I think I can convince my coworkers that we should only document the production projects; this collapses the first two use cases into a single use case that I think can be handled using the <module> stanza in the POM. The third use case is a bit harder, but with the ability to build Java-based plugins I think I can build a plugin to do the aggregation as a separate process. The main things I need to figure out are: -- How do I define a new packaging value? Looking at the m2 code, it appears to involve something called an extension plugin but I could not find a description of what is required to make one. -- How do I link the items to be aggregated to the project? The likely answer here is configuration information provided to the plugin which does the aggregation. -- How do I ensure that the components to be aggregated are built by the reactor before the aggregation occurs? If I declare the components as dependencies, what scope can I use to ensure the correct build order without also causing the web application war files to be automatically added to the artifact being built? > -----Original Message----- > From: Allison, Bob [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 09, 2005 07:58 > To: Maven Developers List > Subject: RE: Question About Reactor Operation > > > > > > -----Original Message----- > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 08, 2005 20:00 > > To: Maven Developers List > > Subject: Re: Question About Reactor Operation > > > > > > Allison, Bob wrote: > > > > >>>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". > > >> > > >> > > >If I set the packaging to "pom" on a sample project that is > > supposed to > > >produce a deployable web application, won't that mess up the build > > >process for that project? I want to be able to produce > > proper artifacts > > >from the sample projects, just be able to automatically > exclude them > > >from production builds. > > > > > > > > Ok, I was confused because you said "directories which do > not produce > > artifacts", didn't catch the "samples not included". > Wouldn't you omit > > those from the <modules> list, and traverse them separately? > > IF they are > > not part of the product release, they probably aren't tagged and > > developed on the same timeline, so could even be in a separate tree? > > They could be in a separate tree, but that makes it hard to > include them > in the product documentation. Also, this case might include > an obsolete > deliverable that we don't want to remove from CVS quite yet > (e.g., used > in a version that is still being supported). > > > > > >I'm not talking about making site reactor-aware (something I > > am eagerly > > >awaiting). I am referring to being able to automatically > > exclude some > > >projects from the documentation. > > > > > > > > Ok, so if it is reactor aware, you want to exclude projects? Is this > > just the same use case as above applied to the site, or are > > there others > > that would be excluded? > > It is almost the same as the previous case, but the list of exclusions > might be different so it would require a different property to filter > on. > > > > > >>This should be done by creating a web application subproject that > > >>depends on the portlet projects. > > >> > > >> > > >The main problem with that, I think, is the portlet-specific > > deplyment > > >descriptors. In the 1.0.2 build tree we are currently using > > I have done > > >a bit of work to have these descriptors generated from project > > >properties in such a way that the descriptor is correct whether I > > >aggregated the portlets or not. > > > > > > > > I had a look at your example below and am still a little > lost. I don't > > totally understand portlets so that may be the reason. If I'm > > off here I > > apologise, but here goes... > > > > One of the key things that makes Maven work is that a project always > > builds a single thing the same way. It appears from your > > example that a > > project builds a different descriptor depending on its > usage. This is > > fine as long as it isn't included in the final artifact. > > Based on this paragraph, I guess I am back to either sticking > with Maven > 1.x or abandoning the idea of being able to keep the portlets in > separate projects and aggregating them as necessary during the build > process. > > > > > It might be better to actually generate the aggregated > > descriptor inside > > the aggregated webapp with a different goal though, that is > > able to take > > the normal generated descriptors and put them together (if > > that's possible). > > The main reasons the descriptor is built inside of the individual > component are: > -- the content of the descriptor depends on a number of properties > defined in the component project > -- the vast majority of the descriptor is the same whether > aggregated or > not > > > > > This is certainly something we want to work through as there > > are various > > different aggregation scenarios we haven't tried yet. > > I can certainly wait on this, and I would be willing to try to help > build the necessary plugins or at least test possibilities to see how > things work in our environment. > > (Since I am still working on figuring out how to build plugins, please > be patient with any errors below...) > > I am assuming that the best way to do the documentation would be a > plugin that extends the site plugin and calls super.execute() only if > the proper property is set. I think the production build > could be done > the same way but I'm not sure which plugin to extend. The > real problem > is the aggregation problem, since I need to be able to collect > information from each project that was processed (I guess from another > plugin extending something like war). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
