You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gump Integration Build <de...@avalon.apache.org> on 2003/02/28 11:32:24 UTC
[GUMP] Build Failure - excalibur-xmlutil
----------------------------------------------------
This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-02-28/excalibur-xmlutil.html>
----------------------------------------------------
Buildfile: build.xml
Caught exception (org.apache.tools.ant.BuildException) while expanding tools.class.path: /home/rubys/jakarta/jakarta-site/lib not found.
dependencies:
check-environment:
compile:
[mkdir] Created dir: /home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
[javac] Compiling 34 source files to /home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:70: package org.apache.xml.resolver does not exist
[javac] import org.apache.xml.resolver.CatalogManager;
[javac] ^
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:71: package org.apache.xml.resolver.tools does not exist
[javac] import org.apache.xml.resolver.tools.CatalogResolver;
[javac] ^
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:102: cannot resolve symbol
[javac] symbol : class CatalogManager
[javac] location: class org.apache.excalibur.xml.DefaultEntityResolver
[javac] protected CatalogManager catalogManager = new CatalogManager();
[javac] ^
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:105: cannot resolve symbol
[javac] symbol : class CatalogResolver
[javac] location: class org.apache.excalibur.xml.DefaultEntityResolver
[javac] protected CatalogResolver catalogResolver = new CatalogResolver(catalogManager);
[javac] ^
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:102: cannot resolve symbol
[javac] symbol : class CatalogManager
[javac] location: class org.apache.excalibur.xml.DefaultEntityResolver
[javac] protected CatalogManager catalogManager = new CatalogManager();
[javac] ^
[javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:105: cannot resolve symbol
[javac] symbol : class CatalogResolver
[javac] location: class org.apache.excalibur.xml.DefaultEntityResolver
[javac] protected CatalogResolver catalogResolver = new CatalogResolver(catalogManager);
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 6 errors
BUILD FAILED
file:///home/rubys/jakarta/avalon-excalibur/xmlutil/build.xml:111: Compile failed; see the compiler error output for details.
Total time: 5 seconds
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
>>Until
>>there is a better alternative one should be moderate with criticism,
>>or act on it :D
>
> But I ***am*** acting on it! What, you mean whining doesn't count?
ROTFL!
sun is shining over here. This sounds like a good time to turn of my PC,
before we all volunteer for something further delaying our releases ;)
have a nice weekend!
cheers,
- Leo, who will undoubtly turn his PC back on in an hour or two, but
don't tell anyone :D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons
>
> Leo Sutic wrote:
> > Which outlines all that I think is wrong with GUMP.
> >
> > 1) You can't try it yourself locally before committing.
>
> you can but it is a pain in the $*!# to setup as you need
> gigs and gigs
> of diskspace and running it takes a long time.
Yes, but with a remote and local repository that is updated
as needed and blah blah blah blah - you know how to
improve this, right, so I don't have to say it?
I get it:
1. Gump is big and ugly because it has to work with
Ant buildfiles.
2. Gump has to work with Ant buildfiles because it is
so big and ugly that no one would use a new buildfile
format designed specifically for gump.
> You should understand the context in which GUMP was created
> (http://jakarta.apache.org/gump/why.html). It has broken quite a few
> lances for continuous integration, and it does its job.
I understand the context, and I understand why it ended up the way
it is. What I don't like is that it stopped there.
> Until
> there is a better alternative one should be moderate with criticism,
> or act on it :D
But I ***am*** acting on it! What, you mean whining doesn't count?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> Which outlines all that I think is wrong with GUMP.
>
> 1) You can't try it yourself locally before committing.
you can but it is a pain in the $*!# to setup as you need gigs and gigs
of diskspace and running it takes a long time.
> 2) You have dependency information in several places.
yep.
> 3) Building with gump is vastly different from just building.
the thing gump adds to the "just building" is classpath management (ie
override). Any system that works with existing ant build systems has, I
think, no other option. Either one must extensively modify ant or move
to something else.
> 4) Building with GUMP is not a single command, it is a
> ritual.
when you have all of gump installed (like on nagoya) on a server, you
can run gump with './cvs/jakarta-gump/gen.bat; ./update all; ./build
all'. Add that line to a crontab and its automated. On the client side
you can verify syntactic correctness of your configuration (using the
'ant gen' target), but you cannot tell the server to immediately check
your changes.
> When picking a build system, I consider these things (among others)
> important:
>
> + You should use the same system for *every* build. All the time.
> You use X for building on your machine, you use it for nightly/daily
> builds, etc. That way, you know that if it builds on your machine,
> odds are better than 99.999% that it will pass the nightly build.
+1
> + Dependency information is kept in ***one*** place.
+1
> + Easy to use.
+1
> Gump fails all three.
Given the design requirement of not or barely impacting the existing
(well, used to be before centipede & maven) de facto standard of
ant-based buildfiles, it is very difficult to satisfy those other goals
you list, without redefining or heavily modding ant. This is mostly
because ant doesn't provide a mechanism for defining inter-project
dependencies.
You should understand the context in which GUMP was created
(http://jakarta.apache.org/gump/why.html). It has broken quite a few
lances for continuous integration, and it does its job. Until there is a
better alternative one should be moderate with criticism, or act on it :D
> How is Maven in comparison?
Jason has sketched out plans for (forgot the name) a piece of software
which will provide continuous integration based on maven POMs instead of
on ant buildfiles (see this lists' archives and maven-dev archives). I'm
not sure how far along this effort is, but I believe the timetable for
arrival is a few months (unless people help write it of course, Jason's
asked for help on it). My guess this is going to turn out as a
continuously running service, similar to some of the existing commercial
tools, but compatible with maven.
Until that project arrives on the scene, maven can't really be used for
continuous integration testing, so no comparison is possible.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Mar 2003 00:17, Leo Sutic wrote:
> How is Maven in comparison?
Damn fine - except for continuous integration. You *can* use maven to generate
the required build.xml and gump.xml but it felt hacky to me and I founf it
easier to just hand hack them.
There is a continous integration tool in the works that will render need for
gump obsolete but thats not out yet.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Sam Ruby <ru...@apache.org>.
Leo Sutic wrote:
>
> The concept is excellent.
>
> The problem is that you don't run Gump locally.
These discussions amuse me.
I run Gump locally. Once a week or so (when things look good) I resynch
by doing an overnight build. If things look bad, I go longer. But
after that point I build and update individual projects on an individual
and as needed basis.
Gump's implementation is in two parts: data reduction and generation.
Despite years of feature creep, the data reduction is 7 Java classes.
The generation is 13 stylesheets. Certainly, technology other than XSLT
could have been used. These stylesheets generate two flavors of
artifacts today: bash and win bat files. Additional flavors could be
added (costin, for example, created an ant flavor).
One thing that I particularly like is that Gump itself doesn't require
anything more than a current JDK to run.
Gump need not build using only inputs from cvs. It can use installed
packages or even jars from cvs. The project definitions need not be
centralized, they can be distributed.
Centipede and/or Ruper can eliminate much of the conceptual start up costs.
Recommended profiles of installed packages and/or related projects to
build from cvs would address the rest.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Simons <le...@apache.org>.
funny how programmers always turn a thread about software usage into one
of software development! I'm just explaining how to /use/ this piece of
software, and I think we should use it (until there is a better piece of
software that can do the same thing) :D
happy coding though ;)
cheers,
- Leo
Nicola Ken Barozzi wrote:
> Actually it is, but not per design ;-)
> The implementation uses XSLT which seems to suck badly as a templating
> system. Change to Velocity, and it will get much better.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Leo Sutic wrote, On 28/02/2003 15.33:
> ...
> > The problem is that you don't run Gump locally.
>
> I don't because I don't want to build everything from CVS. Just the
> current CVS module projects.
Well, that's the problem then: You can't run gump on just one
project, having it fetch the dependencies from some repository
instead of compiling them locally.
> I type
>
> cent build
>
> and it works :-)
Well, how about you type
cent make-gump-shine
and take the rest of the day off then - it is Friday after all? :-)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote, On 28/02/2003 15.33:
...
> The problem is that you don't run Gump locally.
I don't because I don't want to build everything from CVS. Just the
current CVS module projects.
> Where I work, the very same build system that does nightly
> builds run on each developer workstation. Thus, if it builds on
> the workstation -> it builds in the nightly build.
Gump is not simply nightly. It's nightly of all the latest.
> Really, why do we have JARS in CVS? We should just have to specify that
> the project needs jars A, B and C, and make that version 2.0.3 of C,
> please?,
> and then the build system should handle the rest - setting up classpaths
> and so on.
>
> I don't want to type
>
> ant build
>
> to build. I want
>
> gump build
I type
cent build
and it works :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: den 28 februari 2003 15:09
> To: Avalon Developers List
> Subject: Re: [GUMP] Build Failure - excalibur-xmlutil
>
>
>
>
> Berin Loritsch wrote, On 28/02/2003 14.56:
> > However, I do have to say that the *concept* of GUMP
> > is good. The fact that you build your project based on
> > the current CVS of all the dependencies.
The concept is excellent.
> And BTW, Gump does not build, it launches builds. So effectively you
> *do* use the same build tool when using Gump.
Given the vast differences in environment, it isn't the same.
> Actually it is, but not per design ;-)
> The implementation uses XSLT which seems to suck badly as a
> templating
> system. Change to Velocity, and it will get much better.
I'd say that's not the main fault. If Gump worked like it did now,
but with Velocity, it would still be bad.
The problem is that you don't run Gump locally.
Where I work, the very same build system that does nightly
builds run on each developer workstation. Thus, if it builds on
the workstation -> it builds in the nightly build.
Really, why do we have JARS in CVS? We should just have to specify that
the project needs jars A, B and C, and make that version 2.0.3 of C,
please?,
and then the build system should handle the rest - setting up classpaths
and so on.
I don't want to type
ant build
to build. I want
gump build
.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 28/02/2003 14.56:
> Leo Sutic wrote:
>
>>
>> Gump fails all three.
>>
>> How is Maven in comparison?
>
>
> Maven is a replacement for our ANT build script hackery.
>
> They do have a project that is supposed to correct all
> the ills of GUMP.
>
> However, I do have to say that the *concept* of GUMP
> is good. The fact that you build your project based on
> the current CVS of all the dependencies.
>
> That part is good.
And I have started a build system based on Ant tasks that uses the same
descriptor for day2day builds. I'm happy that you finally get to realize
one of the basic motives why I started it.
I piggymack on Gump's CI feature, and use the same descriptor through
Ant to have it always up2date.
And BTW, Gump does not build, it launches builds. So effectively you
*do* use the same build tool when using Gump.
> How it goes about doing it is a mess.
Yes and no.
Actually it is, but not per design ;-)
The implementation uses XSLT which seems to suck badly as a templating
system. Change to Velocity, and it will get much better.
I have mused over not using scripts, but actually it's a feature of
Gump: it totally abstracts from any Java system, so it can even run
native builds and not suffer from JVM errors itself.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
> Gump fails all three.
>
> How is Maven in comparison?
Maven is a replacement for our ANT build script hackery.
They do have a project that is supposed to correct all
the ills of GUMP.
However, I do have to say that the *concept* of GUMP
is good. The fact that you build your project based on
the current CVS of all the dependencies.
That part is good.
How it goes about doing it is a mess.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> I think it's important that all committers working on a
> project realize
> when they need to update the gump descriptors. In this case,
> the fix is
> to add
>
> <depend project="xml-commons-resolver"/>
>
> to the project
>
> <project name="excalibur-xmlutil">
>
> in
>
> jakarta-gump/project/avalon-excalibur.xml
>
> (which I've just done, and which is something people like Sam
> silently
> do for lots of projects whose committers don't maintain the gump
> descriptors very well). This is a common, simple rule: whenever you
> import a dependency into a project in one way or another, you need to
> also add this dependency information to the gump descriptor (and then
> always run 'ant gen' in the jakarta-gump base directory, and
> commit the
> change if there's no errors in the output).
Which outlines all that I think is wrong with GUMP.
1) You can't try it yourself locally before committing.
2) You have dependency information in several places.
3) Building with gump is vastly different from just building.
4) Building with GUMP is not a single command, it is a
ritual.
When picking a build system, I consider these things (among others)
important:
+ You should use the same system for *every* build. All the time.
You use X for building on your machine, you use it for nightly/daily
builds, etc. That way, you know that if it builds on your machine,
odds are better than 99.999% that it will pass the nightly build.
+ Dependency information is kept in ***one*** place.
+ Easy to use.
Gump fails all three.
How is Maven in comparison?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [GUMP] Build Failure - excalibur-xmlutil
Posted by Leo Simons <le...@apache.org>.
(GUMP awareness tutorial part 1 :D)
Interesting to see what happens here as a case study. Carsten updates
the xmlutil stuff based on developments in cocoon. He adds a cvs
snapshot jar to CVS, probably runs a few ant tests to ensure things
work, then commits. Regardless of the fact that it is not a good idea to
have jars in CVS (fix in development :D), and that Carsten doesn't know
that the excalibur build system expect you to modify
${subproject}/default.properties when you add a new dependency, gump is
not told about the change, so it complains and xmlutil fails to build.
This is a prereq failure for xml-cocoon2 (not the only one at this
point, but it could've been), resulting in cocoon not building, and
blocks depending on cocoon core also failing, and stuff like forrest
also failing.
I think it's important that all committers working on a project realize
when they need to update the gump descriptors. In this case, the fix is
to add
<depend project="xml-commons-resolver"/>
to the project
<project name="excalibur-xmlutil">
in
jakarta-gump/project/avalon-excalibur.xml
(which I've just done, and which is something people like Sam silently
do for lots of projects whose committers don't maintain the gump
descriptors very well). This is a common, simple rule: whenever you
import a dependency into a project in one way or another, you need to
also add this dependency information to the gump descriptor (and then
always run 'ant gen' in the jakarta-gump base directory, and commit the
change if there's no errors in the output).
Another common reason why you need to update the gump descriptor is when
source trees or build trees are moved around or reformatted, or even
entire projects. For example, the excalibur-meta project was moved to
avalon-sandbox some time ago, but no-one (should've been me as I moved
it) updated the avalon-excalibur buildfile to know about this, so this
resulted in errors still popping up 2 months after the cvs
restructuring! Another example is when a project not built by gump is
defined by referencing a jarfile, and the name of the jarfile changes.
For example, jakarta-gump/project/xml-cocoon2.xml defines
<project name="maybeupload">
<url href="http://www.weft.co.uk/library/maybeupload/"/>
<package>uk.co.weft.maybeupload</package>
<description>
Upload files from Java Servlets
</description>
<home nested="lib/optional"/>
<jar name="maybeupload_1-0-5pre3.jar"/>
</project>
but the referenced jar
xml-cocoon2/lib/optional/maybeupload_1-0-5pre3.jar no longer exists
(Stefano removed it two days ago). GUMP reports this is a "prereq
failure" for cocoon (so the limited <nag/> tags defined in
xml-cocoon2.xml don't result in a complaint message to the cocoon
mailing list), when in fact the project definition for maybeupload is
now wrong.
gotta go now,
cheers,
- Leo
Gump Integration Build wrote:
> compile:
> [mkdir] Created dir: /home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
> [javac] Compiling 34 source files to /home/rubys/jakarta/avalon-excalibur/xmlutil/build/classes
> [javac] /home/rubys/jakarta/avalon-excalibur/xmlutil/src/java/org/apache/excalibur/xml/DefaultEntityResolver.java:70: package org.apache.xml.resolver does not exist
> [javac] import org.apache.xml.resolver.CatalogManager;
> [javac] ^
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org