RE: Missing Class for Fulcrum DVSL
Problem solved! Thank you Gump for finding a missing dependency! > -Original Message- > From: Eric Pugh [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 11, 2004 11:20 AM > To: Gump code and data > Subject: RE: Missing Class for Fulcrum DVSL > > > I have just added jaxen as an explicit maven dependency for DVSL, so > hopefully this will solve the issue. We'll see in the next run! > > I know that fixing the classloaders for plugins will break stuff, but I > believe it will be forward compatible right? If I fix a project that was > unintentionally depending on the single classloader for all > plugins, then it > will still run under maven 1.0, as well as maven 1.1? > > When you get to the point of committing the code, it may be good to put > another instance of gump up with a maven 1.1 Release Candidate so > we can see > who breaks and start fixing them before the official release of 1.1. > > Again, another good reason for Gump! > > Eric > > > -Original Message- > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 09, 2004 10:50 PM > > To: Gump code and data > > Subject: Re: Missing Class for Fulcrum DVSL > > > > > > Just to confirm some things here: > > - test honours jar overrides as it uses maven.dependency.classpath > > - Maven does not introduce any jaxen dependencies normally. However, > > if you are using any plugin:* latka:* pmd:* release:* goals it will be > > introduced. This is an unfortunate side-effect of not having plugin > > classloaders separate - something we desparately want to implement, > > but would break a significant number of builds that have come to > > depend (no pun intended!) on it. > > > > If you run maven with -X you will see what maven.dependency.classpath > > is and whether jaxen has found its way onto there. > > > > I think Maven 1.1 is going to have to take the backwards compat hit > > and separate the classloaders. I've already done the work but not > > committed it. > > > > - Brett > > > > On Tue, 9 Nov 2004 18:55:24 +0100, Eric Pugh > > <[EMAIL PROTECTED]> wrote: > > > Not quite sure where this dependency is coming from. I don't > > believe Maven > > > is introducing for me the Jaxen dependency. As the test runs > perfectly > > > without it. Could it be the version of dom4j being used? My > > component is > > > just a wrapper around velocity-dvsl, so it may be somewhere > in there... > > > > > > I'll try and spill out the classpath in the test.. > > > > > > Eric > > > > > > > > > > > > > > > > -Original Message- > > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, November 09, 2004 5:39 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Missing Class for Fulcrum DVSL > > > > > > > > > > > > On Tue, 09 Nov 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 9 Nov 2004, Eric Pugh <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > >> I have inlined the text of the error. The issue is something > > > > >> missing on Jaxen. However, I have in my Gump descriptor (but not > > > > >> in Maven) a dependency on Jaxen. > > > > > > > > > > So how do you compile your code with Maven if you don't > specify the > > > > > dependency at all? Is the version of Jaxen used Maven "helping > > > > > out"? > > > > > > > > should read > > > > > > > > Is the version of Jaxen used by Maven "helping out"? > > > > > > > > Stefan > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump RSS link
> I noticed a link to gump's RSS on http://www.planetapache.org/ (right > hand column under the blogroll), but it was to the lsd instance that > isn't running. Good catch, thanks. > Is the appropriate place to change it to > http://brutus.apache.org/gump/public/rss.xml? Yup, that is a good one. > I think any committer can modify the planet stuff to get that changed > - I'll check it out later when I have access (or if anyone else cares > to do so). I don't think we get to change the "framework", just the contents of the links. Thom May added this link separately for us, as a courtesy, since Gump got "kicked off the main island/planet" (it was too inhuman ;-). Thom, would you mind fixing this for us? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffee local-env-brutus.sh on brutus
On Thu, 11 Nov 2004, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > So, i have added the following 2 lines in > /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh: Great, thanks. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffee local-env-brutus.sh on brutus
Davanum Srinivas wrote: Folks, i was chatting with dalibor about kaffee and gump and ant's bootstrap.sh this morning. He pointed me to his mesage: http:[EMAIL PROTECTED]/2004-11/msg00010.html and the gump failure: http://brutus.apache.org/gump/kaffe/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html So, i have added the following 2 lines in /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh: export JAVAC=jikes-kaffe export ANT_OPTS="-Dbuild.compiler=jikes -Djavac.source=1.3" awesome! sorry for not having being able to do that myself (I'm really swamped these days) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
kaffee local-env-brutus.sh on brutus
Folks, i was chatting with dalibor about kaffee and gump and ant's bootstrap.sh this morning. He pointed me to his mesage: http:[EMAIL PROTECTED]/2004-11/msg00010.html and the gump failure: http://brutus.apache.org/gump/kaffe/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html So, i have added the following 2 lines in /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh: export JAVAC=jikes-kaffe export ANT_OPTS="-Dbuild.compiler=jikes -Djavac.source=1.3" Thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed
On Tue, 9 Nov 2004 17:08:36 +, sebb <[EMAIL PROTECTED]> wrote: > On Tue, 09 Nov 2004 10:33:26 -0500, Stefano Mazzocchi > > > <[EMAIL PROTECTED]> wrote: > > Stefan Bodewig wrote: > > > > > > > On Mon, 08 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > > > > > > > >>Geoff Howard wrote: > > > > > > > > >>>I find it hard to believe the jms spec has changed, though I > > >>>suppose this is possible. > > > > > > > > > Which version does geronimo-* implement? Maybe it is a change between > > > 1.0.2 (the version of JMS we had before Niclas changed it to the > > > geronimo version) and 1.1 - which seems to be the current version. > > > > > > Any reason we use Geronimo snapshots instead of the "official" Sun > > > jars, BTW? > > > > no really. We shipt it with geronimo's and that compiles so I thought > > that was going to be better, but nope. > > > > If we identified there is a API change between 1.0.2 and 1.1, I'd rather > > have cocoon update to the latest JMS API rather than having to different > > packages in gump since it seems that cocoon is the only one having that > > problem anyway. > > Not quite - JMeter is also failing to find JMS, but as it's optional, > no error is generated. > > See: > > http://brutus.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter/gump_work/build_jakarta-jmeter_jakarta-jmeter.html > > ... > > /usr/local/gump/packages/jms1.0.2/lib/jms.jar ... > > ... > > jms-message: > [echo] Classes for JMS support not found in classpath > > I don't understand why the JMS jar is not being found - hopefully the > latest JMS might solve this... > Duh! This is a JMeter build.xml issue. Gump builds use a different target in the build file, and set the properties directly, rather than checking for a class name ... > > > > -- > > Stefano. > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Missing Class for Fulcrum DVSL
I have just added jaxen as an explicit maven dependency for DVSL, so hopefully this will solve the issue. We'll see in the next run! I know that fixing the classloaders for plugins will break stuff, but I believe it will be forward compatible right? If I fix a project that was unintentionally depending on the single classloader for all plugins, then it will still run under maven 1.0, as well as maven 1.1? When you get to the point of committing the code, it may be good to put another instance of gump up with a maven 1.1 Release Candidate so we can see who breaks and start fixing them before the official release of 1.1. Again, another good reason for Gump! Eric > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 09, 2004 10:50 PM > To: Gump code and data > Subject: Re: Missing Class for Fulcrum DVSL > > > Just to confirm some things here: > - test honours jar overrides as it uses maven.dependency.classpath > - Maven does not introduce any jaxen dependencies normally. However, > if you are using any plugin:* latka:* pmd:* release:* goals it will be > introduced. This is an unfortunate side-effect of not having plugin > classloaders separate - something we desparately want to implement, > but would break a significant number of builds that have come to > depend (no pun intended!) on it. > > If you run maven with -X you will see what maven.dependency.classpath > is and whether jaxen has found its way onto there. > > I think Maven 1.1 is going to have to take the backwards compat hit > and separate the classloaders. I've already done the work but not > committed it. > > - Brett > > On Tue, 9 Nov 2004 18:55:24 +0100, Eric Pugh > <[EMAIL PROTECTED]> wrote: > > Not quite sure where this dependency is coming from. I don't > believe Maven > > is introducing for me the Jaxen dependency. As the test runs perfectly > > without it. Could it be the version of dom4j being used? My > component is > > just a wrapper around velocity-dvsl, so it may be somewhere in there... > > > > I'll try and spill out the classpath in the test.. > > > > Eric > > > > > > > > > > > -Original Message- > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, November 09, 2004 5:39 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Missing Class for Fulcrum DVSL > > > > > > > > > On Tue, 09 Nov 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > > On Tue, 9 Nov 2004, Eric Pugh <[EMAIL PROTECTED]> > > > > wrote: > > > > > > >> I have inlined the text of the error. The issue is something > > > >> missing on Jaxen. However, I have in my Gump descriptor (but not > > > >> in Maven) a dependency on Jaxen. > > > > > > > > So how do you compile your code with Maven if you don't specify the > > > > dependency at all? Is the version of Jaxen used Maven "helping > > > > out"? > > > > > > should read > > > > > > Is the version of Jaxen used by Maven "helping out"? > > > > > > Stefan > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
