You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "DeVries, Joe" <jo...@austin.utexas.edu> on 2011/12/08 21:25:13 UTC

Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


Re: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Sands Alden Fish <sa...@MIT.EDU>.
Yes, I figured it must've been that I was using my system's default java v1.6.0_24.  Wasn't too difficult to work around.

I'll be in touch with the results.


--
sands fish
Senior Software Engineer
MIT Libraries
Technology Research & Development
sands@MIT.EDU<ma...@MIT.EDU>
E25-131





On Dec 9, 2011, at 10:22 AM, DeVries, Joe wrote:

Sands: FYI, I it compiled without errors using jdk 1.3.1_16 (same as in the manifest of the custom jar).  Let me know if you get it working, and I see if I can include it with Vireo.

Joe


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Sands Alden Fish [mailto:sands@MIT.EDU]
Sent: Friday, December 09, 2011 9:18 AM
To: <de...@cocoon.apache.org>>
Cc: DeVries, Joe; Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: Re: Determining blocks specified for building an existing cocoon 2.1.9 jar

It sounds like this is going to be the best solution possible.  I have a built version from this source (2.1.9) now and I'm going to try using the resulting JARs for debugging.

(I'm not sure why exactly, but the 2.1.9 build had errors in it from the tag.  ClobHelper and BlobHelper were missing overrides.  But I was able to put no-op methods in place and get it to build.)

We'll see how using these dependencies goes, probably today.

-Sands


On Dec 9, 2011, at 10:13 AM, Robby Pelssers wrote:


Did you checkout the tagged version from SVN?

http://svn.apache.org/repos/asf/cocoon

You will find a /tags/cocoon-2.1/RELEASE_2_1_9  (tagged version)

If you check this out you might be able to attach the sources and still be able to do quite a lot of debugging.  And if you can deduce what blocks you use you even might be able to somehow reconstruct the jar. I noticed that this version of Cocoon indeed has a block.properties file where you declare block dependencies.

It might sound like a long shot but I guess it’s better than nothing?!

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:35 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

The application is mission critical and not trivial to rewrite.  We are currently evaluating options for a better long term solution including switching the underlying DSpace to version 1.8.x which uses Cocoon 2.2.    I was hoping for a ‘quick’ solution to be able to better debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I’m pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard ‘Cocoon 2.1.x’ people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I’m not really that familiar with the building of Cocoon2.1.x apps but shouldn’t there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don’t have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don’t know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the ‘official’ cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477




RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by "DeVries, Joe" <jo...@austin.utexas.edu>.
Sands: FYI, I it compiled without errors using jdk 1.3.1_16 (same as in the manifest of the custom jar).  Let me know if you get it working, and I see if I can include it with Vireo.

Joe


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Sands Alden Fish [mailto:sands@MIT.EDU]
Sent: Friday, December 09, 2011 9:18 AM
To: <de...@cocoon.apache.org>
Cc: DeVries, Joe; Scott Phillips (scott.a.phillips@gmail.com)
Subject: Re: Determining blocks specified for building an existing cocoon 2.1.9 jar

It sounds like this is going to be the best solution possible.  I have a built version from this source (2.1.9) now and I'm going to try using the resulting JARs for debugging.

(I'm not sure why exactly, but the 2.1.9 build had errors in it from the tag.  ClobHelper and BlobHelper were missing overrides.  But I was able to put no-op methods in place and get it to build.)

We'll see how using these dependencies goes, probably today.

-Sands


On Dec 9, 2011, at 10:13 AM, Robby Pelssers wrote:


Did you checkout the tagged version from SVN?

http://svn.apache.org/repos/asf/cocoon

You will find a /tags/cocoon-2.1/RELEASE_2_1_9  (tagged version)

If you check this out you might be able to attach the sources and still be able to do quite a lot of debugging.  And if you can deduce what blocks you use you even might be able to somehow reconstruct the jar. I noticed that this version of Cocoon indeed has a block.properties file where you declare block dependencies.

It might sound like a long shot but I guess it's better than nothing?!

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:35 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

The application is mission critical and not trivial to rewrite.  We are currently evaluating options for a better long term solution including switching the underlying DSpace to version 1.8.x which uses Cocoon 2.2.    I was hoping for a 'quick' solution to be able to better debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I'm pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard 'Cocoon 2.1.x' people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477



Re: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Sands Alden Fish <sa...@MIT.EDU>.
It sounds like this is going to be the best solution possible.  I have a built version from this source (2.1.9) now and I'm going to try using the resulting JARs for debugging.

(I'm not sure why exactly, but the 2.1.9 build had errors in it from the tag.  ClobHelper and BlobHelper were missing overrides.  But I was able to put no-op methods in place and get it to build.)

We'll see how using these dependencies goes, probably today.

-Sands


On Dec 9, 2011, at 10:13 AM, Robby Pelssers wrote:

Did you checkout the tagged version from SVN?

http://svn.apache.org/repos/asf/cocoon

You will find a /tags/cocoon-2.1/RELEASE_2_1_9  (tagged version)

If you check this out you might be able to attach the sources and still be able to do quite a lot of debugging.  And if you can deduce what blocks you use you even might be able to somehow reconstruct the jar. I noticed that this version of Cocoon indeed has a block.properties file where you declare block dependencies.

It might sound like a long shot but I guess it’s better than nothing?!

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Friday, December 09, 2011 3:35 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

The application is mission critical and not trivial to rewrite.  We are currently evaluating options for a better long term solution including switching the underlying DSpace to version 1.8.x which uses Cocoon 2.2.    I was hoping for a ‘quick’ solution to be able to better debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I’m pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard ‘Cocoon 2.1.x’ people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I’m not really that familiar with the building of Cocoon2.1.x apps but shouldn’t there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don’t have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don’t know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the ‘official’ cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477



RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Robby Pelssers <Ro...@nxp.com>.
Did you checkout the tagged version from SVN?

http://svn.apache.org/repos/asf/cocoon

You will find a /tags/cocoon-2.1/RELEASE_2_1_9  (tagged version)

If you check this out you might be able to attach the sources and still be able to do quite a lot of debugging.  And if you can deduce what blocks you use you even might be able to somehow reconstruct the jar. I noticed that this version of Cocoon indeed has a block.properties file where you declare block dependencies.

It might sound like a long shot but I guess it's better than nothing?!

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Friday, December 09, 2011 3:35 PM
To: Robby Pelssers; dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

The application is mission critical and not trivial to rewrite.  We are currently evaluating options for a better long term solution including switching the underlying DSpace to version 1.8.x which uses Cocoon 2.2.    I was hoping for a 'quick' solution to be able to better debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I'm pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard 'Cocoon 2.1.x' people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by "DeVries, Joe" <jo...@austin.utexas.edu>.
The application is mission critical and not trivial to rewrite.  We are currently evaluating options for a better long term solution including switching the underlying DSpace to version 1.8.x which uses Cocoon 2.2.    I was hoping for a 'quick' solution to be able to better debug the current code base, but I agree that this may not be a viable option.

Thanks Again,

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 8:28 AM
To: DeVries, Joe; dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I'm pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard 'Cocoon 2.1.x' people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Robby Pelssers <Ro...@nxp.com>.
Hi Joe,

I can understand that you want to be able to restore a situation where you actually have matching sources and config for your existing application.   On the other hand this might be a tricky task from the looks of it. Is this a huge application?!  Porting the app to Cocoon2.2 or Cocoon 3 is no option?  I'm pretty sure you will like working with the newer versions even more and even I am planning to switch from Cocoon2.2 to Cocoon3 next year. I know this involves a lot of work but sometimes the effort is worth the return you get.

If you guys should consider moving to C2 or higher there might be more response to help out.   If this is impossible maybe some die hard 'Cocoon 2.1.x' people can give more help.

Robby

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by "DeVries, Joe" <jo...@austin.utexas.edu>.
Hi Robby,

Regarding my objective, we have an application which relies on an old version of DSpace.  DSpace 1.5.1 uses the custom cocoon jar for which we no longer have the source, or ability to recreate.  I would like to build a 2.1.9 jar and have the source for debugging that is compatible with the existing version.    My other objective (and likely the more important one) is to gain a better understanding of how Cocoon works.

Thanks for looking into it, I appreciate your help.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Friday, December 09, 2011 1:43 AM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com); DeVries, Joe
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>); Scott Phillips (scott.a.phillips@gmail.com<ma...@gmail.com>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]<mailto:[mailto:Robby.Pelssers@nxp.com]>
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Robby Pelssers <Ro...@nxp.com>.
I'm not really that familiar with the building of Cocoon2.1.x apps but shouldn't there be some blocks.properties (not 100% sure about the name) file used by ant where you can determine which blocks you want to include?  That would be a good starting point to compare with the default one.

By the way, I noticed that the last modified timestamps were very similar, as if the Dspace jar was from a scheduled build from another day.
Regular cocoon jar : 4/12/2006 12:56 PM
DSpace jar: 4/11/2006 12:56 PM

Can you also explain what the point is of this exercise?  You don't have the sources used to build the DSpace.jar in some source repository?

Kind regards,
Robby
From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Thursday, December 08, 2011 10:43 PM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu); Scott Phillips (scott.a.phillips@gmail.com)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by "DeVries, Joe" <jo...@austin.utexas.edu>.
Hi Robby,

