Re: excalibur builds!

Sam Ruby wrote:
> Leo Simons wrote:
>>> If you want, you can use Gump itself in the meantime.
>>> Make an Avalon profile, give the classpath the jars needed that are 
>>> not generated in the avalon project, and it will build any avalon 
>>> project.
>>
>> could you give an example? I don't want everyone to have to set up 
>> their own gump workspace (ie rubix.xml). Is that possible you think?
> 
> rubix.xml is just a properties file with an XML syntax.  Drop the 
> "additional projects" and "after the bootstrap", and you end up with a 
> rather small file with only two things most users will need to tailor: 
> basedir and user.  (To be fair, I fully expect most people will also 
> want to tailor pkgdir).
> 
> If somebody wants to go down this path, I will help.  It certainly is 
> easier than building each dependency with Ant.  And doesn't require any 
> change to Avalon to work.
> 
> It *will* require a little trial and error to find out what the minimum 
> Avalon really needs to build.  You would think that this is something 
> that could be determined by analysis, but in practice it is often easier 
> and more reliable to try it and see.

I'm wondering a little whether it is worth the effort...if I keep things 
running till the next centipede is out I somehow suspect someone else 
will happily move us over ;)

If I have time this weekend, I'll experiment. If not, not.

> P.S.  Because of build.sysclasspath=only, I have yet to reproduce the 
> excalibur build under gump, but I am confident I will.  For those 
> interested in why this is so, here's two links:
> 
> http://gump.covalent.net/log/jakarta-avalon-excalibur.html

compile:

prepare-conf:

jar:

dist-jar:

dependencies-test:

compile-test:
[mkdir] Created dir: /data/gump/jakarta-avalon-excalibur/cli/build/testsrc
[copy] Copying 2 files to 
/data/gump/jakarta-avalon-excalibur/cli/build/testsrc
[mkdir] Created dir: 
/data/gump/jakarta-avalon-excalibur/cli/build/testclasses
[javac] Compiling 2 source files to 
/data/gump/jakarta-avalon-excalibur/cli/build/testclasses
[javac] 
/data/gump/jakarta-avalon-excalibur/cli/build/testsrc/org/apache/avalon/excalibur/cli/test/ClutilTestCase.java:12: 
cannot resolve symbol [javac] symbol : class AbstractParserControl
[javac] location: package cli
[javac] import org.apache.avalon.excalibur.cli.AbstractParserControl;

> http://jakarta.apache.org/gump/why.html

"So I did the only thing I could think of. I hacked Ant so that I could 
tell it to ignore the classpath elements in build scripts. All of them. 
This was then and remains now a dirty, nasty hack. It meant that test 
cases could not be run using the recently compiled classes unless I knew 
in advance where the classes were to be placed. It means that cactus 
can't be built in one run against both Tomcat 3 and Tomcat 4."

IOW, Gump is ignoring the reference to ${build.classes}, so the tests 
can't be compiled, right? Funny, as I believe this works properly in 
most gump-managed projects. Have you dealt with this before?

> I am confident that it would would if build.sysclasspath=last were 
> specified, and that is something that is controllable as a property in 
> the workspace.

I must say I have very little idea what you're talking about...no time 
to investigate right now....

cheers,

- Leo