The application is mis= sion 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 no= t be a viable option.

Thanks Again,

Joe

Joe DeVries

Sr Software Developer/Analy= st

Digital Library Services, T= DL

University of Texas at Aust= in

512-495-4639

PCL 1.335 / S5477

From: Robby Pe= lssers [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.philli= ps@gmail.com)
Subject: RE: Determining blocks specified for building an existing c= ocoon 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 wi= th the newer versions even more and even I am planning to switch from Cocoo= n2.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 con= sider moving to C2 or higher there might be more response to help out. &nbs= p; If this is impossible maybe some die hard ‘Cocoon 2.1.x’= ; people can give more help.

Robby

From: DeVries,= Joe [mailto:joe.devri= es@austin.utexas.edu]
Sent: Friday, December 09, 2011 3:19 PM
To: Robby Pelssers; dev@coc= oon.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 c= ocoon 2.1.9 jar

Hi Robby,

Regarding my objective= , we have an application which relies on an old version of DSpace. DS= pace 1.5.1 uses the custom cocoon jar for which we no longer have the sourc= e, 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 wo= rks.

Thanks for looking int= o it, I appreciate your help.

Joe<= /p>

Joe DeVries

Sr Software Developer/Analy= st

Digital Library Services, T= DL

University of Texas at Aust= in

512-495-4639

PCL 1.335 / S5477

From: Robby Pe= lssers [mailto:Robby.Pelssers@n= xp.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 c= ocoon 2.1.9 jar

I’m not really t= hat familiar with the building of Cocoon2.1.x apps but shouldn’t ther= e 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 def= ault one.

By the way, I noticed = that the last modified timestamps were very similar, as if the Dspace jar w= as 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 w= hat the point is of this exercise? You don’t have the sources u= sed to build the DSpace.jar in some source repository?

Kind regards,

Robby

From: DeVries,= Joe [mailto:joe.devri= es@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 c= ocoon 2.1.9 jar

Hi Robby,

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

cocoon-2.1.9.src\org\a= pache\cocoon\Cocoon.java cocoon:

boolean result =3D thi= s.threadSafeProcessor.process(environment);

dspace -2.1.9.src\org\= apache\cocoon\Cocoon.java:

result =3D this.thread= SafeProcessor.process(environment);

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

There are also 6 new c= lasses 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<= /span>

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

Joe<= /p>

Joe DeVries

Sr Software Developer/Analy= st

Digital Library Services, T= DL

University of Texas at Aust= in

512-495-4639

PCL 1.335 / S5477

From: Robby Pe= lssers [mailto:Robby.Pelssers@n= xp.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 c= ocoon 2.1.9 jar

I unpacked both jar fi= les 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 di= fferences.

Kind regards.

Robby Pelssers

From: DeVries,= Joe [mailto:joe.devri= es@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 cocoo= n 2.1.9 jar

Hello,

I am trying to recreate a custom built Cocoon 2.1.9 jar used by DSpace.&nbs= p; The custom jar has a different size and checksum from the ‘officia= l’ 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 som= ehow 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/cocoo= n-2.1.9.jar
md5: 1d80a0a9ed50764c06b664427a2d5098

Thanks,
Joe DeVries

Joe DeVries

Sr Software Developer/Analyst<= /span>

Digital Library Services, TDL<= /span>

University of Texas at Austin<= /span>

512-495-4639

PCL 1.335 / S5477