Python Gump TODOs

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

Hi,

I finally managed to compare the results on LSD (of last Thursday?)
with the ones of covalent.net and they look more or less the same.

Some comments on the output:

* I really like the "Missing Output" error that will help us to
  diagnose the "jar has moved" type of error a lot faster.

* Where is jakarta-commons?  commons-latka has a pre-req failure, no
  TODO for this type of problem?

* for the bigger modules the "traditional" listing of a single
  red/yellow/white line per project is superior IMHO.  When you watch
  Gump for a longer time day by day, you know which projects are
  "supposed to fail" - like excalibur-lifecycle.  It's a lot harder
  to ignore a red icon if you cannot immediately see that it is
  "the usual suspect".

* Navigation for a failed project is kind of cumbersome.  If you click
  on the "red" icon for test-ant (the last one in the Ant line), you
  have to scroll five pages to get to the build log - just to see that
  you have to follow another link to get the full log.

  I'd prefer to get the full log immediately for type "build failed"
  errors.

* The jakarta-slide results are inconsistent.  The TODO says "red",
  the modules list says "orange".

* jython builds fine on my box.

Stefan

Re: Python Gump TODOs

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

> Nope that is the point of the file.  Local settings that are not in CVS.

Not exactly, it was more -- per host configuration, of the things that vary
by machine (where gump is installed, where Java is, etc.) I've extended
gumpy.sh to look for local-env-py-{hostname}.sh and use that. These we could
check in to CVS.

Thinking about it, it sure would be nice not to have to have any
configuration than the workspace XML file. Sure would be nice not to have a
gumpy.sh at all. I'll add those to a TODO.

regards,

Adam

Re: Python Gump TODOs

[Nick Chalko <ni...@chalko.com>]

Leo Simons wrote:

>
>
>> I think I need to find a way to make these files less at risk.
>
>
> how about putting them in cvs?
>

Nope that is the point of the file.  Local settings that are not in CVS.

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

Re: Python Gump TODOs

[Leo Simons <le...@apache.org>]

Adam R. B. Jack wrote:
>>>Yup, don't know why it is 'last Thursday', I need to investigate that. I
> 
> was
> 
>>>kinda hoping it was Leo using the box for other things, but we'll see.
>>
>>nope; it should have been running.
> 
> Not sure what caused it trouble before, but now -- here is the grief. There
> was a file called 'local-env-py.sh' that have the LSD environment settings.
> It was wiped -- if not before, when 'cvs' -- which in this case Gump runs
> in -- was wiped.

whoops!

> I think I need to find a way to make these files less at risk.

how about putting them in cvs?

- LSD

Re: Python Gump TODOs

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

> > Yup, don't know why it is 'last Thursday', I need to investigate that. I
was
> > kinda hoping it was Leo using the box for other things, but we'll see.
>
> nope; it should have been running.

Not sure what caused it trouble before, but now -- here is the grief. There
was a file called 'local-env-py.sh' that have the LSD environment settings.
It was wiped -- if not before, when 'cvs' -- which in this case Gump runs
in -- was wiped.

I think I need to find a way to make these files less at risk.

regards

Adam

Re: Python Gump TODOs

[Leo Simons <le...@apache.org>]

Adam R. B. Jack wrote:
>>I finally managed to compare the results on LSD (of last Thursday?)
>>with the ones of covalent.net and they look more or less the same.
> 
> Thanks, I appreciate you doing this. Every pair of eyes (especially an
> expert pair) helps.
> 
> Yup, don't know why it is 'last Thursday', I need to investigate that. I was
> kinda hoping it was Leo using the box for other things, but we'll see.

nope; it should have been running.

cheers!

- LSD

Re: Python Gump TODOs

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

> I'd love to hear the reasoning behind these two. Are there examples of why
> they are needed?

Ah, yes ... for folks who use Gump locally -- doing builds w/o
updates/syncs. I keep forgetting that use case 'cos I'm focusing on the
nightlies.

BTW: Anybody interested in picking up the GUI part of Gumpy? I've neglected
it, yet it is a valuable use case. I'd help anybody who is interested in
working on it get into it.

regards

Adam

Re: Python Gump TODOs

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

On Mon, 3 Nov 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:

> I'd love to hear the reasoning behind these two. Are there examples
> of why they are needed?

<mkdir> in the jython case has been path of least resistance.

When Gump was run on JDK 1.3 <mkdir> was also necessary for <work>
entries as the 1.3 VMs drop directories from the CLASSPATH if they
don't exist at startup - so they had to exist before Ant was started.

