cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morten Ludvigsen <>
Subject Re: [proposal] a new kind of 'dist'
Date Tue, 25 Mar 2003 18:56:11 GMT
Hi, sorry to butt in like this, but I am a newcomer to Cocoon, and I 
must say I am a bit worried by this suggestion. Trying to build Cocoon 
2.1 dev on my W2K work station has proved a bit of a head ache. I have 
checked the newest version from CVS to C:\Src\new_cocoon-2.1 on my 
machine. When I try to build, it crashes when it reaches javadocs (see 
below). After trying a lot of different things, I came up with the wild 
idea that maybe a command line was getting too long. I then did "SUBST 
X: C:\Src\new_cocoon-2.1" switched to the new X: drive, and hey presto - 
it worked. What I think this story illustrates is that building from 
source can be a barrier to some people (if I hadn't seen the 2.04 WAR 
first I might have given up). The barrier might not even be something 
you guys are aware of, and a lot of people may just pass Cocoon by after 
trying to build once - and failing. I know it is not Cocoon's failing, 
but something in my setup (any suggestions would be welcome :-) By 
supplying a binary distribution you can remove one point of possible 

Just my 2 øre (well that's what we use in Denmark :-)


Morten Ludvigsen
2-People Software

Output from build (CVS from a couple of hours ago):
Created dir: C:\Src\new_cocoon-2.1\build\cocoon-2.1-dev\javadocs

Generating Javadoc
Javadoc execution

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x706F5C62

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.

Current Java thread:
    at java.lang.Win32Process.create(Native Method)
    at java.lang.Win32Process.<init>(
    at java.lang.Runtime.execInternal(Native Method)
    at java.lang.Runtime.exec(
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.lang.reflect.Method.invoke(

Dynamic libraries:
0x00400000 - 0x00406000     C:\j2sdk1.4.1_02\bin\java.exe
0x77F80000 - 0x77FFB000     C:\WINNT\system32\ntdll.dll
0x77DB0000 - 0x77E0B000     C:\WINNT\system32\ADVAPI32.dll
0x77E80000 - 0x77F34000     C:\WINNT\system32\KERNEL32.dll
0x77120000 - 0x77191000     C:\WINNT\system32\RPCRT4.dll
0x78000000 - 0x78046000     C:\WINNT\system32\MSVCRT.dll
0x6D340000 - 0x6D46A000     C:\j2sdk1.4.1_02\jre\bin\client\jvm.dll
0x77E10000 - 0x77E6F000     C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F79000     C:\WINNT\system32\GDI32.dll
0x77550000 - 0x77581000     C:\WINNT\System32\WINMM.dll
0x10000000 - 0x100A0000     C:\WINNT\System32\scorillont.dll
0x00840000 - 0x00870000     C:\WINNT\System32\scorsock.dll
0x6D1E0000 - 0x6D1E7000     C:\j2sdk1.4.1_02\jre\bin\hpi.dll
0x6D310000 - 0x6D31E000     C:\j2sdk1.4.1_02\jre\bin\verify.dll
0x6D220000 - 0x6D239000     C:\j2sdk1.4.1_02\jre\bin\java.dll
0x6D330000 - 0x6D33D000     C:\j2sdk1.4.1_02\jre\bin\zip.dll
0x77920000 - 0x77943000     C:\WINNT\system32\imagehlp.dll
0x729B0000 - 0x729DD000     C:\WINNT\system32\DBGHELP.dll
0x68FF0000 - 0x68FFB000     C:\WINNT\System32\PSAPI.DLL

Local Time = Tue Mar 25 19:12:54 2003
Elapsed Time = 437
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode)
# An error report file has been saved as hs_err_pid1416.log.
# Please refer to the file for further information.

Stefano Mazzocchi wrote:

> In the beginning, there was only one cocoon distribution, packaged 
> with two different packagers (zip for windows and tar.gz for unix and 
> friends).
> Then cocoon became very complex and we decided to create a binary 
> distribution to make things easier. Things were indeed easier for new 
> users to install and try out, but it was harder for them to actually 
> *do* something with cocoon and tune it for their needs.
> The fact that there is even a sourceforge project about a 'clean' 
> version of our shipped cocoon WAR feels a little like a slap in our face.
> Then the 1.3/1.4 JDBC incompatibilities came out, forcing us to do two 
> different binary releases.
> Now, in the light of a cleaned-up build system and a 
> very-well-factored-out static block architecture and the inclusion of 
> a super light-weight servlet container, I think we are ready to 
> finally go back to where we started and stop releasing binaries.
> Before you jump up and down and scream "no, no, binaries are easier 
> for our users", get off your 
> life-without-a-compiler-windows-inflicted-mindset and think that every 
> JDK comes with a compiler.
> To be really honest, Cocoon already includes not one but *TWO* java 
> compilers!!! we could build from javawebstart if we really wanted to! 
> (we should also decide if we want to remove pizza from the distribution!)
> So, in light of the good old triad
>  ./configure; make; make install
> I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of 
> our current CVS and improve a little the 'INSTALL.txt' doc that will 
> suggest you to do
>  $> ./
>  $> ./ servlet
> and voila', that was it! or, if you really want to deploy stuff into 
> your wervlet container do a simple
>  $> ./ war
> and you are done.
> And next step, when you want to tune your distribution for your needs 
> simply do
>  $> cp
>  $> cp
> then edit them, then
>  $> ./ clean
>  $> ./
>  $> ./ servlet-admin &
> so you can start/stop/restart your cocoon without having to star/stop 
> jetty from the command line.
> What do you think?
> Stefano.

View raw message