commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [GUMP@vmgump]: Project commons-id (in module commons-sandbox) failed
Date Mon, 27 Aug 2007 14:59:38 GMT
Stefan Bodewig wrote:
> On Sat, 25 Aug 2007, Dennis Lundberg <dennisl@apache.org> wrote:
>> Stefan Bodewig wrote:
>>> On Sat, 25 Aug 2007, Dennis Lundberg <dennisl@apache.org> wrote:
>>>
>>>> Gump needs to run maven in online mode, so it can download the
>>>> necessary dependencies, see below...
>>> No, if it did, it wouldn't be serving the purpose it is used for.
>>> If Gump runs Maven in online mode it cannot control the artifacts
>>> Maven builds against.
>> OK, I'm not up to speed on the purpose of Gump.
> 
> No problem.
> 
> Gump tries to be an early warning system for backwards incompatible
> changes.  It detects a backwards incompatible change in a project A by
> building all other projects that state a dependency on any version of
> A against trunk of A instead of the specified version.
> 
> If for example velocity changed in a way that would break the
> commons-id build, then commons-id would get notified (yes, it would be
> nicer if velocity got the nag mail, we know).
> 
> In order to work, Gump must completely ignore the version a project
> asks for and instead will always provide a project with the very
> latest versions of its dependencies.
> 
>>> The Gump project descriptor of commons-id must list all
>>> dependencies, so Gump can produce the proper jar overrides.
>> The Gump project descriptor, is that file that resides on the Gump
>> server?
> 
> The files live in <https://svn.apache.org/repos/asf/gump/metadata/>
> and any ASF committer has write access.  commons-id would be in
> <https://svn.apache.org/repos/asf/gump/metadata/project/commons-sandbox.xml>.

I had a look at this and found these dependencies:

     <depend project="ant"/>
     <depend project="commons-discovery"/>
     <depend project="commons-logging"/>
     <depend project="xml-xerces"/>
     <depend project="junit"/>
     <depend project="maven-cobertura-plugin"/>
     <depend project="maven-xdoc-plugin"/>

But if I read the descriptor right, it runs 'maven jar' which shouldn't 
need either maven-cobertura-plugin or maven-xdoc-plugin. They are 
specified in the project.xml file in order to get a certain version for 
the site generation.

I'll patch the descriptor and see how it goes...

>>> But are these
>>>
>>>>> dom4j-1.4.jar commons-jelly-1.0-RC1.jar
>>>>> commons-jelly-tags-jsl-1.0.jar commons-jelly-tags-log-1.0.jar
>>>>> commons-jelly-tags-velocity-1.0.jar
>>>>> commons-jelly-tags-xml-1.1.jar (try downloading from
>>>>> http://jakarta.apache.org/commons/jelly/libs/xml/)
>>>>> maven-1.0.2.jar maven-model-3.0.0.jar velocity-1.4.jar
>>>>> commons-jelly-tags-fmt-1.0.jar
>>> really dependencies of commons-id?  Or are they needed by some
>>> Maven plugin that is used by the commons.id build but not by any
>>> (most?)  other Maven builds under Gump?
>> None of these are listed as dependencies in either the M1
>> project.xml or the M2 pom.xml. To me they look like Maven 1 internal
>> or plugins dependencies.
> 
> I thought so.
> 
>> That being said, Commons Id doesn't use any "weird" plugins:
>>
>>      <report>maven-changes-plugin</report>
>>      <report>maven-checkstyle-plugin</report>
>>      <report>maven-cobertura-plugin</report>
>>      <report>maven-javadoc-plugin</report>
>>      <report>maven-junit-report-plugin</report>
>>      <report>maven-jxr-plugin</report>
>>      <report>maven-license-plugin</report>
> 
> Has any of them been added lately?  It's not as if commons-id had been
> failing for months.
> 
> Then again Gump is now working on a fresh machine, maybe we are simply
> missing one of those jars that have been present in the old local
> repository.
> 
> We know that we need to run Maven in online mode at least once after a
> fresh install so it can download its internal dependenices.  Given
> that any other Maven1 project seems to work (well at least they break
> in different ways), it probably is one of those plugins - and nobody
> else seems to be using it as well.
> 
> I'll manually run Maven in online mode once, this should silence the
> nag mails.
> Stefan

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message