Just my 2 øre (well that's what we use in Denmark :-)
Regards,
Morten Ludvigsen 2-People Software
Output from build (CVS from a couple of hours ago): ... javadocs-check: Created dir: C:\Src\new_cocoon-2.1\build\cocoon-2.1-dev\javadocs
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 Function=[Unknown.] Library=(N/A)
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>(Win32Process.java:63)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Runtime.java:566)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec(Execute.java:650)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:420)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:431)
at org.apache.tools.ant.taskdefs.Javadoc.execute(Javadoc.java:1835)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:227)
at org.apache.tools.ant.Task.perform(Task.java:388)
at org.apache.tools.ant.Target.execute(Target.java:309)
at org.apache.tools.ant.Target.performTasks(Target.java:336)
at org.apache.tools.ant.Project.executeTarget(Project.java:1389)
at org.apache.tools.ant.Project.executeTargets(Project.java:1263)
at org.apache.tools.ant.Main.runBuild(Main.java:611)
at org.apache.tools.ant.Main.start(Main.java:198)
at org.apache.tools.ant.Main.main(Main.java:245)
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
$> ./build.sh $> ./cocoon.sh servlet
and voila', that was it! or, if you really want to deploy stuff into your wervlet container do a simple
$> ./build.sh war
and you are done.
And next step, when you want to tune your distribution for your needs simply do
$> cp build.properties local.build.properties $> cp blocks.properties local.blocks.properties
then edit them, then
$> ./build.sh clean $> ./build.sh $> ./servlet.sh 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.
