last night build on lsd

[Antoine Lévy-Lambert <an...@antbuild.com>]

1) dom4j is building again :-)

2) jakarta-slide's build is failing with an irritating message saying it
cannot copy

/data3/gump/jakarta-slide/lib/jdom-b9.jar

http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html

the build should actually be looking for

jdom-20040226-.jar because Oliver Zeigermann put this one 2 days ago in 
the repository of jakarta-slide


3) avalon is still failing on gumpy,
although the avalon guys have updated their descriptor, adding the 
suggested mkdir line.

http://lsd.student.utwente.nl/gump/avalon/avalon.html

Antoine




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

Re: last night build on lsd

[Stefan Bodewig <bo...@apache.org>]

On Sun, 29 Feb 2004, Antoine Lévy-Lambert <an...@antbuild.com>
wrote:

> 2) jakarta-slide's build is failing with an irritating message
> saying it cannot copy
> 
> /data3/gump/jakarta-slide/lib/jdom-b9.jar
> 
> http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html
> 
> the build should actually be looking for

I think the slide team simply forgot to adapt the build file when they
changed from jdom-b9 to a dated CVS snapshot.  Or they forgot to use a
property instead of a hard-coded filename 8-)

<http://marc.theaimsgroup.com/?l=slide-dev&m=107815316322321&w=2>

Stefan

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

Re: Gump Sync

["Adam R. B. Jack" <aj...@trysybase.com>]

> I just now looked into my build.sh again and we don't use -C.  Now you
> have me extra puzzled, since it behaves exactly as if the switch was
> enabled (and I don't think -a includes -C).

I should have said that didn't quite register (but didn't 'cos I didn't have
time to check). I didn't think Gumpy set that. Still, I've seen rsync just
not clean up directories that it ought, a long ways back (and can't recall
details). I just don't trust it.

 > Sync deletes the previous build results, so I think it's less likely
> to be hit by disk space issues than the actual build process.

Yeah, good point -- I was wrong. It was creating xdocs (for a new project)
that dorked when LSD became full.

regards

Adam


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

Re: Gump Sync

[Stefan Bodewig <bo...@apache.org>]

On Mon, 1 Mar 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> I do think we need our own rsync, but it is good to know of gotcha
> like this prior to writing it.

Quite possible.  In particular we don't need rsync but just sync.

> Do we need/want the .cvsignore functionality?

I don't really think so.

