commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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 <dennis.lundberg@mdh.se> wrote:
> Phil Steitz wrote:
> > On 12/4/05, Brett Porter <brett@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message