<delete> in mockobjects is there because we build two different
(incompatible) versions from the same module.  The "cleaner"
alternative would be two modules, I guess.

Stefan

Re: Python Gump TODOs

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

> Woah,
>   mkdir and delet int the Gump Descriptor.    That seems wrong to me.  I
> thought the dump descriptor was declarative.
>
> Oh well if it there we should support it.

Good point. I started adding them, and then realized what you just stated. I
agree they are potentially dodgy (so perhaps we ought "frown on them -- 
unless there is a darn good reason".)

I see <deletes that say "clean up last build" -- but the "rsynch --delete"
(if used) ought do that (ought it not?) Even in a workspace that works on
the same directories each run (not like Sam's nightly to a dated directory)
ought be "clean" because of rsynch.

For <mkdir, if a users build.xml is 99% used for developers, and less often
by Gump, maybe there is a need. That said, I'm not sure it couldn't
transparently go into the build.xml.

I'd love to hear the reasoning behind these two. Are there examples of why
they are needed?

BTW: I don't see <delete or <mkdir documented on the Gump pages. Are they?

regards

Adam

Re: Python Gump TODOs

[Nick Chalko <ni...@chalko.com>]

Adam R. B. Jack wrote:

>>Ah, so the Python Gump doesn't know how to handle <mkdir> in the Gump
>>descriptor 8-)
>>
>>There also is an occasional <delete> (in mockobjects-j2ee-*) you may
>>want to look at.
>>    
>>


Woah,
  mkdir and delet int the Gump Descriptor.    That seems wrong to me.  I 
thought the dump descriptor was declarative.

Oh well if it there we should support it.

Re: Python Gump TODOs

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

> Ah, so the Python Gump doesn't know how to handle <mkdir> in the Gump
> descriptor 8-)
> 
> There also is an occasional <delete> (in mockobjects-j2ee-*) you may
> want to look at.

See, I knew you'd spot something I wouldn't! Thanks. :-)

regards

Adam

Re: Python Gump TODOs

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

On Mon, 3 Nov 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:

>> * jython builds fine on my box.
> 
> Last I looked .. this problem is because their dist directory
> doesn't exist at time of building.

Ah, so the Python Gump doesn't know how to handle <mkdir> in the Gump
descriptor 8-)

There also is an occasional <delete> (in mockobjects-j2ee-*) you may
want to look at.

Stefan

Re: Python Gump TODOs

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

> I finally managed to compare the results on LSD (of last Thursday?)
> with the ones of covalent.net and they look more or less the same.

Thanks, I appreciate you doing this. Every pair of eyes (especially an
expert pair) helps.

Yup, don't know why it is 'last Thursday', I need to investigate that. I was
kinda hoping it was Leo using the box for other things, but we'll see.

> * Where is jakarta-commons?  commons-latka has a pre-req failure, no
>   TODO for this type of problem?

I figured that we ought not bug folks when their pre-requisites fail, since
they (possibly) can do nothing about it. So, unless the module or the
project fails directly I don't add it to the TODOs.

> * for the bigger modules the "traditional" listing of a single
>   red/yellow/white line per project is superior IMHO.  When you watch
>   Gump for a longer time day by day, you know which projects are
>   "supposed to fail" - like excalibur-lifecycle.  It's a lot harder
>   to ignore a red icon if you cannot immediately see that it is
>   "the usual suspect".

Nick keeps asking for this also, a list of the projects in build order. I'll
try to add it.

> * Navigation for a failed project is kind of cumbersome.  If you click
>   on the "red" icon for test-ant (the last one in the Ant line), you
>   have to scroll five pages to get to the build log - just to see that
>   you have to follow another link to get the full log.
>
>   I'd prefer to get the full log immediately for type "build failed"
>   errors.

Yup, Leo asked for this. I got 'closer' putting the tail into the project,
but I'll work on it some more.

> * The jakarta-slide results are inconsistent.  The TODO says "red",
>   the modules list says "orange".
>
> * jython builds fine on my box.

Last I looked .. this problem is because their dist directory doesn't exist
at time of building. There is an ant target to make it, but they don't have
that as a dependency of the gump'ed target. I've written to them (a week or
two ago) to tell them, but no response. Not sure my posting got past
moderator, I could try again ... but I was hoping to nag them instead.

BTW: This is what I worry about with rsynch, I fear rsynch is imperfect.

regards

Adam