ok defining profiles to have 2 site runs without same reporting plugins is ok: the 2 site runs share the same site.xml what would be an issue would be to require 2 different site.xml files. But from your description, you don't need such thing, no?
Regards, Hervé Le lundi 27 janvier 2014 20:35:00 Benjamin Damm a écrit : > Thanks to you and Mr. Boutemy for your replies. Let me explain a little > more about what I want to do. > > We have perhaps two dozen maven modules that together provide a collection > of core services. Together these modules are an SDK of sorts for clients. > I'm trying to create a structure for generated documentation; however > JavaDoc alone is not enough since we have other artifacts that make up our > SDK. Protobuf definitions, WSDL files, REST services, etc. So, if an > effort to create reliable documentation is going to produce good results, > we need a mechanism that can be shared across all these modules and a model > for how to aggregate the resulting documentation back into one SDK. > > The maven site plugin seems like the perfect structure to base this effort. > We can take advantage of the maven build cycle and the parent pom > structure, we can use skins to create a consistent look and feel, and we > can use existing and new plugins (e.g. JavaDoc and others) to produce > "site" artifacts from source. Controlling the inherited site definition > gives us a relatively easy way to cross-link module output. > > However, the "site" defaults and related plugins also are useful, so I want > to retain the ability to generate classic "site" output (e.g. test reports, > code coverage, javadoc, findbugs). This output is not appropriate for > distribution, but it's very useful for us internally. Hence, my > investigation of using profiles. I started by redefining the site plugin's > configuration in the parent pom within two profiles, so that all the > sub-modules got access to those profiles without defining them > individually. > > If this is a maven anti-pattern, then I certainly hear that and respect > that. I wonder what other options are available? Any ideas? > > Thanks, > -Ben > > -- > Benjamin Damm > Silver Spring Networks > +1-650-839-4201 > ________________________________________ > From: Stephen Connolly [stephen.alan.conno...@gmail.com] > Sent: Sunday, January 26, 2014 11:37 AM > To: Maven Users List > Subject: Re: Renaming site.xml or using different top-level site.xml for > site plugin > > In a multimodule project you need to attach the site descriptor of parent > poms to the reactor. > > Thus the site descriptor you attach will depend on your profile... > > Thus you are in a maven anti-pattern (ie artifacts attached to the reactor > should not depend on the profiles active at the time) > > You will likely have to find a different way, as I believe the rest if the > maven developers will agree with me that this is a bad plan, and hence > there will not be support for trying to solve your actual problem with the > technique that us giving you thus problem > > HTH > > Stephen > > On Friday, 24 January 2014, Benjamin Damm <bd...@silverspringnet.com> wrote: > > Hello Mavens, > > > > Is there a way to rename site.xml to something else? I want to use the > > site framework to produce two "trees" of sites, each quite distinct from > > each other because they are based on two different profiles, and I was > > hoping, two different site.xml from the superpom at the top. > > > > In other words, I'm trying to achieve two trees of sites, each with a > > different site.xml at the top, but otherwise retaining the same structure > > (in terms of modules). I also plan to use profiles to use different > > site.xml files at the module level; that part works fine already because I > > can repoint the entire site document structure by using siteDirectory. > > > > It's the site.xml at the very top that's giving me trouble. No matter > > what I seem to do, I can only have one site.xml at the top of the module > > hierarchy. Does anyone know if there's a way around this limitation? > > > > Scouring the source code of the site plugin has so far not revealed > > > > anything. > > > > Thank you, > > -Ben > > > > -- > > Benjamin Damm > > Silver Spring Networks > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org <javascript:;> > > For additional commands, e-mail: users-h...@maven.apache.org<javascript:;> > > -- > Sent from my phone > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
