On Dec 22, 2008, at 11:32 AM, Todd Thiessen wrote:
For instance, as a developer on your project just getting up to
speed, I
shouldn't have to know that there even is a docbkx goal defined in
your
POM in order to do a build. All I should need to know are the core
life
cycle phases like package, install, deploy, site, etc... If your
project
needs to do some some docbkx stuff, then that stuff should be bound to
the appropriate place in the lifecycle.
The problem with this approach is that lifecycles are coarsely
grained. For example, we use the docbkx plugin to generate
documentation, so there's really only one phase where it would belong:
the site phase. However, we have other plugins bound to "site" as
well, such as the JavaDoc plugin. As a result, the entire site phase
takes a very long time to run. (JavaDoc is quite slow when there are
many documented classes and methods.) On top of that, executing the
site phase triggers other phases to run, such as "install", which has
still more plugins bound to it, such as a bytecode obfuscation plugin.
These also take a long time to run.
In the end, we're talking about a site phase that takes around 5
minutes to complete. If a developer adds a sentence or two to the
DocBook source and wants to see how it looks in HTML, he must now wait
5 minutes to do so. If he then sees a mistake and wants to regenerate
the HTML, then that's another 5 minutes. This is simply unacceptable.
Because of this performance issue, the developers on our project need
to know how to invoke a docbkx goal by itself. I can't just bind it to
a phase and tell them to run that phase, since that would kill their
productivity.
Trevor
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
