Re: What do we do with "beanutils"?

2004-11-09 Thread robert burrell donkin
On 8 Nov 2004, at 23:58, Brett Porter wrote:
I've been meaning to reply to this in kind.
If a project splits itself into three, should gump really try and map
projects depending on an older version to these? I know you are
experimenting with the latest and greatest, but this might be the
point where you start maintaining beanutils-1.6.x and
beanutils-*-1.7.x in gump and projects can migrate on their own (gump
could encourage those left on the old one to do so, but not require it
to keep running).
this was discussed at the time and the consensus was that the right 
thing for gump to do was to move everyone onto the new jar's. (unless 
i've missed something) gump's always aimed at bringing the latest and 
greatest code together.

a primary reason why beanutils was split into a modular jar system was 
so that gump (and anyone else trying to use the latest versions) would 
not run into difficulties with the two incompatible series of commons 
collections releases. at the time, it seemed best to migrate all 
projects (rather than having rely on nagging messages) and i think that 
this decision has been proved right.

i suppose that the bigger issue is who owns the gump descriptors: the 
individual projects or gump...

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Problems running gump (both trunk and live)

2004-11-09 Thread Gareth Webbley
Hi Peter,

I have had the same problem.  When executing a command the gump.py in the root 
directory (of gump) creates a list and passes that as the options to the 
command.  However the command is not expecting a list.

The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.

HTH

Gareth Webbley


On Monday 08 November 2004 02:41, Peter Janes wrote:
> I've recently synced both the trunk and live branch of Gump (which are
> identical as of revision 56892) and have a problem running both of them. 
> If I
>
> execute "python2.3 gump.py build" I get the following traceback:
> > Traceback (most recent call last):
> >   File "gump.py", line 118, in ?
> > main(sys.argv)
> >   File "gump.py", line 108, in main
> > getattr(command, "process")(options,arguments)
> >   File
> > "/home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build
> >.py", line 41, in process workspace =
> > WorkspaceLoader(options.isCache()).load(ws)
> > AttributeError: 'list' object has no attribute 'isCache'
>
> I think it's a scope problem--gump.core.run.options is imported, but the
> process() method takes an argument named "options"--but I'm at a loss to
> explain why my version doesn't run and the Apache one does.  Any takers?
>
> Also, I notice that http://gump.apache.org/gettingstarted.html directs new
> users to check out the trunk (i.e. potentially unstable) version instead of
> the "live" branch.  Would it be more appropriate to send them to "live"
> instead?
>
> Thanks,
> Peter J.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

2004-11-09 Thread Stefan Bodewig
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?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



jvmarg gets ignored

2004-11-09 Thread Stefan Bodewig
Hi,

since nagoya is down I post it here before I forget about it.

If you look at the ant-xdocs-proposal build output you'll see no sign
of -Xmx512m even though it should be there.

My limited understanding leads me to think that the reason is this
code in project.py (line 546 in revision 57013)

for jvmarg in self.getDomChildIterator('jvmarg'):

which - I think - iterates over the children of , not 
or .

I'm a bit unsure about how we want to fix it.

Maybe this really is more a property of the project and not the
builder and thus we should modify the DTD, the docs and the
descriptors to follow the code?

Or should the code iterate over ant/jvmarg and maven/jvmarg instead?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



forrest.xml doesn't validate

2004-11-09 Thread Leo Simons
Hi gang,
./validate says today:
  Processing Local Projects 
./tmp/./project/forrest.xml:33: element project: validity error : No 
declaration for attribute basedir of element project
  
^
./tmp/./project/forrest.xml:62: element project: validity error : No 
declaration for attribute basedir of element project
  
   ^
./tmp/./project/forrest.xml:73: element project: validity error : No 
declaration for attribute basedir of element project
  

^
./tmp/./project/forrest.xml:89: element project: validity error : No 
declaration for attribute basedir of element project
ct name="forrest-whiteboard-forrestdoc-autotest" 
basedir="whiteboard/forrestdoc"

^
---
Now, I have no real idea what validate is or how it works, but this is 
probably a bad thing...

cheers,
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Missing Class for Fulcrum DVSL

2004-11-09 Thread Eric Pugh
Well,

The second to last build issue for Fulcrum concerns Fulcrum DVSL Impl.
Everything builds nicely, but the unit test is failing:

http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-dvsl-im
pl/gump_work/build_jakarta-turbine-fulcrum_fulcrum-dvsl-impl.html

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.

I notice in the jaxen.xml project file there are two different ones.  A
packaged with dom4j and a standalone.  Do I maybe want the packaged with
dom4j?

I went and checked, and org.jaxen.JaxenException is still part of CVS HEAD
for jaxen...

ERic


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problems running gump (both trunk and live)

2004-11-09 Thread Peter Janes
Gareth Webbley wrote:
The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.
That seems to do it, thanks.
Oddly, the "getting started" page gives instructions on installing and 
configuring Gump, but stops just short of actually *running* it. :)

