On 12/5/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > > 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'm more than happy with the updatePlugins approach. It's KISS at its best. ;-) I remain -1 on reverting to extending the commons-build POM Ditto. -- Martin Cooper 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] > >
