You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Nick Chalko <ni...@chalko.com> on 2003/07/30 17:23:58 UTC

Date mismatch

I run a local gump  at
http://gump.chalko.com/index.html
but I sometimes get date mismatches on generated jars  for example


Build krysalis-ruper - ruper Wed Jul 30 04:04:33 PDT 2003
Module: definition <http://gump.chalko.com/module_krysalis-ruper.html> 
home <http://www.krysalis.org/index.shtml> cvs 
<http://gump.chalko.com/cvs_krysalis-ruper.html>
Dependencies: ant <http://gump.chalko.com/module_ant.html> 
krysalis-version-core 
<http://gump.chalko.com/krysalis-version-core.html> xml-xerces 
<http://gump.chalko.com/module_.html> commons-vfs 
<http://gump.chalko.com/module_commons-vfs.html> commons-logging 
<http://gump.chalko.com/module_jakarta-commons.html> commons-httpclient 
<http://gump.chalko.com/module_jakarta-commons.html> jakarta-regexp 
<http://gump.chalko.com/module_jakarta-regexp.html>

Missing prereq 
|/home/share/gump/gump-work/krysalis-version/build/ant-bootstrap/krysalis-version-core/krysalis-version-core-20030729.jar| 
from krysalis-version-core 
<http://gump.chalko.com/krysalis-version-core.html>


------------------------------------------------------------------------
Note this ran on the 30th, but was looking for the 29th. 

I imagine this is a TZ thing. 

Any ideas on where to fix this at.

R,
Nick

Re: Date mismatch

Posted by Nick Chalko <ni...@chalko.com>.
Adam Jack wrote:

>>Nick Chalko wrote:
>>
>>It looks like the failed merge step was the cause.   my 09:00  run
>>worked fine.
>>
>>    
>>
>Can we modify the gump.sh to test for gen failure and stop?
>
Yes we should.  and send a nag email.

>
>That said, this problem has also occured on public gump before, but who
>knows -- maybe for the same reason. I stil think there is more to dig into
>with this.
>
>regards
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Re: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
> Nick Chalko wrote:
>
> It looks like the failed merge step was the cause.   my 09:00  run
> worked fine.
>
Can we modify the gump.sh to test for gen failure and stop?

That said, this problem has also occured on public gump before, but who
knows -- maybe for the same reason. I stil think there is more to dig into
with this.

regards

Adam

Re: Date mismatch

Posted by Nick Chalko <ni...@chalko.com>.
Nick Chalko wrote:

> Nick Chalko wrote:
>
>> I run a local gump  at
>> http://gump.chalko.com/index.html
>> but I sometimes get date mismatches on generated jars  for example
>
>
>
>
> This coould bebecuase the merge step failed  but th erest of the gump 
> run continued. Still investigating.
>

It looks like the failed merge step was the cause.   my 09:00  run 
worked fine.

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

Re: Date mismatch

Posted by Nick Chalko <ni...@chalko.com>.
Nick Chalko wrote:

> I run a local gump  at
> http://gump.chalko.com/index.html
> but I sometimes get date mismatches on generated jars  for example



This coould bebecuase the merge step failed  but th erest of the gump 
run continued. 
Still investigating.

Re: Date mismatch

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 31 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> I think some information gump has isn't snarfable like above.

What kind of information is it that you'd need to expose?

I feel more like adding additional tokens to be expanded
(@@WORKSPACE@@ or whatever) that you can use or not.  Passing
properties to the Ant build unconditionally can result in (admittedly
unlikely) name-clashes.

> So, what do you think to what I am proposing given that?

I'm not exactly sure what you are proposing 8-)

Stefan

RE: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
	> Hmm, I did a search for .timestamp (trying to find out who created
	> it, and I could) and look what I find in gump.sh.

	It predates gump.sh by far.

Yes, but don't forget -- gump.sh was just taken from something Sam was using
anyway. We "inherited" many of the lines from that.

	I use .timestamp in the cron job that runs Gump and I think Leo and
	Sam do the same.  The .timestamp mechanism allows you to do partial
	Gump runs based on older builds.

	<snip/>

Interesting. I get it, thanks for the insight.

	> > rm -f .timestamp <----------------------------------- This was in
	> the script I copied, I never understood it

	I hope I could clear that up.

You did, so this line ought stay for gump.sh which likes to do all.

	You can always override them from the Gump descriptor.

	<ant ...>
	  <property name="DSTAMP" value="@@DATE@@"/>
	</ant>

Nice idea, that hadn't occurred to me.

	What is wrong with nesting <property> into Gump's <ant> tags?  Which
	feature are you missing?

I think some information gump has isn't snarfable like above. I use gump to
build some in-house projects, and then launch (via centipede) some "value
added" build scripts. Since I run a number of gumps on one box I need to
know which gump I am in and where, etc.

