Re: Access to Maven settings for BSF Gump build

2010-04-01 Thread Jörg Schaible
Hi Brett,

Brett Randall wrote:

 snip/

 I'd bet that the retroweaver will produce everytime the same thing.
 However, md5sums (ans sha1sum) is generated by the deploy plugin
 automatically and will always validate the deployed jar itself.

 - Jörg

 snip/
 
 For the md5sum I was referring to an md5sum run against .class files
 extracted from the retro-weaved JAR, varying from build to build.  On
 the bsf-engines module from the 3.x branch, this can be observed by
 running the following command twice:
 
 bsf-engines$ mvn clean install  unzip -p
 target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
 md5sum
 snip/
 c6817d078ad972bcf1716e05e4c7f52f  -
 bsf-engines$ mvn clean install  unzip -p
 target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
 md5sum
 snip/
 49fb13a50a5c8bbf88823f31ca882680  -
 
 Not sure what to make of that - is it retroweaver?  Maybe retroweaver
 places some datetime related info into the instrumented class-file.

It have to be retroweaver then..

 It doesn't matter, just pointing out that this tripped me when I was
 trying to fix the build and test that I was producing the exact same
 artifact with the new build.  It turns out that the artifact will be
 different from build to build without changes, unless I am missing
 something.

That's simply unfortunate. :-/

- Jörg


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



Re: Access to Maven settings for BSF Gump build

2010-04-01 Thread sebb
On 01/04/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Brett,

  Brett Randall wrote:


  snip/
  
   I'd bet that the retroweaver will produce everytime the same thing.
   However, md5sums (ans sha1sum) is generated by the deploy plugin
   automatically and will always validate the deployed jar itself.
  
   - Jörg
  
   snip/
  
   For the md5sum I was referring to an md5sum run against .class files
   extracted from the retro-weaved JAR, varying from build to build.  On
   the bsf-engines module from the 3.x branch, this can be observed by
   running the following command twice:
  
   bsf-engines$ mvn clean install  unzip -p
   target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
   md5sum
   snip/
   c6817d078ad972bcf1716e05e4c7f52f  -
   bsf-engines$ mvn clean install  unzip -p
   target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
   md5sum
   snip/
   49fb13a50a5c8bbf88823f31ca882680  -
  
   Not sure what to make of that - is it retroweaver?  Maybe retroweaver
   places some datetime related info into the instrumented class-file.


If you compare the classfiles, the last few bytes of each file are
slightly different.
Dunno if this is a datestamp or not.

However, the dates of the class files are also different; this is
probably caused by the repackaging process in the Ant script.

 It have to be retroweaver then..

And Ant.


   It doesn't matter, just pointing out that this tripped me when I was
   trying to fix the build and test that I was producing the exact same
   artifact with the new build.  It turns out that the artifact will be
   different from build to build without changes, unless I am missing
   something.


 That's simply unfortunate. :-/


  - Jörg



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



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