> -----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]