So, what do you think to what I am proposing given that? Good idea? Bad?

regards

Adam

Re: Date mismatch

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 30 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> Hmm, I did a search for .timestamp (trying to find out who created
> it, and I could) and look what I find in gump.sh.

It predates gump.sh by far.

I use .timestamp in the cron job that runs Gump and I think Leo and
Sam do the same.  The .timestamp mechanism allows you to do partial
Gump runs based on older builds.

To illustrate this.  Gump starts at 10pm on my box, today's results
(running more than eight hours) have a timestamp of 20030730 (to me
that's yesterday).

If I want to experiment with changing some project descriptors to see
whether I can get a certain build going, I simply rerun gen.sh and
test.  If Jenny didn't take .timestamp into account, all generated
jars would have the wrong date (as now would create 20030731) and I'd
have to rebuild a lot of projects.

> > rm -f .timestamp <----------------------------------- This was in
> the script I copied, I never understood it

I hope I could clear that up.

> The build.xml files used by krysalis-version-core and krysalis-ruper
> use current date (although I did set TZ to GMT) so they are
> generated at run time.

You can always override them from the Gump descriptor.

<ant ...>
  <property name="DSTAMP" value="@@DATE@@"/>
</ant>

> Maybe we ought remove that "rm -f".

Re: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
To attempt to get inside this problem...

I had a look inside the gump code that converts @DATE@ to a date string, and
it is in the Java code, which I beleive is called from gen.sh to create the
merge.xml and then build.sh/update.sh. It seems to take the "last modied
time (GMT)" of a file called .timestamp -- and if that doesn't exist then it
takes "now". [I think I've found the problem with this that part.]

Hmm, I did a search for .timestamp (trying to find out who created it, and I
could) and look what I find in gump.sh. I was not sure why it was there in
the scsript I copied, I assumed it was some facet of CVS - -and it might be.
Now it seems clear that by deleting that file we have change gump to run
from the date of the file to run from "now" != GMT.
#

# Do a CVS update

#

echo $SEPARATOR >> $GUMP_LOG

cd $GUMP

cvs -q update -dP >> $GUMP_LOG 2>&1

rm -f .timestamp            <----------------------------------- This was in
the script I copied, I never understood it


The build.xml files used by krysalis-version-core and krysalis-ruper use
current date (although I did set TZ to GMT) so they are generated at run
time. As such, I think we could have a mismatch. I've not figured out how it
fails, but it does (emperically) seem to be. Maybe we ought remove that
"rm -f". [That said, this is only the case on servers that use gump.sh, or
similar, right? Still confused...]

I'd love other folks thoughts on the intentions around this area, if they
could...

BTW: I think the problem is that gump is not communicating with the build
scripts, but relying upon implicit behaviours. I'd love gump to pass
parameters to the ant script, that a build script can rely upon. For
example, for this, to pass:

    -Dgump.date=XXXXXXXX

regards,

Adam
----- Original Message -----
From: "Nick Chalko" <ni...@chalko.com>
To: "Gump code and data" <gu...@jakarta.apache.org>
Sent: Wednesday, July 30, 2003 9:23 AM
Subject: Date mismatch


> I run a local gump  at
> http://gump.chalko.com/index.html
> but I sometimes get date mismatches on generated jars  for example
>
>
> Build krysalis-ruper - ruper Wed Jul 30 04:04:33 PDT 2003
> Module: definition <http://gump.chalko.com/module_krysalis-ruper.html>
> home <http://www.krysalis.org/index.shtml> cvs
> <http://gump.chalko.com/cvs_krysalis-ruper.html>
> Dependencies: ant <http://gump.chalko.com/module_ant.html>
> krysalis-version-core
> <http://gump.chalko.com/krysalis-version-core.html> xml-xerces
> <http://gump.chalko.com/module_.html> commons-vfs
> <http://gump.chalko.com/module_commons-vfs.html> commons-logging
> <http://gump.chalko.com/module_jakarta-commons.html> commons-httpclient
> <http://gump.chalko.com/module_jakarta-commons.html> jakarta-regexp
> <http://gump.chalko.com/module_jakarta-regexp.html>
>
> Missing prereq
>
|/home/share/gump/gump-work/krysalis-version/build/ant-bootstrap/krysalis-ve
rsion-core/krysalis-version-core-20030729.jar|
> from krysalis-version-core
> <http://gump.chalko.com/krysalis-version-core.html>
>
>
> ------------------------------------------------------------------------
> Note this ran on the 30th, but was looking for the 29th.
>
> I imagine this is a TZ thing.
>
> Any ideas on where to fix this at.
>
> R,
> Nick
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: gump-help@jakarta.apache.org
>

RE: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
Nick wrote:

	-Dgump.ws=/fullyqualified/path

Sure, this is good.

Also, we really do need to decide something on -DDSTAMP=@@DATE@@ as Stefan
(effectively) suggested. As gump sets get large, and CVS stays slow, there
will be times when the Jenny in gen.sh runs on a different day that then
ant/build.xml for individual projects. Doing -DDSTAMP=@@DATE@@ (the value
not that symbol) seems a bit crude, but might be the best way to alleviate
problems for lots of projects.

regards

Adam

Re: Date mismatch

Posted by Nick Chalko <ni...@chalko.com>.
Adam Jack wrote:

>I keep coming up with a number of things:
>
>1) gump is running this build
>2) gump.date
>3) gump.ws -- where am I & other projects (useful for somethings)
>4) gump.info -- where the metadata is (useful for some things)
>5) Heck, I've relied on most of those GUMP_ things we've set in the ENV.
>
>and others. I suspect -D is the quick option, but (although more work) I
>assume a gump.properties would be cleaner.
>  
>
-Dgump.ws=/fullyqualified/path

