You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@apache.org> on 2004/12/03 04:32:49 UTC

Hello Gump

Howdy folks,

Long time no speak! (I've been unexpectedly buried helping my wife w/ her
start-up, learning DotNet). I've missed you. I've missed Gump. I'm going try
hard to get back online here. Give me pointers as to where I ought focus my
energies.

regards

Adam
--
Have you Gumped your code today?
http://gump.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by Stefano Mazzocchi <st...@apache.org>.
Davanum Srinivas wrote:
> xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
> built-in is my guess.

ohhhh, yeah, that would explain it. I think xerces is missing a 
dependency on xml-commons! weird that we never found out in all this 
time ;-)

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> Do we need per "environment" dependency settings, or do we just work to
> the lowest common denominator? Ought we try to test against latest classes
> and not rely upon what is in the JDK, or optimally would we want "both"?

I rather strongly feel opposed to have per-workspace dependency settings.

The whole point of a virtual machine is that everything should work 
exactly the same.

This means that even if the JDK ships with the xml resolver, I think 
that xerces should depend on it even in sun's JDK builds. Not only this 
would fix Kaffe, but it would also allow xerces to know if xml-commons 
changes their contracts, in perfect gump style.

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
OOOPS!!! made a typo in brutus.xml - forgot a double-quote. starting
gump by hand.

-- dims


On Sat, 4 Dec 2004 16:34:25 -0500, Davanum Srinivas <da...@gmail.com> wrote:
> oops...i updated brutus.xml as ANT_OPTS is not really picked up.
> 
> Added:
>         <sysproperty name="jikes.class.path"
> value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar"/>
> 
> Thanks,
> dims
> 
> PS: Can we run kaffe at least one more time every day till we sort things out?
> 
> 
> 
> On Sat, 4 Dec 2004 16:10:27 -0500, Davanum Srinivas <da...@gmail.com> wrote:
> > I added a resolver.jar in
> > /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh...let's see if it
> > works tonight and then decide what to do next.
> >
> > thanks,
> > dims
> >
> >
> >
> > On Sat, 4 Dec 2004 13:03:20 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> > >
> > > > xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
> > > > built-in is my guess.
> > >
> > > Ok, I see an xml-resolver project in the xml-commons. Do we need to tweak
> > > it's dependencies so xml-xerces can rely upon it, not vica-versa?
> > >
> > > BTW: Do we need per "environment" dependency settings, or do we just work to
> > > the lowest common denominator? Ought we try to test against latest classes
> > > and not rely upon what is in the JDK, or optimally would we want "both"?
> > >
> > > regards,
> > >
> > > Adam
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Sam Ruby <ru...@intertwingly.net>.
Stefano Mazzocchi wrote:

