The usual way is deploy the site and publish javadocs as part of the site. If not that, then the alternative is invoking it via a profile. mvn -P javadoc deploy would work just the same (the current javadoc plugin configuration would just move to the profile, no other changes needed).
Kalle On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<[email protected]> wrote: > Great, thanks very much for this Kalle. > > +1 to removing the JavaDoc as part of the install process to shorten > build times. I wouldn't want to move it to a profile until we can > also guarantee it executes during the deploy goal so the build server > produces them during the normal deployment. I'm sure this is an easy > fix that I'm overlooking... > > On Mon, Aug 24, 2009 at 10:30 AM, Kalle > Korhonen<[email protected]> wrote: >> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<[email protected]> wrote: >>> I'd be happy to add any patches you might be able to contribute. I >>> agree that there is still some cleanup left like what you recommend. >>> I think it might make more sense to include these as patches to >>> different Jira issues just in case one or more of them need to be >>> discussed first. >> >> Ok, I'll open 2-3 issues with small patches. >> >>> As for the javadoc, I just added that back really quickly before our >>> first maven deployment to ensure that it would be uploaded. For some >>> reason the previous configuration didn't seem to be generating it at >>> all. Where should it go? I personally don't really care how it is >>> defined as long as it is generated and uploaded each time a deployment >>> is done. Any patches/recommendations for that? >> >> By default javadoc:jar binds to package phase, which is the >> recommended usage. However, it takes some time and the most common >> Maven command is mvn install so it makes sense to try to optimize the >> execution time of it. For one project at work the javadoc is created >> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc >> install. However, the most common way to do it is to generate javadoc >> as part of site deployment (I think site plugin executes it even by >> default). We could do it with a profile for now while we think about >> the site deployment some more (as part of the other email thread). >> I'll create an issue and add a patch. >> >> Kalle >> >> >>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle >>> Korhonen<[email protected]> wrote: >>>> There are a few small errors in the trunk and some and some >>>> folders/files that would need to be ignore from svn. I could easily >>>> write up a patch to clean it up (I like my source tree all clean and >>>> nice so nothing would mask the real errors), but would the committers >>>> accept it, and if so, should I open an issue for each of them >>>> separately or one for all? It'd cut down on bureaucracy if somebody >>>> with commit rights would do them directly. Here's a few for reference: >>>> >>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs >>>> to declare org.apache.shiro (not org.shiro). >>>> - all target folders need to be added to svn:ignore >>>> - IDE specific files should be added to svn:ignore >>>> - why is javadoc generated as part of regular install goal? >>>> >>>> Kalle >>>> >>> >> >