--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problems running gump (both trunk and live)

2004-11-09 Thread Stefano Mazzocchi
Gareth Webbley wrote:
Hi Peter,
I have had the same problem.  When executing a command the gump.py in the root 
directory (of gump) creates a list and passes that as the options to the 
command.  However the command is not expecting a list.

The way I got around this problem was to cd to the cron directory and either 
run gump.sh in that directory or python gump.py.  There is another copy of 
gump.py in the cron directory which works differently to the one in the root 
directory.  I think this is the one used in the official runs.
correct!
the official gump runs with the cron/gump.sh script.
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.

The internals of gump have not being changed (in fact it works as 
before) but my user-friendly CLI work is not finished and I was 
sidetracked by my day job + work on dynagump.

I'll get back to that soon since I now have dynagump in a state where I 
need gump to start populating the relational database for real.

So, for now, use the cron script or you can help me out and fix the 
bugs :-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

2004-11-09 Thread Stefano Mazzocchi
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.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problems running gump (both trunk and live)

2004-11-09 Thread Stefano Mazzocchi
Peter Janes wrote:
Gareth Webbley wrote:
The way I got around this problem was to cd to the cron directory and 
either run gump.sh in that directory or python gump.py.  There is 
another copy of gump.py in the cron directory which works differently 
to the one in the root directory.  I think this is the one used in the 
official runs.

That seems to do it, thanks.
Oddly, the "getting started" page gives instructions on installing and 
configuring Gump, but stops just short of actually *running* it. :)
I know, it's confusing as hell and I'm totally sorry for you I went thru 
the same pain.

we'll fix this soon.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

2004-11-09 Thread Stefan Bodewig
On Tue, 09 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

> 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.

Looks like Cocoon was using JMS 1.1, but we only provided 1.0.2:

>[javac] 
> /home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:217:
>  cannot resolve symbol
>[javac] symbol  : method createConnection 
> (java.lang.String,java.lang.String)
>[javac] location: interface javax.jms.ConnectionFactory
>[javac] return 
> factory.createConnection(cc.getUserName(), cc.getPassword());
>[javac]   ^

Is here



>[javac] 
> /home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:231:
>  cannot resolve symbol
>[javac] symbol  : method createConnection ()
>[javac] location: interface javax.jms.ConnectionFactory
>[javac] return factory.createConnection();
>[javac]   ^

Is here



The J2EE 1.3 version

looks like a marker interface.

JMS 1.1 is on the way to my disk (and to brutus after that).

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

2004-11-09 Thread Stefano Mazzocchi
Stefan Bodewig wrote:
On Tue, 09 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

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.

Looks like Cocoon was using JMS 1.1, but we only provided 1.0.2:

  [javac] 
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:217:
 cannot resolve symbol
  [javac] symbol  : method createConnection (java.lang.String,java.lang.String)
  [javac] location: interface javax.jms.ConnectionFactory
  [javac] return factory.createConnection(cc.getUserName(), 
cc.getPassword());
  [javac]   ^

Is here

  [javac] 
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/jms/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java:231:
 cannot resolve symbol
  [javac] symbol  : method createConnection ()
  [javac] location: interface javax.jms.ConnectionFactory
  [javac] return factory.createConnection();
  [javac]   ^

Is here

The J2EE 1.3 version

looks like a marker interface.
JMS 1.1 is on the way to my disk (and to brutus after that).
awesome! thanks :-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: cvs commit: gump/profile gump.xml

2004-11-09 Thread Stefan Bodewig
On 9 Nov 2004, <[EMAIL PROTECTED]> wrote:

>   Upgrade to JMS 1.1

cocoon-block-jms needs to  on jms instead of geronimo-spec-jms
to take advantage of this change.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: gump/profile gump.xml

2004-11-09 Thread Stefano Mazzocchi
Stefan Bodewig wrote:
On 9 Nov 2004, <[EMAIL PROTECTED]> wrote:

 Upgrade to JMS 1.1

cocoon-block-jms needs to  on jms instead of geronimo-spec-jms
to take advantage of this change.
consider it fixed.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Missing Class for Fulcrum DVSL

2004-11-09 Thread Stefan Bodewig
On Tue, 9 Nov 2004, Eric Pugh <[EMAIL PROTECTED]> wrote:

> The second to last build issue for Fulcrum concerns Fulcrum DVSL
> Impl.  Everything builds nicely, but the unit test is failing:

I'm not completely certain that Maven's test plugin (is that the
correct term?) honors jar overrides, so I'm not completely sure which
classpath your tests see.

Could you echo out java.class.path inside of your tests to see what is
going on.

> 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"?
This scares me more than a bit.

> I notice in the jaxen.xml project file there are two different ones.
> A packaged with dom4j and a standalone.  Do I maybe want the
> packaged with dom4j?

