I think so, too. I filed a bug (MNG-1464) and included a patch.
-----Original Message----- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 08, 2005 11:51 AM To: Maven Users List Subject: Re: [m2] Adding goals to execution -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd say that the javadoc:jar mojo needs to detect its environment just as the javadoc:javadoc mojo does. That's a bug IMO. FWIW, john David Jackman wrote: | Here's what I'd like to do: For our product, we have a number of | Maven projects, most of which are simple Java jar projects, but others | are not. For these jar projects, I'd like the javadoc:jar and | source:jar goals to execute as well. I'd like this to be as automatic | as possible for projects (i.e. define this in one central place | without requiring individual projects to do anything explicit). | | As far as I know, there are three ways to accomplish this. First | would be to add the plugins to the pom.xml for each project. This | works, but requires adding them to each project, defeating my goal to | only define it in one place. | | The next way to do this would be to add the plugins to the parent | pom.xml. I can put the information into the pluginManagement section | of the parent, but this still requires that each project's pom contain | a reference to the plugin, which I'd rather not do. The other option | is to put the information in the parent's build-plugins. This | actually does seem to work (the subproject picks it up automatically), | but has a an unpleasant side effect in that these goals are run for | all of the non-jar type projects as well as the jar type projects. | Looking a bit closer, it seems the javadoc:javadoc and source:jar | goals are saying they won't execute because the project isn't the | right type, but the javadoc:jar goal runs anyway, creating a javadoc | jar with no actual javadocs in it. Maybe this is just a bug and I should report/patch it. | | The third way to do this would be to add the plugins to a profile and | have the build pick it up there. I'm not as well-versed with | profiles, so I may be missing something here. But from what I know, | for this to work I'd have to specify the profile whenever I build | (unless it's the | default) and make sure all of the developers have the correct settings | for their profile definition (or I suppose I can put the profile | definition into the parent pom, but I'm not sure how that works). I | don't think it actually buys me anything to list the plugins in a | profile, though (i.e. it doesn't work any better than listing the | plugins directly in the parent pom). | | Anyway, is there a recommended methodology for doing this sort of thing? | Is there something I'm missing that I should be taking advantage of? | | Thanks, | ..David.. | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDcPN+K3h2CZwO/4URAjkaAJ49pVI9amanJB//7IuQRoiHX7+0pACfVC7T jSirjtPNkQJoLeZzmwFX2c4= =V93w -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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]