> Davanum Srinivas wrote:
> 
>> Stefano,
>>
>> i think i poked through all the jars in JDK 1.4 and did not find
>> it...hence the question.
> 
> Found it!!!
> 
> The problem is in the XJavac task that Xerces2 uses to compile stuff 
> (probably it's a left-over workaround from an ant bug on the javac task).
> 
> Now, not only I can't find the sourcecode of that sucker

http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/tools/src/XJavac.java?view=markup
http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/tools/bin/xjavac.jar?rev=1.6&view=log

- Sam Ruby



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
YIKES!!!!!!!!!!!

-- dims


On Sun, 05 Dec 2004 18:54:58 -0500, Stefano Mazzocchi
<st...@apache.org> wrote:
> Davanum Srinivas wrote:
> > Stefano,
> >
> > i think i poked through all the jars in JDK 1.4 and did not find
> > it...hence the question.
> 
> Found it!!!
> 
> The problem is in the XJavac task that Xerces2 uses to compile stuff
> (probably it's a left-over workaround from an ant bug on the javac task).
> 
> Now, not only I can't find the sourcecode of that sucker (I had to
> decompile it with jad (find it attached) but here is the offending part:
> 
>   String s = ((String) properties.get( "java.vendor" )).toUpperCase(
> Locale.ENGLISH );
>   if(s.indexOf("IBM") >= 0)
>   {
>                // create an IBM-specific classpath
>   }
>   else if(s.indexOf("SUN") >= 0 ||
>           s.indexOf("BLACKDOWN") >= 0 ||
>           s.indexOf("APPLE") >= 0)
>   {
>            // build the regular classpath
>   }
> 
> note how the classpath *IS*NOT*BUILT* if neither of the above match!
> 
> I would strongly lobby with the xerces people to get rid of that silly task.
> 
> --
> Stefano.
> 
> 
> // Decompiled by Jad v1.5.8c. Copyright 2001 Pavel Kouznetsov.
> // Jad home page: http://www.geocities.com/kpdus/jad.html
> // Decompiler options: packimports(3)
> // Source File Name:   XJavac.java
> 
> package org.apache.xerces.util;
> 
> import java.util.Hashtable;
> import java.util.Locale;
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.taskdefs.Javac;
> import org.apache.tools.ant.types.Path;
> import org.apache.tools.ant.util.JavaEnvUtils;
> 
> public class XJavac extends Javac
> {
> 
>     public XJavac()
>     {
>     }
> 
>     public void execute()
>         throws BuildException
>     {
>         if(isJDK14OrHigher())
>         {
>             java.util.Properties properties = null;
>             try
>             {
>                 properties = System.getProperties();
>             }
>             catch(Exception exception)
>             {
>                 throw new BuildException("unable to determine java vendor because could not access system properties!");
>             }
>             String s = ((String)properties.get("java.vendor")).toUpperCase(Locale.ENGLISH);
>             if(s.indexOf("IBM") >= 0)
>             {
>                 Path path = createBootclasspath();
>                 String s1 = System.getProperty("java.home");
>                 StringBuffer stringbuffer = new StringBuffer();
>                 stringbuffer.append(s1).append("/lib/charsets.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/core.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/graphics.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/javaws.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/jaws.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/security.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/server.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/JawBridge.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/gskikm.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/ibmjceprovider.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/indicim.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/jaccess.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/ldapsec.jar:");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 stringbuffer.replace(s1.length(), stringbuffer.length(), "/lib/ext/oldcertpath.jar");
>                 path.createPathElement().setPath(stringbuffer.toString());
>                 setBootclasspath(path);
>             } else
>             if(s.indexOf("SUN") >= 0 || s.indexOf("BLACKDOWN") >= 0 || s.indexOf("APPLE") >= 0)
>             {
>                 Path path1 = createBootclasspath();
>                 Path path2 = getClasspath();
>                 path1.append(path2);
>                 String s2 = (String)properties.get("sun.boot.class.path");
>                 Path path3 = new Path(null);
>                 path3.createPathElement().setPath(s2);
>                 path1.append(path3);
>                 setBootclasspath(path1);
>             }
>         }
>         super.execute();
>     }
> 
>     private boolean isJDK14OrHigher()
>     {
>         String s = JavaEnvUtils.getJavaVersion();
>         return s.equals("1.4") || !s.equals("1.3") && !s.equals("1.2") && !s.equals("1.1") && !s.equals("1.0");
>     }
> }
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Stefano Mazzocchi <st...@apache.org>.
Davanum Srinivas wrote:
> Stefano,
> 
> i think i poked through all the jars in JDK 1.4 and did not find
> it...hence the question.

Found it!!!

The problem is in the XJavac task that Xerces2 uses to compile stuff 
(probably it's a left-over workaround from an ant bug on the javac task).

Now, not only I can't find the sourcecode of that sucker (I had to 
decompile it with jad (find it attached) but here is the offending part:

  String s = ((String) properties.get( "java.vendor" )).toUpperCase( 
Locale.ENGLISH );
  if(s.indexOf("IBM") >= 0)
  {
               // create an IBM-specific classpath
  }
  else if(s.indexOf("SUN") >= 0 ||
          s.indexOf("BLACKDOWN") >= 0 ||
          s.indexOf("APPLE") >= 0)
  {
           // build the regular classpath
  }

note how the classpath *IS*NOT*BUILT* if neither of the above match!

I would strongly lobby with the xerces people to get rid of that silly task.

-- 
Stefano.


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
Stefano,

i think i poked through all the jars in JDK 1.4 and did not find
it...hence the question.

-- dims


On Sun, 05 Dec 2004 12:40:03 -0500, Stefano Mazzocchi
<st...@apache.org> wrote:
> Davanum Srinivas wrote:
> > My Question is: WHY is JDK1.4 succeding? Haven't found the answer yet.
> 
> JDK 1.4 contains resolver.jar while Kaffe does not. We never noticed
> that xerces dependeded on that library before because it always fall
> back into the system classloader.
> 
> Adding the explicit dependency should take care of both (and also, as I
> said) allow for xerces to fail in case xml-commons changes contracts
> (unlikely, but you never know).
> 
> --
> Stefano.
> 
> ---------------------------------------------------------------------
> 
> 
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 05 Dec 2004, Stefano Mazzocchi <st...@apache.org> wrote:

> We never noticed that xerces dependeded on that library before

This is not really true.  We once had a Gump build that broke because
Xerces-J required xml-resolver about two weeks ago.  And on the next
build everything succeeded.  I thought they had removed the
dependency, while in reality they patched xjavac 8-(

+1 for adding a dependency on resolver to xerces while making resolver
depend on jaxp instead of xerces.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Stefano Mazzocchi <st...@apache.org>.
Davanum Srinivas wrote:
> My Question is: WHY is JDK1.4 succeding? Haven't found the answer yet.

JDK 1.4 contains resolver.jar while Kaffe does not. We never noticed 
that xerces dependeded on that library before because it always fall 
back into the system classloader.

Adding the explicit dependency should take care of both (and also, as I 
said) allow for xerces to fail in case xml-commons changes contracts 
(unlikely, but you never know).

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
My Question is: WHY is JDK1.4 succeding? Haven't found the answer yet.

-- dims


On Sun, 05 Dec 2004 19:13:03 +1100, David Crossley <cr...@apache.org> wrote:
> Stefano Mazzocchi wrote:
> > Davanum Srinivas wrote:
> >
> >> oops...i updated brutus.xml as ANT_OPTS is not really picked up.
> >>
> >> Added:
> >>         <sysproperty name="jikes.class.path"
> >> value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar"/>
> >
> > Anybody against removing this and adding a dependency on
> > xml-commons/resolver from xml-xerces2?
> 
> I wondered from the beginning of this thread if
> that might be what is needed. I checked the
> 'cvs log' for that resolver.jar and it is the
> "xml commons" version.
> 
> --David
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by David Crossley <cr...@apache.org>.
Stefano Mazzocchi wrote:
> Davanum Srinivas wrote:
> 
>> oops...i updated brutus.xml as ANT_OPTS is not really picked up.
>>
>> Added:
>>         <sysproperty name="jikes.class.path"
>> value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar"/> 
> 
> Anybody against removing this and adding a dependency on 
> xml-commons/resolver from xml-xerces2?

I wondered from the beginning of this thread if
that might be what is needed. I checked the
'cvs log' for that resolver.jar and it is the
"xml commons" version.

--David



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Stefano Mazzocchi <st...@apache.org>.
Davanum Srinivas wrote:
> oops...i updated brutus.xml as ANT_OPTS is not really picked up.
> 
> Added:
>         <sysproperty name="jikes.class.path"
> value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar"/>

Anybody against removing this and adding a dependency on 
xml-commons/resolver from xml-xerces2?

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
Thanks Adam.


On Sat, 4 Dec 2004 15:01:53 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> > PS: Can we run kaffe at least one more time every day till we sort things
> out?
> 
> Done.
> 
> [gump@brutus] ~ $ crontab -l | grep -i kaf
> # Kaffe - This Gump runs on top of Kaffe and uses the 'live' branch
> 0 8,18 * * *      cd /usr/local/gump/kaffe/gump/cron; /bin/bash gump.sh all
> 
> regards
> 
> Adam
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by "Adam R. B. Jack" <aj...@apache.org>.
> PS: Can we run kaffe at least one more time every day till we sort things
out?

Done.

[gump@brutus] ~ $ crontab -l | grep -i kaf
# Kaffe - This Gump runs on top of Kaffe and uses the 'live' branch
0 8,18 * * *      cd /usr/local/gump/kaffe/gump/cron; /bin/bash gump.sh all

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
oops...i updated brutus.xml as ANT_OPTS is not really picked up.

Added:
        <sysproperty name="jikes.class.path"
value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar"/>

Thanks,
dims

PS: Can we run kaffe at least one more time every day till we sort things out?

On Sat, 4 Dec 2004 16:10:27 -0500, Davanum Srinivas <da...@gmail.com> wrote:
> I added a resolver.jar in
> /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh...let's see if it
> works tonight and then decide what to do next.
> 
> thanks,
> dims
> 
> 
> 
> On Sat, 4 Dec 2004 13:03:20 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> >
> > > xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
> > > built-in is my guess.
> >
> > Ok, I see an xml-resolver project in the xml-commons. Do we need to tweak
> > it's dependencies so xml-xerces can rely upon it, not vica-versa?
> >
> > BTW: Do we need per "environment" dependency settings, or do we just work to
> > the lowest common denominator? Ought we try to test against latest classes
> > and not rely upon what is in the JDK, or optimally would we want "both"?
> >
> > regards,
> >
> > Adam
> >
> >
> 
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by Davanum Srinivas <da...@gmail.com>.
I added a resolver.jar in
/usr/local/gump/kaffe/gump/cron/local-env-brutus.sh...let's see if it
works tonight and then decide what to do next.

thanks,
dims

On Sat, 4 Dec 2004 13:03:20 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> 
> > xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
> > built-in is my guess.
> 
> Ok, I see an xml-resolver project in the xml-commons. Do we need to tweak
> it's dependencies so xml-xerces can rely upon it, not vica-versa?
> 
> BTW: Do we need per "environment" dependency settings, or do we just work to
> the lowest common denominator? Ought we try to test against latest classes
> and not rely upon what is in the JDK, or optimally would we want "both"?
> 
> regards,
> 
> Adam
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


XML Resolver for Xerces on Kaffe was Re: Hello Gump)

Posted by "Adam R. B. Jack" <aj...@apache.org>.
> xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
> built-in is my guess.

Ok, I see an xml-resolver project in the xml-commons. Do we need to tweak
it's dependencies so xml-xerces can rely upon it, not vica-versa?

BTW: Do we need per "environment" dependency settings, or do we just work to
the lowest common denominator? Ought we try to test against latest classes
and not rely upon what is in the JDK, or optimally would we want "both"?

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by Davanum Srinivas <da...@gmail.com>.
xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes
built-in is my guess.

-- dims


On Fri, 3 Dec 2004 16:58:33 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> 
> > I need help with the Kaffe gump run...it's stuck in xml-xerces
> >
> (http://brutus.apache.org/gump/kaffe/xml-xerces2/xml-xerces/gump_work/build_
> xml-xerces2_xml-xerces.html)
> >
> 
> I'm somewhat out of my area here, but (and stating the hopefully obvious) it
> looks like a bunch of warning, and four import errors that go on to cause
> the rest:
> 
> [xjavac]     44. import org.apache.xml.resolver.Catalog;
>    [xjavac]                ^-----------------------------^
>    [xjavac] *** Semantic Error: The import "org/apache/xml/resolver/Catalog"
> is not valid, since it does not name a type in a package.
> 
> I believe this is Kaffe's version of "Not Found" (although I couldn't find,
> via Google, that documented).
> 
> I can't seem to find them either, not in this source tree, only the
> reference to them.
> 
> [gump@brutus] ~/workspaces2/kaffe/workspace/xml-xerces2 $ find  .  -name
> '*.java' -exec grep org.apache.xml.resolver {} \; -print
> import org.apache.xml.resolver.Catalog;
> import org.apache.xml.resolver.CatalogManager;
> import org.apache.xml.resolver.readers.OASISXMLCatalogReader;
> import org.apache.xml.resolver.readers.SAXCatalogReader;
> 
> fResolverCatalogManager.setCatalogClassName("org.apache.xml.resolver.Catalog
> ");
>             "org.apache.xml.resolver.readers.OASISXMLCatalogReader");
> ./java/src/org/apache/xerces/util/XMLCatalogResolver.java
> 
> Where are they meant to come from?
> 
> regards,
> 
> Adam
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by "Adam R. B. Jack" <aj...@apache.org>.
> I need help with the Kaffe gump run...it's stuck in xml-xerces
>
(http://brutus.apache.org/gump/kaffe/xml-xerces2/xml-xerces/gump_work/build_
xml-xerces2_xml-xerces.html)
>

I'm somewhat out of my area here, but (and stating the hopefully obvious) it
looks like a bunch of warning, and four import errors that go on to cause
the rest:

[xjavac]     44. import org.apache.xml.resolver.Catalog;
   [xjavac]                ^-----------------------------^
   [xjavac] *** Semantic Error: The import "org/apache/xml/resolver/Catalog"
is not valid, since it does not name a type in a package.

I believe this is Kaffe's version of "Not Found" (although I couldn't find,
via Google, that documented).

I can't seem to find them either, not in this source tree, only the
reference to them.

[gump@brutus] ~/workspaces2/kaffe/workspace/xml-xerces2 $ find  .  -name
'*.java' -exec grep org.apache.xml.resolver {} \; -print
import org.apache.xml.resolver.Catalog;
import org.apache.xml.resolver.CatalogManager;
import org.apache.xml.resolver.readers.OASISXMLCatalogReader;
import org.apache.xml.resolver.readers.SAXCatalogReader;

fResolverCatalogManager.setCatalogClassName("org.apache.xml.resolver.Catalog
");
            "org.apache.xml.resolver.readers.OASISXMLCatalogReader");
./java/src/org/apache/xerces/util/XMLCatalogResolver.java

Where are they meant to come from?

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by Davanum Srinivas <da...@gmail.com>.
I need help with the Kaffe gump run...it's stuck in xml-xerces
(http://brutus.apache.org/gump/kaffe/xml-xerces2/xml-xerces/gump_work/build_xml-xerces2_xml-xerces.html)

thanks,
dims


On Thu, 2 Dec 2004 20:32:49 -0700, Adam R. B. Jack <aj...@apache.org> wrote:
> Howdy folks,
> 
> Long time no speak! (I've been unexpectedly buried helping my wife w/ her
> start-up, learning DotNet). I've missed you. I've missed Gump. I'm going try
> hard to get back online here. Give me pointers as to where I ought focus my
> energies.
> 
> regards
> 
> Adam
> --
> Have you Gumped your code today?
> http://gump.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by "Adam R. B. Jack" <aj...@apache.org>.

> The behavior is as you specified, if the build fails the first time due to
a
> prereq you get a notice, after that you don't until  the build passes.
> However, when a basic prereq like commons-lang or ant or xml parser
failes,
> and then fixes, it causes a storm of spam messages.   On the turbine dev
> list, if this happens we get 20 emails, one per fulcurm component.  Which
is
> very annoying and causes people just to filter gump messages.
>
> At least in the fulcurm case, we don't care if a prereq failed and then
> successed..  We do care ONLY when we succeed/fail.

I don't understand why this is happening, 'cos it was never intended to. I
say we stop "success notifications" (reverting just to failure
notifications) until we figure it out; the good will of one success is not
worth the bad of spam. I'll commit that now, and work on fixing it as I get
time.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


RE: Hello Gump

Posted by Eric Pugh <ep...@opensourceconnections.com>.
The behavior is as you specified, if the build fails the first time due to a
prereq you get a notice, after that you don't until  the build passes.
However, when a basic prereq like commons-lang or ant or xml parser failes,
and then fixes, it causes a storm of spam messages.   On the turbine dev
list, if this happens we get 20 emails, one per fulcurm component.  Which is
very annoying and causes people just to filter gump messages.

At least in the fulcurm case, we don't care if a prereq failed and then
successed..  We do care ONLY when we succeed/fail.

> -----Original Message-----
> From: Adam R. B. Jack [mailto:ajack@apache.org]
> Sent: Saturday, December 04, 2004 10:22 PM
> To: Gump code and data
> Subject: Re: Hello Gump
>
>
>
> > When a project is not built because one of the dependencies didn't build
> > and then gets build again because the dependency solved its problems,
> > the project receives an email that is has no longer a problem.
> >
> > We have concensus to feel that this is annoying and the projects should
> > be made aware of their change in status *only* when they fix their own
> > problems, not when people down the road does.
> >
> > Either we solve this, or we stop sending email until we figure out a
> > better way because this is harming our ability to make gump
> appear useful.
> >
> > WDYT?
>
> I think it'd bug me too. ;-)
>
> That said, I thought this code would've taken care of that.
>
> In actor/notify/logic.py we have:
>
>     elif entity.isSuccess():
>         #
>         # Notify on first success, after a failure.
>         #
>         if (stats.sequenceInState == 1):
>             if not STATE_PREREQ_FAILED == stats.previousState:
>                 if stats.getTotalRuns() > 1:
>
> notification=gump.actor.notify.notification.SuccessNotification(se
> lf.run,ent
> ity)
>
> So -- I'm missing something. If they failed to build due to pre-requisite
> failure they ought not get the notification. Maybe I broke
> something when I
> hacked in attempting to build from repository (previously built
> artifacts).
> I'll look into is ASAP.
>
> BTW: We really need your historical database, so we can query not
> hack. :-)
>
> regards,
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by "Adam R. B. Jack" <aj...@apache.org>.
> When a project is not built because one of the dependencies didn't build
> and then gets build again because the dependency solved its problems,
> the project receives an email that is has no longer a problem.
>
> We have concensus to feel that this is annoying and the projects should
> be made aware of their change in status *only* when they fix their own
> problems, not when people down the road does.
>
> Either we solve this, or we stop sending email until we figure out a
> better way because this is harming our ability to make gump appear useful.
>
> WDYT?

I think it'd bug me too. ;-)

That said, I thought this code would've taken care of that.

In actor/notify/logic.py we have:

    elif entity.isSuccess():
        #
        # Notify on first success, after a failure.
        #
        if (stats.sequenceInState == 1):
            if not STATE_PREREQ_FAILED == stats.previousState:
                if stats.getTotalRuns() > 1:

notification=gump.actor.notify.notification.SuccessNotification(self.run,ent
ity)

So -- I'm missing something. If they failed to build due to pre-requisite
failure they ought not get the notification. Maybe I broke something when I
hacked in attempting to build from repository (previously built artifacts).
I'll look into is ASAP.

BTW: We really need your historical database, so we can query not hack. :-)

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Hello Gump

Posted by Stefano Mazzocchi <st...@apache.org>.
Adam R. B. Jack wrote:
> Howdy folks,
> 
> Long time no speak! (I've been unexpectedly buried helping my wife w/ her
> start-up, learning DotNet). I've missed you. I've missed Gump. I'm going try
> hard to get back online here. Give me pointers as to where I ought focus my
> energies.

yey! we were beginning to feel lonely here withyou you, Adam :-)

There is one top priority bug that is being bugging people a lot.

When a project is not built because one of the dependencies didn't build 
and then gets build again because the dependency solved its problems, 
the project receives an email that is has no longer a problem.

We have concensus to feel that this is annoying and the projects should 
be made aware of their change in status *only* when they fix their own 
problems, not when people down the road does.

Either we solve this, or we stop sending email until we figure out a 
better way because this is harming our ability to make gump appear useful.

WDYT?

-- 
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org