This is in order to break a cyclic dependency between jaxen and
dom4j.  The resulting jars should work the same way, but only "jaxen"
has been compiled against the same dom4j version you use, so you
probably want to use that.

> I went and checked, and org.jaxen.JaxenException is still part of
> CVS HEAD for jaxen...

IIRC it has changed its parent class, though.  Saxpath moved around a
bit.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Missing Class for Fulcrum DVSL

2004-11-09 Thread Stefan Bodewig
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]



Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

2004-11-09 Thread sebb
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...

> 
> --
> Stefano.
> 
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: gump/project lenya.xml

2004-11-09 Thread Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
bodewig 2004/11/09 09:10:42
  Modified:project  lenya.xml
  Log:
  This is a very strange way to ship tasks IMHO
  
  Revision  ChangesPath
  1.5   +2 -1  gump/project/lenya.xml
  
  Index: lenya.xml
  ===
  RCS file: /home/cvs/gump/project/lenya.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- lenya.xml	4 Nov 2004 00:31:30 -	1.4
  +++ lenya.xml	9 Nov 2004 17:10:42 -	1.5
  @@ -42,6 +42,7 @@
   
   
   
  +
   
   
   
just curious, what would be a better way? lenya copied it from cocoon, I 
think.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: cvs commit: gump/project lenya.xml

2004-11-09 Thread Stefan Bodewig
On Tue, 09 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:

>>   This is a very strange way to ship tasks IMHO
> 
> just curious, what would be a better way? lenya copied it from
> cocoon, I think.

Have cocoon build it and provide it as a jar.  Something like a
cocoon-xconftool project that both cocoon and lenya depend on.

Shipping a class file in CVS is as good or bad as keeping the jars
there - and I'm in the "no jars in CVS" camp.  No religious debate,
please.

Things may be even worse for class files if nobody knows about their
origin.  class files for classes in the default package are probably
the worst of all.

Cheers

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: gump/project lenya.xml

2004-11-09 Thread Stefano Mazzocchi
Stefan Bodewig wrote:
On Tue, 09 Nov 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:

 This is a very strange way to ship tasks IMHO
just curious, what would be a better way? lenya copied it from
cocoon, I think.

Have cocoon build it and provide it as a jar.  Something like a
cocoon-xconftool project that both cocoon and lenya depend on.
Shipping a class file in CVS is as good or bad as keeping the jars
there - and I'm in the "no jars in CVS" camp.  No religious debate,
please.
Things may be even worse for class files if nobody knows about their
origin.  class files for classes in the default package are probably
the worst of all.
fair enough, was just curious.
I agree that how lenya build is a little bit fucked up but there are 
more important things to be concerned about ATM.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


RE: Missing Class for Fulcrum DVSL

2004-11-09 Thread Eric Pugh
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]



Re: Problems running gump (both trunk and live)

2004-11-09 Thread Peter Janes
Stefano Mazzocchi wrote:
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.
[...]
So, for now, use the cron script or you can help me out and fix the 
bugs :-)
Love to, but I think I've exhausted my Python knowledge.  If I get a chance 
I'll submit a patch for the getting started page though. :)
--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problems running gump (both trunk and live)

2004-11-09 Thread Stefano Mazzocchi
Peter Janes wrote:
Stefano Mazzocchi wrote:
The status of the gump.py file in the root is *up in the air* at best 
and totally untested for a lot of things. In short, it's a mess.
[...]
So, for now, use the cron script or you can help me out and fix 
the bugs :-)

Love to, but I think I've exhausted my Python knowledge.  If I get a 
chance I'll submit a patch for the getting started page though. :)
the wiki awaits you :-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Missing Class for Fulcrum DVSL

2004-11-09 Thread Brett Porter
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]



Re: forrest.xml doesn't validate

2004-11-09 Thread David Crossley
Leo Simons wrote:
> Hi gang,
> 
> ./validate says today:

This did used to validate recently. I see from the
commit history that various people have since been
making changes but not using the 'validate' script.

I just moved the "basedir" attribute from the "project"
elements to the "ant" elements. Not sure if that is correct.

Would someone please help us to sort out the mess.

--David

>    Processing Local Projects 
> ./tmp/./project/forrest.xml:33: element project: validity error : No 
> declaration for attribute basedir of element project
>
>  ^
> ./tmp/./project/forrest.xml:62: element project: validity error : No 
> declaration for attribute basedir of element project
>
> ^
> ./tmp/./project/forrest.xml:73: element project: validity error : No 
> declaration for attribute basedir of element project
> basedir="whiteboard/forrestdoc">
>  
>  ^
> ./tmp/./project/forrest.xml:89: element project: validity error : No 
> declaration for attribute basedir of element project
> ct name="forrest-whiteboard-forrestdoc-autotest" 
> basedir="whiteboard/forrestdoc"
>  
>  ^
> 
> 
> ---
> Now, I have no real idea what validate is or how it works, but this is 
> probably a bad thing...
> 
> cheers,
> 
> - Leo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]