I ran Java Decompiler on both jars and compared the resulting files.  Unfortunately there are over 600 differences (see attached list), with oddities such as:

cocoon-2.1.9.src\org\apache\cocoon\Cocoon.java cocoon:
boolean result = this.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\apache\cocoon\Cocoon.java:
result = this.threadSafeProcessor.process(environment);

However, I don't know very much about decompiling, so maybe these are misleading results.

There are also 6 new classes in the DSpace version:
org\apache\cocoon\components\flow\javascript\fom \CompilingClassLoader$1.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$2.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$3.java
org\apache\cocoon\components\flow\javascript\fom\ CompilingClassLoader$4.java
org\apache\cocoon\generation\ JXTemplateGenerator$3.java
org\apache\cocoon\transformation\IncludeTransformer$1.java

I was going to look into a tool like clirr to check for binary compatibility and see if that can narrow down any differences.

Joe

--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477

From: Robby Pelssers [mailto:Robby.Pelssers@nxp.com]
Sent: Thursday, December 08, 2011 2:39 PM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu)
Subject: RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]<mailto:[mailto:joe.devries@austin.utexas.edu]>
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org<ma...@cocoon.apache.org>
Cc: Sands Alden Fish (sands@mit.edu<ma...@mit.edu>)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477


RE: Determining blocks specified for building an existing cocoon 2.1.9 jar

