Stefan Bodewig wrote:
On Sat, 25 Aug 2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Stefan Bodewig wrote:
On Sat, 25 Aug 2007, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
