On Mon, Apr 26, 2010 at 8:39 AM, Marshall Schor <[email protected]> wrote: > My use case: > > I'm running the maven docbkx plugin to produce both pdf and html outputs > from multiple docbook sources. > > The docbkx plugin says to use two executions (with ids, for instance, of > "html" and "pdf", one for each of the outputs). > > I would like to reuse this setup 4 times in my builds, because I have 4 > "books" to process in this project. > > I'm trying to factor out common configuration for these, into a > pluginManagement element, having 2 configurations with those ids of > "html" and "pdf". > > I understand that the configuration merging is done by matching "ids". > My trouble is that when I now try to write my 8 executions (2 per book), > I have to write 8 unique "ids", which can't match up with the 2 ids in > the pluginManagement. > > Is there a maven best practice for how to factor this? > > I know the one "solution" of splitting up the 4 docbooks into 4 separate > projects, but I'm looking for another solution since I would rather not > split these up. >
One solution would be to separate content from rendering. I have books that need to be packaged into a different formats. Each book is rendered as a PDF, HTML, and as an eclipse book. In addition to these formats, a book may need to be rendered in a reduced format for a special print, and each book needs to be published to Scribd, Lulu, etc. I reached a point with docbkx where I was frustrated with having to deal with a massively customized lifecycle in one central "book" project. Instead of dealing with 8 executions, I have a content project that installs docbook source as a JAR in the local repo. Other projects in the multimodule project then declare the source as a dependency and process the docbook accordingly. See here: http://github.com/sonatype/nexus-book/ While it is substantially more complex than what you are doing, you might find that the separation allows you to avoid having to define 8 plugin execution ids. Or, you might be able to fiddle around with project hierarchy once you've moved away from the "massive, monolithic docbkx project" approach. > -Marshall > > --------------------------------------------------------------------- > 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]
