Results of big commits

[Mark Hindess <ma...@googlemail.com>]

As well as the new classes, we have over 2700 tests that's nearly ten
times the number we were running a week ago.  And there are a few more
that need some work.  So if anyone is looking for something to do,
take a look at the excluded tests in the
modules/*/make/common/build.xml files.

I've been doing some application testing on the latest trunk plus the
integration of HARMONY-39 in my workspace.  It's pretty cool.

Tomcat 5.5 (which uses the eclipse compiler rather than requiring a
jdk) now starts up ok.  (I do get an error when it shuts down but I'm
sure we'll get to that.)

I tried axis but it looks like we'll need stubs for a few more classes
before that will work - e.g. java.awt.datatransfer.Transferable and
java/rmi/RemoteException.

It's great to see some really substantial applications running on the
Harmony classes.

Regards,
 Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.

Re: Dr. Strangebuild or: How I learned to stop worrying and love Gump

[Leo Simons <ma...@leosimons.com>]

On Thu, Mar 16, 2006 at 10:07:59AM -0800, Stefano Mazzocchi wrote:
> Gump is the, citing Leo, the "most misunderstood piece of software ever".
<snip/>

Hehehe.

Way back, before the jdk had a gargantuan TCK (this is something I assume),
apache's java hackers would routinely find various bugs in the jdk. Gump is
a tool that helps do this. Previously we've helped the kaffe people to do
much of the same thing (I don't think we have a gump-on-kaffe set up at the
moment unfortunately. I keep trying to convince Dalibor to put in some cycles
to help make it happen). One of the main reasons that Apache Ant works so
well on so many platforms and has a long history of backwards-compatibility
is that its developers make good use of gump.

> WARNING: gump is far from being perfect and a new generation (gump3) has 
> been in the making forever [and this is why both Leo and I got a real 
> day job and stopped working on it]. We also had a summer-of-code student 
> working on the dynamic web application interface for dynagump and 
> continuing that work is in my light-year-long todo list.
> 
> I'm secretly hoping to get this project to make me itch my old gump 
> scars enough to start scratching again.

Yeah, same here. Heh, its one of the reasons I wanted to be involved with
Harmony in the first place.

My other secret hope is that there's some people who really, really need
gump3 and know it (most of the software industry needs it but doesn't know
it) and are gonna pay me to finish the critter (which serves as a nice
itch).

> NOTE: if somebody wants to have access to vmgump (the solaris zone that 
> runs all the code) and help us setup a harmony gump run, that can be 
> easily arranged.

Well, we'd probably have to make said individual a committer first. Heh.
That's also easily arranged I guess :-).

LSD

Dr. Strangebuild or: How I learned to stop worrying and love Gump

[Stefano Mazzocchi <st...@apache.org>]

Mark Hindess wrote:
> Stefano,
> 
> I don't really know much about gump but I'm interested to learn a
> little more about it.

Gump is the, citing Leo, the "most misunderstood piece of software ever".

On the surface, Gump is a nightly build system: it reads a bunch of xml 
files that tell it where the various cvs or svn repositories are, 
fetches them and builds them.

No biggy so far. Projects like Continuum, Tinderbox and probably your 
own build system that you wrote years ago for your own project work like 
this too, with more or less sophistication, with more or less simplicity 
of interaction, with more or less detailed of report, with more or less 
frequency and continuous operation.

Gump does something a little weird here: if project A depends on library 
B version 2.0, gump takes project B (from trunk!), builds that and uses 
that to build A instead of using the version that project A advertises 
it needs.

Normally, it fails.

It's at this point that people start scratching their heads: why would I 
want that? I'll deal with the next version of that library once the time 
comes, why bother now?

Well, Gump was conceived, written and first maintained for years by Sam 
(Ruby) [another one of the mentors of this project, FYI]. Sam described 
it as a "social experiment": Gump is not supposed to tell you if your 
project builds or not, but it's supposed to tell you if *your* changes 
broke somebody that depended on them!

It's supposed to make you want to talk to people on other projects.

In 6 years of operation, we had *2* perfect gump runs. yes, 2, out of 
probably 6(years) * 356(days) * 3(times a day) * 3(machines) * 3(virtual 
machines) runs.

But success stories for Gump are not reaching 100%, but telling project 
A that their apparently harmless single-line API deprecation caused 35% 
of 900 projects to fail! This is the kind of knowledge that no other 
system will be able to emerge for you!

Gump is also written in python, therefore JVM-independent and is used to 
build not only java projects (like APR and HTTPD).

Today gump run is at 75% success using JVM 1.5 and 20% using Kaffe + 
Classpath.

The ASF runs gump on its own virtual box at

  http://vmgump.apache.org/

for more info about the project see

  http://gump.apache.org/

WARNING: gump is far from being perfect and a new generation (gump3) has 
been in the making forever [and this is why both Leo and I got a real 
day job and stopped working on it]. We also had a summer-of-code student 
working on the dynamic web application interface for dynagump and 
continuing that work is in my light-year-long todo list.

I'm secretly hoping to get this project to make me itch my old gump 
scars enough to start scratching again.

NOTE: if somebody wants to have access to vmgump (the solaris zone that 
runs all the code) and help us setup a harmony gump run, that can be 
easily arranged.

Hope this helps.

-- 
Stefano.

Re: Results of big commits

[Mark Hindess <ma...@googlemail.com>]

Stefano,

I don't really know much about gump but I'm interested to learn a
little more about it.  I'm doing some builds local so I should be able
to help with the details we'd need to get it going.  Hopefully
HARMONY-39 will be committed by the time we get things set up.

In our builds the ant recipe for completing the Harmony + VME tree is
as follows:

  <target name="copy-depends">
    <echo>Copying VME to ${root}</echo>
    <copy todir="${root}/jre/bin/default/" overwrite="true">
      <fileset dir="${vme.root}/deploy/jre/bin/default/" />
    </copy>

    <echo>Copying XML jars to jre/lib/boot</echo>
    <copy todir="${root}/jre/lib/boot/" overwrite="true">
      <fileset dir="${depend.dir}">
        <include name="resolver.jar" />
        <include name="xalan.jar" />
        <include name="xercesImpl.jar" />
        <include name="xml-apis.jar" />
      </fileset>
    </copy>

    <!-- This jar has been unsigned.  I did this on unix with:
             zip -d /tmp/bcprov.jar META-INF/BCKEY.SF
    -->
    <echo>Copying bouncycastle jar to jre/lib/ext</echo>
    <copy todir="${root}/jre/lib/ext/" overwrite="true">
      <fileset dir="${depend.dir}">
        <include name="bcprov.jar" />
      </fileset>
    </copy>
  </target>

I've not tested it but I think with Tim's change in r386171 the XML jars should
already be present in the right place so that part can be removed.

I'll describe a little more about the builds I'm running in a separate note.

Regards,
 Mark.

On 3/15/06, Stefano Mazzocchi <st...@apache.org> wrote:
> Mark Hindess wrote:
> > As well as the new classes, we have over 2700 tests that's nearly ten
> > times the number we were running a week ago.  And there are a few more
> > that need some work.  So if anyone is looking for something to do,
> > take a look at the excluded tests in the
> > modules/*/make/common/build.xml files.
> >
> > I've been doing some application testing on the latest trunk plus the
> > integration of HARMONY-39 in my workspace.  It's pretty cool.
> >
> > Tomcat 5.5 (which uses the eclipse compiler rather than requiring a
> > jdk) now starts up ok.  (I do get an error when it shuts down but I'm
> > sure we'll get to that.)
> >
> > I tried axis but it looks like we'll need stubs for a few more classes
> > before that will work - e.g. java.awt.datatransfer.Transferable and
> > java/rmi/RemoteException.
> >
> > It's great to see some really substantial applications running on the
> > Harmony classes.
>
> Mark,
>
> this is just awesome.
>
> Now, I *really* think we should have Gump running on Harmony sooner
> rather than later, this will tell us more about where we need to put our
> efforts on earlier.
>
> I might even volunteer for that (I'm the one who did it for
> kaffe/classpath in the past) if you point me (write me) a very detailed
> description on how to get all the pieces together, build them and
> getting them run.
>
> Also, from Leo, I would like to know if we should be using
> Gump3/Dynagump or not. Yes, I'm willing to fix gump problems if they emerge.
>
> --
> Stefano.
>
>

--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.

Re: Results of big commits

[Stefano Mazzocchi <st...@apache.org>]

Mark Hindess wrote:
> As well as the new classes, we have over 2700 tests that's nearly ten
> times the number we were running a week ago.  And there are a few more
> that need some work.  So if anyone is looking for something to do,
> take a look at the excluded tests in the
> modules/*/make/common/build.xml files.
> 
> I've been doing some application testing on the latest trunk plus the
> integration of HARMONY-39 in my workspace.  It's pretty cool.
> 
> Tomcat 5.5 (which uses the eclipse compiler rather than requiring a
> jdk) now starts up ok.  (I do get an error when it shuts down but I'm
> sure we'll get to that.)
> 
> I tried axis but it looks like we'll need stubs for a few more classes
> before that will work - e.g. java.awt.datatransfer.Transferable and
> java/rmi/RemoteException.
> 
> It's great to see some really substantial applications running on the
> Harmony classes.

Mark,

this is just awesome.

Now, I *really* think we should have Gump running on Harmony sooner 
rather than later, this will tell us more about where we need to put our 
efforts on earlier.

I might even volunteer for that (I'm the one who did it for 
kaffe/classpath in the past) if you point me (write me) a very detailed 
description on how to get all the pieces together, build them and 
getting them run.

Also, from Leo, I would like to know if we should be using 
Gump3/Dynagump or not. Yes, I'm willing to fix gump problems if they emerge.

-- 
Stefano.