Posted by Robby Pelssers <Ro...@nxp.com>.
I unpacked both jar files with winrar and noticed some differences in size for a few files.  One of those files is cocoon.roles for example.

I suggest you take the same approach and find out by using some compare tool to find the exact differences.

Kind regards.
Robby Pelssers

From: DeVries, Joe [mailto:joe.devries@austin.utexas.edu]
Sent: Thursday, December 08, 2011 9:25 PM
To: dev@cocoon.apache.org
Cc: Sands Alden Fish (sands@mit.edu)
Subject: Determining blocks specified for building an existing cocoon 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.  The custom jar has a different size and checksum from the 'official' cocoon-2.0.9.jar, and I don't believe that there were and changes to the source code.  It was likely built with certain blocks included/excluded.
Is it possible to somehow determine which blocks were included/excluded at build time by looking at an existing jar file?

http://repo1.maven.org/maven2/org/dspace/xmlui/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar
md5: 8f4d38294286cb550a2262720833fb55

http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/cocoon-2.1.9.jar<http://mirrors.ibiblio.org/pub/mirrors/maven2/cocoon/cocoon/2.1.9/>
md5: 1d80a0a9ed50764c06b664427a2d5098


Thanks,
Joe DeVries


--
Joe DeVries
Sr Software Developer/Analyst
Digital Library Services, TDL
University of Texas at Austin
512-495-4639
PCL 1.335 / S5477