commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Date Mon, 05 Dec 2005 18:48:01 GMT
On 12/5/05, Phil Steitz <phil.steitz@gmail.com> wrote:
>
> 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'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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message