I'd probably configure the asciidoc plugin to run at the "site" phase, and change its output directory to target/site. That is, unless you really want to package the html as an a separate artifact in addition to putting it on the site. In that case, I might use exec-maven-plugin (or another plugin) to unpack the zip artifact into the appropriate target/site during the "site" phase to avoid executing asciidoctor a second time.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Mar 26, 2015 at 12:01 PM, dan bress <[email protected]> wrote: > Christopher, > Thanks for the info. > I am going with the approach of generating my javadocs as part of the > mvn site. This works great. Now the next problem: > > Under my top level project I have a project called "docs". It is a > collection of asciidoc source files that I use the asciidoc plugin to turn > into html files, and then i use the assembly plugin to put them in a zip. > This all happens during the "install" lifecycle. This is the "in-app" html > documentation that is bundled with my application. I am trying to get this > generated html also included in my site, but don't see a good way to do > that right now. > > I noticed I can put a dependency from maven-site-plugin to > asciidoctor-maven-plugin, and then copy the source .adoc files to > src/site/asciidoc then they get picked up, and html is generated. This is > cool EXCEPT it means that I have to have my source asciidoc files in two > places, one for the install phase generation, and one for the site phase > generation. > > I suppose I could always keep the files in src/site/asciidocc, and point > the "install phase" ascii-doctor plugin to > > Any ideas here? > > Dan > > > > On Fri, Mar 20, 2015 at 3:15 PM Christopher <[email protected]> wrote: > >> On Fri, Mar 20, 2015 at 2:51 PM, dan bress <[email protected]> wrote: >> > Christopher, >> > Thanks for the info. >> > was your "docs" submodule, where the assembly lived? How would you >> > bundle the javadocs created by the parent? >> > >> >> At the time we were doing this, the docs module was where we generated >> a PDF from LaTeX source. A sibling module did the final tarball >> assembly, which grabbed the PDF documentation generated in the docs >> module, and the javadocs which were generated in the parent but stored >> in the docs module's directory (by overriding outputDirectory in the >> parent task to point to docs/apidocs instead of the default >> target/apidocs; note: this is a terrible idea; generated stuff should >> always go in target). >> >> To be clear, I would not advise this method. I just know it's do-able >> with multiple lifecycle arguments on the maven command-line. >> >> > What I am trying to do is capture all the build related >> > documentation(javadoc, asciidoc, and some other build generated >> > documentation artifacts) and put that in a directory structure so that I >> > can put it on our website. This is why I am aggregating all the javadoc >> in >> > one place. I'm open to other ideas if you have them. >> > >> >> There's a couple of ideas. >> >> 1. You could try using the site/reporting features to generate >> javadocs, rather than using aggregate goal. >> 2. You could create a separate project to build the assembly for the >> site, which depends on your main project. >> 2a) You could depend on your main project's source artifact, >> executes a task which builds the javadocs, and bundles them >> 2b) You could depend on your main project's individual modules' >> individual javadoc jars, and aggregate them manually in your site's >> assembly >> 3. You could manually execute a separate task to build the docs for >> the site, which does not depend on your main build. >> >> Keep in mind that your main Maven build should be for the purposes of >> reproducibly creating deployable artifacts. There are many plugins >> which can be executed independently from your main build, to perform >> useful tasks, but I would avoid conflating the two and trying to bake >> in these utility tasks into your main build, as you're just going to >> make it difficult to produce artifacts/releases. "mvn >> javadoc:aggregate" can always be executed as a separate task, and it >> *may* be more appropriate to do that separately, after you build and >> deploy your artifacts. >> >> > Dan >> > >> > On Fri, Mar 20, 2015 at 12:59 PM Christopher <[email protected]> >> wrote: >> > >> >> On Fri, Mar 20, 2015 at 12:16 PM, dan bress <[email protected]> wrote: >> >> > Maven, >> >> > I have a multi module maven project and am trying to generate an >> >> > assembly that houses all our javadocs and our asciidoc generated docs. >> >> How >> >> > would you do this? >> >> > >> >> > Currently I have a directory structure that looks like this: >> >> > >> >> > root >> >> > java-library-one >> >> > java-library-two >> >> > ascidoc-project >> >> > pom.xml >> >> > >> >> > If I put a javadoc:aggregate plugin execution on the root pom it >> >> generates >> >> > the javadoc for both of my projects, which is what I want. But I am >> not >> >> > sure where to put my assembly. Should that be called from the root >> pom? >> >> > Should I make a sub project for the assembly? If I do that, can it >> refer >> >> > to the javadoc generated by the parent? >> >> > >> >> > Let me know what you think! >> >> > Thanks! >> >> >> >> I've done something like this in the past. It's not pretty, but >> >> essentially, I had a sub-module for "docs", which, in its package >> >> phase, would bundle the javadocs created by the parent. To get this to >> >> work, I would have to run: >> >> >> >> mvn compile javadoc:aggregate package >> >> >> >> This would essentially force 3 lifecycles, the first to compile and >> >> the second to build the javadocs (which requires compilation first), >> >> and the third to package. Incidentally, the third lifecycle would end >> >> up compiling again, which was a bit of a waste, but it did work. >> >> >> >> In general, I'd avoid trying to bundle all the javadocs... partly >> >> because this is messy, and partly because I don't see a lot of value >> >> in a deployable artifact which bundles all the javadocs from many >> >> modules. Currently, my project only bundles individual javadoc jars to >> >> deploy to maven, and no longer builds an artifact with the aggregated >> >> javadocs. We still occasionally run javadoc:aggregate, though to >> >> generate docs to publish. >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