That solves 1 and 3
then ant scripts can load ${gump.ws}/gump.properties    to get the rest.




>regards
>  
>

RE: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
I keep coming up with a number of things:

1) gump is running this build
2) gump.date
3) gump.ws -- where am I & other projects (useful for somethings)
4) gump.info -- where the metadata is (useful for some things)
5) Heck, I've relied on most of those GUMP_ things we've set in the ENV.

and others. I suspect -D is the quick option, but (although more work) I
assume a gump.properties would be cleaner.

regards

Adam
-----Original Message-----
From: Nick Chalko [mailto:nick@chalko.com]
Sent: Wednesday, July 30, 2003 11:15 PM
To: Gump code and data
Subject: Re: Date mismatch


Yes that is a good Idea.
In general  a "this is a gump run"  property would be helpfull.

The time delay is not an issue on my gump. But gump.properties would be
nice.

I think we can add a -Dgump.workspace.dir=$GUMP_WS to the ant command
line in the builds, and go from there.

Adam Jack wrote:

>What about this thought....
>
>Gen is running one day, update is taking forever (just SF.net? not sure),
>and pushing build.sh into the next day -- and that is when the build
scripts
>are determining the date. As such the build.sh is looking for stuff from
day
>N and build produces from N+1.
>
>I think we need -Dgump.date=XXXXXXX.
>
>Can anybody shed light on what sets the .timestamp, it is a CVS side
effect?
>I guess I could try to leverage ant to extract the "date" from that file
(if
>I have access to it, which theoretically I guess I don't).
>
>I really would like to see a bunch of gump properties set. Maybe have gen
>generate a gump.properties in the workarea that projects could (if the
>chose) attempt to read.
>
>regards,
>
>Adam
>-----Original Message-----
>From: Nick Chalko [mailto:nick@chalko.com]
>Sent: Wednesday, July 30, 2003 9:24 AM
>To: Gump code and data
>Subject: Date mismatch
>
>
>I run a local gump  at
>http://gump.chalko.com/index.html
>but I sometimes get date mismatches on generated jars  for example
>
>
>Build krysalis-ruper - ruper Wed Jul 30 04:04:33 PDT 2003
>Module: definition <http://gump.chalko.com/module_krysalis-ruper.html>
>home <http://www.krysalis.org/index.shtml> cvs
><http://gump.chalko.com/cvs_krysalis-ruper.html>
>Dependencies: ant <http://gump.chalko.com/module_ant.html>
>krysalis-version-core
><http://gump.chalko.com/krysalis-version-core.html> xml-xerces
><http://gump.chalko.com/module_.html> commons-vfs
><http://gump.chalko.com/module_commons-vfs.html> commons-logging
><http://gump.chalko.com/module_jakarta-commons.html> commons-httpclient
><http://gump.chalko.com/module_jakarta-commons.html> jakarta-regexp
><http://gump.chalko.com/module_jakarta-regexp.html>
>
>Missing prereq
>|/home/share/gump/gump-work/krysalis-version/build/ant-bootstrap/krysalis-v
e
>rsion-core/krysalis-version-core-20030729.jar|
>from krysalis-version-core
><http://gump.chalko.com/krysalis-version-core.html>
>
>
>------------------------------------------------------------------------
>Note this ran on the 30th, but was looking for the 29th.
>
>I imagine this is a TZ thing.
>
>Any ideas on where to fix this at.
>
>R,
>Nick
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>

Re: Date mismatch

Posted by Nick Chalko <ni...@chalko.com>.
Yes that is a good Idea.  
In general  a "this is a gump run"  property would be helpfull. 

The time delay is not an issue on my gump. But gump.properties would be 
nice. 

I think we can add a -Dgump.workspace.dir=$GUMP_WS to the ant command 
line in the builds, and go from there.

Adam Jack wrote:

>What about this thought....
>
>Gen is running one day, update is taking forever (just SF.net? not sure),
>and pushing build.sh into the next day -- and that is when the build scripts
>are determining the date. As such the build.sh is looking for stuff from day
>N and build produces from N+1.
>
>I think we need -Dgump.date=XXXXXXX.
>
>Can anybody shed light on what sets the .timestamp, it is a CVS side effect?
>I guess I could try to leverage ant to extract the "date" from that file (if
>I have access to it, which theoretically I guess I don't).
>
>I really would like to see a bunch of gump properties set. Maybe have gen
>generate a gump.properties in the workarea that projects could (if the
>chose) attempt to read.
>
>regards,
>
>Adam
>-----Original Message-----
>From: Nick Chalko [mailto:nick@chalko.com]
>Sent: Wednesday, July 30, 2003 9:24 AM
>To: Gump code and data
>Subject: Date mismatch
>
>
>I run a local gump  at
>http://gump.chalko.com/index.html
>but I sometimes get date mismatches on generated jars  for example
>
>
>Build krysalis-ruper - ruper Wed Jul 30 04:04:33 PDT 2003
>Module: definition <http://gump.chalko.com/module_krysalis-ruper.html>
>home <http://www.krysalis.org/index.shtml> cvs
><http://gump.chalko.com/cvs_krysalis-ruper.html>
>Dependencies: ant <http://gump.chalko.com/module_ant.html>
>krysalis-version-core
><http://gump.chalko.com/krysalis-version-core.html> xml-xerces
><http://gump.chalko.com/module_.html> commons-vfs
><http://gump.chalko.com/module_commons-vfs.html> commons-logging
><http://gump.chalko.com/module_jakarta-commons.html> commons-httpclient
><http://gump.chalko.com/module_jakarta-commons.html> jakarta-regexp
><http://gump.chalko.com/module_jakarta-regexp.html>
>
>Missing prereq
>|/home/share/gump/gump-work/krysalis-version/build/ant-bootstrap/krysalis-ve
>rsion-core/krysalis-version-core-20030729.jar|
>from krysalis-version-core
><http://gump.chalko.com/krysalis-version-core.html>
>
>
>------------------------------------------------------------------------
>Note this ran on the 30th, but was looking for the 29th.
>
>I imagine this is a TZ thing.
>
>Any ideas on where to fix this at.
>
>R,
>Nick
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

RE: Date mismatch

Posted by Adam Jack <aj...@trysybase.com>.
What about this thought....

Gen is running one day, update is taking forever (just SF.net? not sure),
and pushing build.sh into the next day -- and that is when the build scripts
are determining the date. As such the build.sh is looking for stuff from day
N and build produces from N+1.

I think we need -Dgump.date=XXXXXXX.

Can anybody shed light on what sets the .timestamp, it is a CVS side effect?
I guess I could try to leverage ant to extract the "date" from that file (if
I have access to it, which theoretically I guess I don't).

I really would like to see a bunch of gump properties set. Maybe have gen
generate a gump.properties in the workarea that projects could (if the
chose) attempt to read.

regards,

Adam
-----Original Message-----
From: Nick Chalko [mailto:nick@chalko.com]
Sent: Wednesday, July 30, 2003 9:24 AM
To: Gump code and data
Subject: Date mismatch


I run a local gump  at
http://gump.chalko.com/index.html
but I sometimes get date mismatches on generated jars  for example


Build krysalis-ruper - ruper Wed Jul 30 04:04:33 PDT 2003
Module: definition <http://gump.chalko.com/module_krysalis-ruper.html>
home <http://www.krysalis.org/index.shtml> cvs
<http://gump.chalko.com/cvs_krysalis-ruper.html>
Dependencies: ant <http://gump.chalko.com/module_ant.html>
krysalis-version-core
<http://gump.chalko.com/krysalis-version-core.html> xml-xerces
<http://gump.chalko.com/module_.html> commons-vfs
<http://gump.chalko.com/module_commons-vfs.html> commons-logging
<http://gump.chalko.com/module_jakarta-commons.html> commons-httpclient
<http://gump.chalko.com/module_jakarta-commons.html> jakarta-regexp
<http://gump.chalko.com/module_jakarta-regexp.html>

Missing prereq
|/home/share/gump/gump-work/krysalis-version/build/ant-bootstrap/krysalis-ve
rsion-core/krysalis-version-core-20030729.jar|
from krysalis-version-core
<http://gump.chalko.com/krysalis-version-core.html>


------------------------------------------------------------------------
Note this ran on the 30th, but was looking for the 29th.

I imagine this is a TZ thing.

Any ideas on where to fix this at.

R,
Nick




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