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?
>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? >>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. 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). This is certainly something we want to work through as there are various different aggregation scenarios we haven't tried yet. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
