cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morten Ludvigsen <mor...@2ps.dk>
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 
failure.

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.
>
>



Mime
View raw message