You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2004/06/08 09:01:50 UTC
Use of the what command with java code (was: Including source files in jars)
Le 8 juin 04, à 08:32, Sylvain Wallez a écrit :
> ...You can know when the build was done by looking at the class files
> creation date in the jars, but you cannot know what sources were used
> to produce them, except that they're older than the build. But how
> much older? Was the checkout done a day before or a week? Also, was it
> a full cvs update or only a partial one (e.g. on a particular
> block)?...
In the Good Old Times (C++ programming under unix) we were using the
"what" command to tell us from which versions of source files our
binaries were built (see "man what" for more info if you're running a
decent platform) (I know I'll get flamed for saying "decent" ;-)
A quick test shows that this works with java as well, using unzip -p to
decompress jars before letting "what" process their content.
g4:/tmp> cat A.java
class A {
public static final String WHAT_ID = "@(#)$Id: A.java,v 1.3
1999/07/08 14:16:07 sylvain Exp $";
public static void main(String args[]) {
System.out.println(WHAT_ID);
}
}
g4:/tmp> javac A.java
g4:/tmp> what A.class
A.class
$Id: A.java,v 1.3 1999/07/08 14:16:07 sylvain Exp $
g4:/tmp> jar cvf a.jar A.class
. . .
g4:/tmp> unzip -p a.jar | what
$Id: A.java,v 1.3 1999/07/08 14:16:07 sylvain Exp $
So I think, by simply adding WHAT_ID strings to our source files we
could have this info without having to include source code in jars (but
of course, your solution works *now* ;-)
-Bertrand
Re: Use of the what command with java code (was: Including source files in jars)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 8 juin 04, à 20:52, Tim Larson a écrit :
> ...This sounds great, except if the cause of the problem/solution that
> made you dig in the source code is a change that was not committed yet,
> and so did not have its version control number bumped appropriately,
> and of course any source code changes would not be stored in the
> version control repository in this case...
Good point. Me, I have a rule that "if it's not under source-code
control it doesn't exist" and will not use code in production that has
not been checked in, but you're right that this might happen.
-Bertrand
Re: Use of the what command with java code (was: Including source files in jars)
Posted by Tim Larson <ti...@keow.org>.
On Tue, Jun 08, 2004 at 09:01:50AM +0200, Bertrand Delacretaz wrote:
> Le 8 juin 04, ? 08:32, Sylvain Wallez a ?crit :
> >...You can know when the build was done by looking at the class files
> >creation date in the jars, but you cannot know what sources were used
> >to produce them, except that they're older than the build. But how
> >much older? Was the checkout done a day before or a week? Also, was it
> >a full cvs update or only a partial one (e.g. on a particular
> >block)?...
>
> In the Good Old Times (C++ programming under unix) we were using the
> "what" command to tell us from which versions of source files our
> binaries were built (see "man what" for more info if you're running a
> decent platform) (I know I'll get flamed for saying "decent" ;-)
>
> A quick test shows that this works with java as well, using unzip -p to
> decompress jars before letting "what" process their content.
This sounds great, except if the cause of the problem/solution that
made you dig in the source code is a change that was not committed yet,
and so did not have its version control number bumped appropriately,
and of course any source code changes would not be stored in the
version control repository in this case. With a centralized setup like
CVS this is pretty likely to happen occasionally, but less likely with
a distributed setup like Monotone.
In short, there are times when having the *actual* source code around
could be a real lifesaver.
--Tim Larson
Re: Use of the what command with java code
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Even better would be to have "directly" the URL that would return you
>> the source file. SVN is already web based, you don't need viewcvs or
>> anything else, just the right URL (do a tcpflow dump of the SVN client
>> over http and you know what I mean)
>
>
>
> Hey, cool idea! We could even have the "what" result be formatted as
> HTML linking to source files!
We could have a getDescription() method returning an RDF that encoded
all that ;-)
--
Stefano, who candidates himself for the FS-of-the-month award with this.
Re: Use of the what command with java code
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Even better would be to have "directly" the URL that would return you
> the source file. SVN is already web based, you don't need viewcvs or
> anything else, just the right URL (do a tcpflow dump of the SVN client
> over http and you know what I mean)
Hey, cool idea! We could even have the "what" result be formatted as
HTML linking to source files!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 juin 04, à 11:51, Sylvain Wallez a écrit :
>
>> .../me kindly reminds Bertrand that Cocoon is released as source only
>> :-)
>
>
> /me goes back in his corner, ears pointing down ;-)
;-P
>> In the distro, there's no SVN or CVS directories from where we could
>> get the version info. So how do we get this info included in the jars
>> with an official distro?
>
>
> Of course, sorry for not waking up more today ;-)
>
> Which means you were 100% right that "what" info is better than jar
> manifest info as long as we're not shipping jars. This is not urgent
> but it would be useful, shall I create a bugzilla task so that we
> don't forget?
+1 !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juin 04, à 11:51, Sylvain Wallez a écrit :
> .../me kindly reminds Bertrand that Cocoon is released as source only
> :-)
/me goes back in his corner, ears pointing down ;-)
> In the distro, there's no SVN or CVS directories from where we could
> get the version info. So how do we get this info included in the jars
> with an official distro?
Of course, sorry for not waking up more today ;-)
Which means you were 100% right that "what" info is better than jar
manifest info as long as we're not shipping jars. This is not urgent
but it would be useful, shall I create a bugzilla task so that we don't
forget?
-Bertrand
Re: Use of the what command with java code
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 juin 04, à 11:24, Sylvain Wallez a écrit :
>
>> ...There's a problem with Antonio's proposal: people that download
>> the official release don't have the source control information (be it
>> CVS or SVN), yet still have to build their own copy of Cocoon...
>
>
> Not sure if I understand: the SVN release number would be included in
> the manifest in jar files, and people can use cvsview (or whatever the
> SVN equivalent is) to get at the right version of the file, isn't it?
/me kindly reminds Bertrand that Cocoon is released as source only :-)
In the distro, there's no SVN or CVS directories from where we could get
the version info. So how do we get this info included in the jars with
an official distro?
>> ...So I'm more in favor of including the "what" information, which
>> puts a small but indelibile stamp in class files (provided of course
>> that the file hasn't been modified after its checkout)....
>
>
> And this could work for your own code as well if you respect the what
> convention, so I agree that it is more precise. The downside is making
> sure this info is in every source file, we'd need a script or ant task
> to check I guess.
Yep. A checking task shouldn't be that difficult to write.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juin 04, à 12:14, Stefano Mazzocchi a écrit :
> ...Even better would be to have "directly" the URL that would return
> you the source file. SVN is already web based, you don't need viewcvs
> or anything else, just the right URL (do a tcpflow dump of the SVN
> client over http and you know what I mean)
Great idea - I have added this to the "spec" in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29462
-Bertrand
Re: Use of the what command with java code
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 juin 04, à 11:24, Sylvain Wallez a écrit :
>
>> ...There's a problem with Antonio's proposal: people that download the
>> official release don't have the source control information (be it CVS
>> or SVN), yet still have to build their own copy of Cocoon...
>
>
> Not sure if I understand: the SVN release number would be included in
> the manifest in jar files, and people can use cvsview (or whatever the
> SVN equivalent is) to get at the right version of the file, isn't it?
Even better would be to have "directly" the URL that would return you
the source file. SVN is already web based, you don't need viewcvs or
anything else, just the right URL (do a tcpflow dump of the SVN client
over http and you know what I mean)
--
Stefano.
Re: Use of the what command with java code
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juin 04, à 11:24, Sylvain Wallez a écrit :
> ...There's a problem with Antonio's proposal: people that download the
> official release don't have the source control information (be it CVS
> or SVN), yet still have to build their own copy of Cocoon...
Not sure if I understand: the SVN release number would be included in
the manifest in jar files, and people can use cvsview (or whatever the
SVN equivalent is) to get at the right version of the file, isn't it?
> ...So I'm more in favor of including the "what" information, which
> puts a small but indelibile stamp in class files (provided of course
> that the file hasn't been modified after its checkout)....
And this could work for your own code as well if you respect the what
convention, so I agree that it is more precise. The downside is making
sure this info is in every source file, we'd need a script or ant task
to check I guess.
> ...And yes, I admit that my solution is good only for uncommon cases,
> i.e. for hard-core users living on the bleeding edge :-)
hehe ;-)
-Bertrand
Re: Use of the what command with java code
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 juin 04, à 09:55, Sylvain Wallez a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
>>>
>>>> ...What about the other proposal I did:
>>>>
>>>> Insert in META-INF/MANIFEST.MF file the "SVN Revision number" (+ maybe
>>>> other needed stuff - need to investigate) of the local working copy at
>>>> compile time? (BTW, It does not requiere net access, because the
>>>> info is
>>>> retrieved from your local working copy)...
>>>
>>>
>>>
>>> I think you're right, with SVN this is enough as the revision number
>>> applies to the whole source tree, no need for individual file
>>> revision info.
>>
>>
>>
>> What if you have a partial update, e.g. keep the officially released
>> core, but use a snapshot of a periperal function or blocks?
>
>
> Hmmm...yes, that's clearly a use-case for individual file revision
> info. Another case would be when you have your own source code control
> system for parts of Cocoon that you (temporarily) maintain yourself,
> like what you currently do with your forms stuff.
>
> Note that I have nothing against your including of source files in
> jars as a switchable option - you're right that this is the more
> precise info that we can provide.
>
> My conclusion would be that including the SVN revision number as
> proposed by Antonio is good for the common case, and your "include
> source in jars" switch can be used for extreme/uncommon cases - so why
> not have both?
There's a problem with Antonio's proposal: people that download the
official release don't have the source control information (be it CVS or
SVN), yet still have to build their own copy of Cocoon.
So I'm more in favor of including the "what" information, which puts a
small but indelibile stamp in class files (provided of course that the
file hasn't been modified after its checkout).
And yes, I admit that my solution is good only for uncommon cases, i.e.
for hard-core users living on the bleeding edge :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz dijo:
> Le 9 juin 04, à 09:55, Sylvain Wallez a écrit :
>
>> Bertrand Delacretaz wrote:
>> What if you have a partial update, e.g. keep the officially released
>> core, but use a snapshot of a periperal function or blocks?
>
> Hmmm...yes, that's clearly a use-case for individual file revision
> info. Another case would be when you have your own source code control
> system for parts of Cocoon that you (temporarily) maintain yourself,
> like what you currently do with your forms stuff.
>
> Note that I have nothing against your including of source files in jars
> as a switchable option - you're right that this is the more precise
> info that we can provide.
>
> My conclusion would be that including the SVN revision number as
> proposed by Antonio is good for the common case, and your "include
> source in jars" switch can be used for extreme/uncommon cases - so why
> not have both?
Sylvain:
Please, note I already agreed with your proposal. I understand it is
convenient at special cases.
I am just against to make them a default.
About the SVN Revision Number, I think is convenient too and it will be
enough for snapshot users. But, I am not sure if it can be "on" as
default.
WDYT?
Best Regards,
Antonio Gallardo.
Best Regards,
Antonio Gallardo.
Re: Use of the what command with java code
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juin 04, à 09:55, Sylvain Wallez a écrit :
> Bertrand Delacretaz wrote:
>
>> Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
>>
>>> ...What about the other proposal I did:
>>>
>>> Insert in META-INF/MANIFEST.MF file the "SVN Revision number" (+
>>> maybe
>>> other needed stuff - need to investigate) of the local working copy
>>> at
>>> compile time? (BTW, It does not requiere net access, because the
>>> info is
>>> retrieved from your local working copy)...
>>
>>
>> I think you're right, with SVN this is enough as the revision number
>> applies to the whole source tree, no need for individual file
>> revision info.
>
>
> What if you have a partial update, e.g. keep the officially released
> core, but use a snapshot of a periperal function or blocks?
Hmmm...yes, that's clearly a use-case for individual file revision
info. Another case would be when you have your own source code control
system for parts of Cocoon that you (temporarily) maintain yourself,
like what you currently do with your forms stuff.
Note that I have nothing against your including of source files in jars
as a switchable option - you're right that this is the more precise
info that we can provide.
My conclusion would be that including the SVN revision number as
proposed by Antonio is good for the common case, and your "include
source in jars" switch can be used for extreme/uncommon cases - so why
not have both?
-Bertrand
Re: Use of the what command with java code
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
>
>> ...What about the other proposal I did:
>>
>> Insert in META-INF/MANIFEST.MF file the "SVN Revision number" (+ maybe
>> other needed stuff - need to investigate) of the local working copy at
>> compile time? (BTW, It does not requiere net access, because the info is
>> retrieved from your local working copy)...
>
>
> I think you're right, with SVN this is enough as the revision number
> applies to the whole source tree, no need for individual file revision
> info.
What if you have a partial update, e.g. keep the officially released
core, but use a snapshot of a periperal function or blocks?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code (was: Including source files in jars)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
> ...What about the other proposal I did:
>
> Insert in META-INF/MANIFEST.MF file the "SVN Revision number" (+ maybe
> other needed stuff - need to investigate) of the local working copy at
> compile time? (BTW, It does not requiere net access, because the info
> is
> retrieved from your local working copy)...
I think you're right, with SVN this is enough as the revision number
applies to the whole source tree, no need for individual file revision
info.
It won't solve Tim's problem of using non-committed code, but it's a
lightweight and elegant way of knowing from which (checked-in) version
your code was built.
I never used ant tasks to get at SVN info but someone has probably done
it already.
-Bertrand
Re: Use of the what command with java code (was: Including source
files in jars)
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz dijo:
> Le 8 juin 04, à 19:59, Antonio Gallardo a écrit :
>
>> ..Wow. I think it is an amazing solution! Have this impact at runtime
>> in Java?..
>
> The WHAT_ID strings would obviously use space in the jars, that's all.
What about the other proposal I did:
Insert in META-INF/MANIFEST.MF file the "SVN Revision number" (+ maybe
other needed stuff - need to investigate) of the local working copy at
compile time? (BTW, It does not requiere net access, because the info is
retrieved from your local working copy).
With this solution, we will affect almost nothing (or nothing) at runtime.
Just a small about of inserted bytes.
We can see the SVN Revision number in many ways and I am sure there must
be an ant task for that. Running the command in my local working copy of
Forrest now I got:
[agallardo@portatil forrest]$ svn info
Path: .
URL: https://svn.apache.org/repos/asf/forrest/trunk
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 20925
Node Kind: directory
Schedule: normal
Last Changed Author: brondsem
Last Changed Rev: 20918
Last Changed Date: 2004-06-08 12:38:30 -0600 (Tue, 08 Jun 2004)
Properties Last Updated: 2004-05-22 02:44:03 -0600 (Sat, 22 May 2004)
WDYT?
Best Regards,
Antonio Gallardo
Re: Use of the what command with java code (was: Including source files in jars)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 8 juin 04, à 19:59, Antonio Gallardo a écrit :
> ..Wow. I think it is an amazing solution! Have this impact at runtime
> in Java?..
The WHAT_ID strings would obviously use space in the jars, that's all.
-Bertrand
Re: Use of the what command with java code (was: Including source
files in jars)
Posted by Antonio Gallardo <ag...@agssa.net>.
Wow. I think it is an amazing solution! Have this impact at runtime in Java?
Another solution is for SVN:
Include in META-INF the SVN number inside each generated jar. I think it
is the least disturbing and cost less.
WDYT?
Best Regards,
Antonio Gallardo
Bertrand Delacretaz dijo:
> Le 8 juin 04, à 08:32, Sylvain Wallez a écrit :
>> ...You can know when the build was done by looking at the class files
>> creation date in the jars, but you cannot know what sources were used
>> to produce them, except that they're older than the build. But how
>> much older? Was the checkout done a day before or a week? Also, was it
>> a full cvs update or only a partial one (e.g. on a particular
>> block)?...
>
> In the Good Old Times (C++ programming under unix) we were using the
> "what" command to tell us from which versions of source files our
> binaries were built (see "man what" for more info if you're running a
> decent platform) (I know I'll get flamed for saying "decent" ;-)
>
> A quick test shows that this works with java as well, using unzip -p to
> decompress jars before letting "what" process their content.
>
> g4:/tmp> cat A.java
> class A {
> public static final String WHAT_ID = "@(#)$Id: A.java,v 1.3
> 1999/07/08 14:16:07 sylvain Exp $";
> public static void main(String args[]) {
> System.out.println(WHAT_ID);
> }
> }
>
> g4:/tmp> javac A.java
> g4:/tmp> what A.class
> A.class
> $Id: A.java,v 1.3 1999/07/08 14:16:07 sylvain Exp $
>
> g4:/tmp> jar cvf a.jar A.class
> . . .
> g4:/tmp> unzip -p a.jar | what
> $Id: A.java,v 1.3 1999/07/08 14:16:07 sylvain Exp $
>
> So I think, by simply adding WHAT_ID strings to our source files we
> could have this info without having to include source code in jars (but
> of course, your solution works *now* ;-)
>
> -Bertrand
>
>