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 >>> >> >
