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 <ctubb...@apache.org> wrote: > On Fri, Mar 20, 2015 at 2:51 PM, dan bress <danbr...@gmail.com> 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 <ctubb...@apache.org> > wrote: > > > >> On Fri, Mar 20, 2015 at 12:16 PM, dan bress <danbr...@gmail.com> 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: 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 > >
