Thanks for your help figuring out what the options are, Dennis. See comments interspersed.
On 12/5/05, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Phil Steitz wrote: > > On 12/4/05, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Dennis Lundberg wrote: > >>> Brett said that this *should* work, so I decided to try it myself. I > >>> received the same results as you did Phil, regarding maven --info, but I > >>> think I understand what is going on now. I have posted a question about > >>> this on the maven-users list to see if I can get some confirmation. > >>> > >> Sorry this went over my head earlier, but Dennis' analysis on the usres > >> list is correct. Maven --info doesn't reflect the difference as it > >> reports what's installed. Plugin dependencies are only used for the life > >> of the project's build, not installed. > >> > >> So the dependency should work regardless of what maven --info says. Is > >> that the case? > > > > Then the solution to add the necessary dependencies to commons-build > > won't work and what we need to do is something like pluginUpdate > > (bunch of explicit plugin installs from the command line). Correct? > > No, as I will elaborate on further down, it will work nicely. I'll leave > aside for a moment the discussion whether or not it's a good idea to > extend project.xml from commons-build in other components. > > Setting up dependencies for a specific version of a Maven plugin, i.e. > the xdoc and site plugins, works the way we want them to. I have tried > this and it's easy to set it up. Here's what needs to be added in > commons-build/project.xml for site generation: > > <dependencies> > <dependency> > <groupId>maven</groupId> > <artifactId>maven-site-plugin</artifactId> > <version>1.6.1</version> > <type>plugin</type> > </dependency> > <dependency> > <groupId>maven</groupId> > <artifactId>maven-xdoc-plugin</artifactId> > <version>1.9.2</version> > <type>plugin</type> > </dependency> > </dependencies> > > This will ensure that building the web site for commons-build will > always use these versions of the plugins, regardless of what the user > has installed on his or her system. So far all is good. Now on to the > "to extend or not extend" discussion... > So will only work for the main commons site, IIUC, which is not good enough. We need the individual sites to build without pain for RMs / maintainers. If just running a clean target in commons-build does not effectively update them, then above strategy will not work, unless you are talking about adding the dependencies to each individual POM, or reverting to extending commons-build, or I am not understanding something. > If commons component A extends the project.xml file from commons-build > these dependencies are transfered to that component, meaning that > component A doesn't have to worry about dependencies for site generation. > > However, if commons component B does *not* extend the project.xml file > from commons-build these dependencies will have to be repeated in the > project.xml file for component B. Hopefully these dependencies would not > change all that often, meaning that little work would have to be done in > order to keep this working, once it has been set up properly. > > Either way I think there is a big win including these dependencies in > commons-build and all commons components. What do you think? > I don't much like the idea of adding dependencies to each of the individual POMs, but understand that this makes the dependency explicit, which is a good thing. So I guess I am +0 for this approach. Actually +1 as in "will help" if others agree we should go this route instead of the updatePlugins approach. I remain -1 on reverting to extending the commons-build POM because this makes individual releases depend on something not shipped (or even release managed) with them and forces users to have commons-build checked out to compile/jar under maven. I know we are still partially broken in this way now, as most projects require commons-build to be checked out for site generation. I view this as less of an issue, though, because we ship the docs with the releases. We should find a way to copy and adjust references to all of the required stuff as (automated, of course ;-) part of the dist build so the releases are 100% self-contained and can be reproduced fully from svn tags. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
