Sam Ruby wrote:
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 ;)Leo Simons wrote: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 you want, you can use Gump itself in the meantime.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?
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.
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.
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:compile:
http://gump.covalent.net/log/jakarta-avalon-excalibur.html
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;
"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."http://jakarta.apache.org/gump/why.html
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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
