commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Date Mon, 05 Dec 2005 18:42:08 GMT
Thanks for your help figuring out what the options are, Dennis.  See
comments interspersed.

On 12/5/05, Dennis Lundberg <> wrote:
> Phil Steitz wrote:
> > On 12/4/05, Brett Porter <> 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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message