I just now looked into my build.sh again and we don't use -C.  Now you
have me extra puzzled, since it behaves exactly as if the switch was
enabled (and I don't think -a includes -C).

Anyway, we should use a complete sync without any excludes IMHO.

> I suspect we wish to migrate a directory based off existence and
> timestamp, but not contents (we ought rely upon timestamps, no?).

This will probably be good enough for us.

> What to do in case of failure? Just bail at time of issue, or ought
> we attempt to unwind our changes [not likely].

For our purpose a failure isn't as dramatic as for say mirrors.
Making big noise is warranted, but the orginal contents are still
there, so I wouldn't invest too much time into rollback support.

> Sync is likely to get hit with disk full, since many of the other
> aspects of Gump are change in place.

Sync deletes the previous build results, so I think it's less likely
to be hit by disk space issues than the actual build process.

> Ought we keep a track of all we do, so we can report upon that for
> users?  [We capture output of CVS/SVN which ought be the same, but
> it might be nice for us to do similarly.]

Some kind of human readable lock would be nice.

> Ought we design this via the Wiki?

Why not?

Stefan

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

Gump Sync: was (Re: Avalon build (was Re: last night build on lsd))

["Adam R. B. Jack" <aj...@trysybase.com>]

> avalon/target is in .cvsignore and since we use rsync's -C switch
> doesn't ever get cleaned out when doing an rsync.

First, Stefan, thanks for being so dogged w/ this problem, I doubt many
could've look into as hard as it needed.

I do think we need our own rsync, but it is good to know of gotcha like this
prior to writing it.
Let's try to specify the functionality before too much code gets laid down,
or thinking gets thunk...

Do we need/want the .cvsignore functionality? Do we need/want similar for
SVN? Do we need a .gumpignore?

I suspect we wish to migrate a directory based off existence and timestamp,
but not contents (we ought rely upon timestamps, no?). I suspect we don't
have to care about anything fancy, as Antoine stated, such as moving between
volumes or following symbolic links.

What to do in case of failure? Just bail at time of issue, or ought we
attempt to unwind our changes [not likely]. We need to ensure that this
automated environment isn't left in a state that a human has to clean up, at
least -- unless we know it. Sync is likely to get hit with disk full, since
many of the other aspects of Gump are change in place. Sync is likely to get
hit with permission problems, and so forth. Error handling is a key aspect.

Ought we keep a track of all we do, so we can report upon that for users?
[We capture output of CVS/SVN which ought be the same, but it might be nice
for us to do similarly.]

I know this is at the same time a simple piece of functionality, but a
critical one. I believe experience has shown that the nastiest problems in
Gump are when the data gets out of sync with CVS/SVN, and we trusted it to
be in sync. Also, since we work in the target area, we really rely upon sync
to clean up each time. That is a heavy burden.

Ought we design this via the Wiki?

regards,

Adam


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

Re: Avalon build

[Stefan Bodewig <bo...@apache.org>]

On Mon, 1 Mar 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> Ought we just ask the Avalon guys if they mind us taking a copy of
> their metadata yet still sending nags to them, or just doing it? Or,
> are you ok working via patches.

If working with patches finally leads to Avaoln getting built in Gump
and the Avalon community being involved in Gump, that is fine with me.
If it doesn't work, well, then we just need to tell the Avalon
community that they are part of the Gump committers.

Stefan

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

Re: Avalon build (was Re: last night build on lsd)

["Adam R. B. Jack" <aj...@trysybase.com>]

> I'm currently iteratively working towards a correct list of
> directories needed and will provide a patch against the current
> descriptor so that it is going to work.

Ought we just ask the Avalon guys if they mind us taking a copy of their
metadata yet still sending nags to them, or just doing it? Or, are you ok
working via patches.

regards

Adam


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

Avalon build (was Re: last night build on lsd)

[Stefan Bodewig <bo...@apache.org>]

On Mon, 01 Mar 2004, Stefan Bodewig <bo...@apache.org> wrote:
> On Sun, 29 Feb 2004, Antoine Lévy-Lambert <an...@antbuild.com>
> wrote:
> 
>> 3) avalon is still failing on gumpy,
> 
> This is extremely strange.
>
> I started out by removing my avalon directory to be sure I'd get a
> clean run - and it fails when I invoke "./build.sh avalon dist".
> Maybe rsync hasn't been cleaning out the avalon working copy
> completely?

I think I'm on the right track now.

avalon/target is in .cvsignore and since we use rsync's -C switch
doesn't ever get cleaned out when doing an rsync.

Both my and gump.covalent.net's installations have the missing classes
in target/classes from an old compilation that has never been cleaned
out.

The directories in Avalon's gump descriptors are more or less all
wrong, nobody evere uses target/api-classes but the classes get
compiled to api/target/classes.  And so on ...

I'm currently iteratively working towards a correct list of
directories needed and will provide a patch against the current
descriptor so that it is going to work.

Stefan

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

Re: last night build on lsd

[Stefan Bodewig <bo...@apache.org>]

On Sun, 29 Feb 2004, Antoine Lévy-Lambert <an...@antbuild.com>
wrote:

> 3) avalon is still failing on gumpy,

This is extremely strange.

I tried to pin down what was different between "traditional" and Gumpy
here and started by modifying the build.sh script generated on my box
to look more like Gumpy's command line.  There are only minor
differences:

* "traditional" has the thnigs that will end up on the bootclasspath
  once again on CLASSPATH.

* Gumpy sets build.clonevm unconditionally.

* order of CLASSPATH elements is slightly different.

I started out by removing my avalon directory to be sure I'd get a
clean run - and it fails when I invoke "./build.sh avalon dist".
Maybe rsync hasn't been cleaning out the avalon working copy
completely?

I'll perform a -debug run and hope to get more information here.  But
then again, avalon's build is really complex as you can see when
looking at the end of the build log - eight levels of nested <ant> or
<antcall>s.

Stefan

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