I'm trying to build Railo from source and I keep getting an error.
I downloaded the latest version from Github (3.3.2.003) and am trying to build it with JDK1.6.0_31
the error I'm getting is *cannot find symbol**: class ByteInputStream*
(I tried with JDK1.5 also, just in case, I get there another error which makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
is that a classpath issue?
any ideas?
Buildfile: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-master\build.xml init: [echo] ***** Start Railo build process. ***** clean: [echo] Deleting build and dist [delete] Deleting directory F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\build [delete] Deleting directory F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\dist getInfo: [echo] Extracting version information from file src/railo/runtime/Info.ini [echo] Version is: 3.3.2.003.rc clean: [echo] Deleting build and dist [delete] Deleting directory F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\build [delete] Deleting directory F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\dist clean: [echo] Deleting build and dist master: [echo] ***** Building railo-loader.jar ***** clean: [echo] Deleting build and dist init: [echo] Creating the build and dist directories. [mkdir] Created dir: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\build\classes [mkdir] Created dir: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\dist compile: [echo] Compile the RailoLoader src. [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\build.xml:36: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 192 source files to F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\build\classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. package: [echo] Packaging the railo-loader.jar file. [jar] Building jar: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-loader\dist\railo-loader.jar install: [echo] Copy the railo-loader.jar to the Railo core lib directory. [copy] Copying 1 file to F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\libs [echo] ***** Building Railo core.rc ***** getInfo: [echo] Extracting version information from file src/railo/runtime/Info.ini [echo] Version is: 3.3.2.003.rc clean: [echo] Deleting build and dist init: [echo] Creating the build, admin and dist directories. [mkdir] Created dir: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\build\classes [mkdir] Created dir: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\build\admin [mkdir] Created dir: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\dist compile: [echo] Compile Railo src. [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\build.xml:57: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 2306 source files to F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\build\classes [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\src\railo\runtime\instrumentat ion\InstrumentationFactory.java:17: warning: sun.management.VMManagement is Sun proprietary API and may be removed in a future release [javac] import sun.management.VMManagement; [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\src\railo\runtime\text\pdf\PDF Document.java:35: package com.sun.xml.internal.messaging.saaj.util does not exist [javac] import com.sun.xml.internal.messaging.saaj.util.ByteInputStream; [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\src\railo\runtime\instrumentat ion\InstrumentationFactory.java:121: warning: sun.management.VMManagement is Sun proprietary API and may be removed in a future release [javac] VMManagement management = (VMManagement) jvmField.get(mxbean); [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\src\railo\runtime\instrumentat ion\InstrumentationFactory.java:121: warning: sun.management.VMManagement is Sun proprietary API and may be removed in a future release [javac] VMManagement management = (VMManagement) jvmField.get(mxbean); [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-core\src\railo\runtime\reflection\I nvoker.java:308: warning: non-varargs call of varargs method with inexact argument type for last parameter; [javac] cast to java.lang.Object for a varargs call [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [javac] return m.invoke(o,null); [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\ *railo-java\railo-core\src\railo\runtime\text\pdf\PDFDocument.java:381: cannot find symbol* [javac] *symbol : class ByteInputStream* [javac] location: class railo.runtime.text.pdf.PDFDocument [javac] doc= PDDocument.load(new ByteInputStream(barr,0,barr.length)); [javac] ^ [javac] F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\ *railo-java\railo-core\src\railo\runtime\text\pdf\PDFDocument.java:385: cannot find symbol* [javac] *symbol : class ByteInputStream* [javac] location: class railo.runtime.text.pdf.PDFDocument [javac] doc= PDDocument.load(new ByteInputStream(IOUtil.toBytes(resource),0,barr.length)); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 3 errors [javac] 4 warnings
*BUILD FAILED* F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\railo-java\railo-master\build.xml:25: The following error occurred while executing this line: F:\Users\Admin\Downloads\dev-21solutions-railo-3.3.2.003-0-g28b7a39\dev-21s olutions-railo-28b7a39\ *railo-java\railo-core\build.xml:57: Compile failed; see the compiler error output for details*.
Total time: 15 seconds
line railo-core\build.xml:57 is the javac command and reads as follows:
thanks for your reply. I get an error from your build script. output below.
Igal
railobuild menu
1. Build Railo 2. Build and Test 3. List available targets 4. Update project 5. Run Target 6. Quit
Enter option 1, 2, 3, 4, 5 or 6 : 1
BUILD FAILED F:\Users\Admin\Downloads\denuno-railobuild-65f3332\denuno-railobuild-65f333 2\bui ld\build.xml:52: The following error occurred while executing this line: F:\Users\Admin\Downloads\denuno-railobuild-65f3332\denuno-railobuild-65f333 2\bui ld\util\zbuild.xml:69: Unable to load a script engine manager (org.apache.bsf.BS FManager or javax.script.ScriptEngineManager)
Total time: 0 seconds
Buildfile: F:\Users\Admin\Downloads\denuno-railobuild-65f3332\denuno-railobuild-65f333 2\build\build.xml [propertyfile] Updating property file: F:\Users\Admin\Downloads\denuno-railobuild-65f3332\denuno-railobuild-65f333 2\build\buildinfo.properties [echo] 2012/02/26 11:24:11 Trying to override old definition of task classloader
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable explicitly and ran the ant build from that command window.
>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
Looks like a JDK issue. Are you sure you were using 1.6? It can be
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
On Sunday, February 26, 2012 11:13:24 PM UTC-8, Denny Valliant wrote:
> On 2/26/12 10:48 PM, Igal wrote: > > I'm trying to build Railo from source and I keep getting an error.
> > I downloaded the latest version from Github (3.3.2.003) and am trying to > > build it with JDK1.6.0_31
> > the error I'm getting is *cannot find symbol**: class ByteInputStream*
> > (I tried with JDK1.5 also, just in case, I get there another error which > > makes sense as Railo3.3 should be compiled with JDK1.6 as far as I know)
> > is that a classpath issue?
> > any ideas?
> Looks like a JDK issue. Are you sure you were using 1.6? It can be > kind of hard to determine sometimes.
> p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > explicitly and ran the ant build from that command window.
>>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
Well poop on a stake! (to turn a phrase ;]) I was hoping that would "just work" for ya. :(
It works for me on OS X and, last I tried, Ubuntu & Windows. And that error looks like it can't find the js.jar that is there in the build/ant/lib folder... gah.
Got any details on your environment that might help me finger it out?
I'm not sure what is going on (which isn't unusual, but still). =]
oops. sorry. the JDK1.6 statement below was with regards to your original question.
when I was about to reply to this one I realized that I should set the JAVA_HOME to 1.6 for your build as well -- so I did -- and now it's running (currently in JGit step).
thanks again :)
ideally though, I'd like to be able to build the project in Eclipse so if you (or anyone) has an idea why I get the original error I reported it'd be great.
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that > error looks like it can't find the js.jar that is there in the > build/ant/lib folder... gah.
> Got any details on your environment that might help me finger it out?
> I'm not sure what is going on (which isn't unusual, but still). =]
On Monday, February 27, 2012 12:10:02 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 12:40 AM, Igal wrote: > > p.s. -- I'm pretty sure the JDK is 1.6 -- after failing to build in > > Eclipse EE, I opened a command prompt, set the %JAVA_HOME% variable > > explicitly and ran the ant build from that command window.
> >>echo %java_home% outputs the correct value of: C:\Java\jdk1.6.0_31
> Well poop on a stake! (to turn a phrase ;]) I was hoping that would > "just work" for ya. :(
> It works for me on OS X and, last I tried, Ubuntu & Windows. And that
> oops. sorry. the JDK1.6 statement below was with regards to your > original question.
> when I was about to reply to this one I realized that I should set the > JAVA_HOME to 1.6 for your build as well -- so I did -- and now it's > running (currently in JGit step).
Grrr! I have a whole little segment in there that's supposed to say "hey, this needs java version X", X being whatever version is needed for the build (we'll be running into this with 7 soon enough).
> thanks again :)
Thanks for trying it!
> ideally though, I'd like to be able to build the project in Eclipse so > if you (or anyone) has an idea why I get the original error I reported > it'd be great.
It totally rings a bell, but sadly that bell is "incorrect java version", which perhaps is the wrong bell.
ok, thank you. I will try to play with it some more.
your script worked really well. it'd be nice if the build script (and doc) in the main projects could be improved.
as a matter of fact my main purpose in trying to build this in Eclipse was so that I can improve the docs on building from source.
also, it'd be nice if branch 3.2 could be removed from Github and then we'll know that JDK1.6 is the only version we need (until Railo Apollo, of course)
On Monday, February 27, 2012 1:07:15 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 1:29 AM, Igal wrote: > > oops. sorry. the JDK1.6 statement below was with regards to your > > original question.
> > when I was about to reply to this one I realized that I should set the > > JAVA_HOME to 1.6 for your build as well -- so I did -- and now it's > > running (currently in JGit step).
> Grrr! I have a whole little segment in there that's supposed to say > "hey, this needs java version X", X being whatever version is needed for > the build (we'll be running into this with 7 soon enough).
> > thanks again :)
> Thanks for trying it!
> > ideally though, I'd like to be able to build the project in Eclipse so > > if you (or anyone) has an idea why I get the original error I reported > > it'd be great.
> It totally rings a bell, but sadly that bell is "incorrect java > version", which perhaps is the wrong bell.
On Monday, February 27, 2012 1:07:15 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 1:29 AM, Igal wrote: > > oops. sorry. the JDK1.6 statement below was with regards to your > > original question.
> > when I was about to reply to this one I realized that I should set the > > JAVA_HOME to 1.6 for your build as well -- so I did -- and now it's > > running (currently in JGit step).
> Grrr! I have a whole little segment in there that's supposed to say > "hey, this needs java version X", X being whatever version is needed for > the build (we'll be running into this with 7 soon enough).
> > thanks again :)
> Thanks for trying it!
> > ideally though, I'd like to be able to build the project in Eclipse so > > if you (or anyone) has an idea why I get the original error I reported > > it'd be great.
> It totally rings a bell, but sadly that bell is "incorrect java > version", which perhaps is the wrong bell.
> ok, thank you. I will try to play with it some more.
> your script worked really well. it'd be nice if the build script (and > doc) in the main projects could be improved.
That's the idea. What did you think of the README? Feel free to fork/edit it if you want!
I'd love to add an Eclipse portion, covering the debug-runner as well. There's nothing like being able to click on a stack trace and have it open the source file in the editor. :) I think we should have a video of the whole process too.
> as a matter of fact my main purpose in trying to build this in Eclipse > was so that I can improve the docs on building from source.
> also, it'd be nice if branch 3.2 could be removed from Github and then > we'll know that JDK1.6 is the only version we need (until Railo Apollo, > of course)
It is standard to keep at least tags of the various versions so that people who (for whatever reason) are on older versions can see what is going on in the version they're using. I know it seems silly that it could be the case with an open source project which is so easy to update, but there are reasons (usually involving management ;)).
your build script is really cool. I was especially impressed with the use of Jetty-Runner as opposed to running Jetty in a whole separate process.
the README is good albeit a little advanced. maybe after I get a better understanding of that build process I will have some suggestions for changes, but for the time being it seems pretty good.
being able to debug in an IDE like you suggested would be awesome! and there's definitely room for video tutorials. I was thinking of creating some myself and hopefully will get to that at some point in the near future.
so is this build project planned to go into the main Railo project on Github?
can it be used to build from local folders? say that I make some changes to code locally and then want to build it, is it possible with these scripts?
On Monday, February 27, 2012 11:58:18 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 11:11 AM, Igal wrote: > > ok, thank you. I will try to play with it some more.
> > your script worked really well. it'd be nice if the build script (and > > doc) in the main projects could be improved.
> That's the idea. What did you think of the README? Feel free to > fork/edit it if you want!
> I'd love to add an Eclipse portion, covering the debug-runner as well. > There's nothing like being able to click on a stack trace and have it > open the source file in the editor. :) I think we should have a video > of the whole process too.
> > as a matter of fact my main purpose in trying to build this in Eclipse > > was so that I can improve the docs on building from source.
> > also, it'd be nice if branch 3.2 could be removed from Github and then > > we'll know that JDK1.6 is the only version we need (until Railo Apollo, > > of course)
> It is standard to keep at least tags of the various versions so that > people who (for whatever reason) are on older versions can see what is > going on in the version they're using. I know it seems silly that it > could be the case with an open source project which is so easy to > update, but there are reasons (usually involving management ;)).
On Monday, February 27, 2012 11:58:18 AM UTC-8, Denny Valliant wrote:
> On 2/27/12 11:11 AM, Igal wrote: > > ok, thank you. I will try to play with it some more.
> > your script worked really well. it'd be nice if the build script (and > > doc) in the main projects could be improved.
> That's the idea. What did you think of the README? Feel free to > fork/edit it if you want!
> I'd love to add an Eclipse portion, covering the debug-runner as well. > There's nothing like being able to click on a stack trace and have it > open the source file in the editor. :) I think we should have a video > of the whole process too.
> > as a matter of fact my main purpose in trying to build this in Eclipse > > was so that I can improve the docs on building from source.
> > also, it'd be nice if branch 3.2 could be removed from Github and then > > we'll know that JDK1.6 is the only version we need (until Railo Apollo, > > of course)
> It is standard to keep at least tags of the various versions so that > people who (for whatever reason) are on older versions can see what is > going on in the version they're using. I know it seems silly that it > could be the case with an open source project which is so easy to > update, but there are reasons (usually involving management ;)).
> your build script is really cool. I was especially impressed with the > use of Jetty-Runner as opposed to running Jetty in a whole separate process.
Thanks! I love jetty-runner! I slathered it with error checks to try to avoid "ghost processes" if there is a build failure in that portion of code, to make CI more bulletproof.
> the README is good albeit a little advanced. maybe after I get a better > understanding of that build process I will have some suggestions for > changes, but for the time being it seems pretty good.
Rock'n. Contributions are always welcome! The complete picture is too big to fit in one page, I think we'll need to break the bits down and use an index of topics, which we should pull from the wiki maybe (or at least link up the content w/docs in github).
> being able to debug in an IDE like you suggested would be awesome! and > there's definitely room for video tutorials. I was thinking of creating > some myself and hopefully will get to that at some point in the near future.
> so is this build project planned to go into the main Railo project on > Github?
That's the idea. We want it to be as painless as possible to get from nothing, to pull requests. :)
> can it be used to build from local folders? say that I make some > changes to code locally and then want to build it, is it possible with > these scripts?
Totally! To be safe, commit your changes locally before running a build, so they will be there even if you do a "forced checkout" (happens when you specify a different branch or tag to build). The plain "build" command won't check out anything if the source is already there (thus builds after that first build are *much* faster =]).
I guess I will have to sharpen my Git skills before I can use it though.
as for my original problem here -- I have Uninstalled (and deleted all registry entries of) all other versions of JDK/JRE and the only thing left on my machine (Windows 7 32bit) is JDK1.6.0_31 -- to ensure that I'm using the correct JDK. I am still getting the same error.
so I did some digging, and the class in question is: * com.sun.xml.internal.messaging.saaj.util.ByteInputStream* ( http://www.docjar.com/html/api/com/sun/xml/internal/messaging/saaj/ut...) -- the weird part is that class is part of the runtime (rt.jar) of the JDK/JRE and it Does exist on my machine in %Java%\jre\live\rt.jar
looking deeper into that class, it looks like it's just a thin wrapper around java.io.ByteArrayInputStream, so I opened up the only class that uses this one: *railo.runtime.text.pdf.PDFDocument* and replaced * ByteInputStream* with *ByteArrayInputStream*
*line 35-: import com.sun.xml.internal.messaging.saaj.util.ByteInputStream; line 35+: import java.io.ByteArrayInputStream;
line 381-: doc= PDDocument.load(new ByteInputStream (barr,0,barr.length)); line 381+: doc= PDDocument.load(new ByteArrayInputStream(barr,0,barr.length));
line 385-: doc= PDDocument.load(new ByteInputStream (IOUtil.toBytes(resource),0,barr.length)); line 385+: doc= PDDocument.load(new ByteArrayInputStream** (IOUtil.toBytes(resource),0,barr.length));*
*and now the project builds!*
am I the only one this happens to? any idea why this would happen? weird...
On Monday, February 27, 2012 12:51:01 PM UTC-8, Denny Valliant wrote:
> On 2/27/12 1:26 PM, Igal wrote: > > your build script is really cool. I was especially impressed with the > > use of Jetty-Runner as opposed to running Jetty in a whole separate > process.
> Thanks! I love jetty-runner! I slathered it with error checks to try > to avoid "ghost processes" if there is a build failure in that portion > of code, to make CI more bulletproof.
> > the README is good albeit a little advanced. maybe after I get a better > > understanding of that build process I will have some suggestions for > > changes, but for the time being it seems pretty good.
> Rock'n. Contributions are always welcome! The complete picture is too > big to fit in one page, I think we'll need to break the bits down and > use an index of topics, which we should pull from the wiki maybe (or at > least link up the content w/docs in github).
> > being able to debug in an IDE like you suggested would be awesome! and > > there's definitely room for video tutorials. I was thinking of creating > > some myself and hopefully will get to that at some point in the near > future.
> > so is this build project planned to go into the main Railo project on > > Github?
> That's the idea. We want it to be as painless as possible to get from > nothing, to pull requests. :)
> > can it be used to build from local folders? say that I make some > > changes to code locally and then want to build it, is it possible with > > these scripts?
> Totally! To be safe, commit your changes locally before running a > build, so they will be there even if you do a "forced checkout" (happens > when you specify a different branch or tag to build). The plain "build" > command won't check out anything if the source is already there (thus > builds after that first build are *much* faster =]).
On Monday, February 27, 2012 12:51:01 PM UTC-8, Denny Valliant wrote:
> On 2/27/12 1:26 PM, Igal wrote: > > your build script is really cool. I was especially impressed with the > > use of Jetty-Runner as opposed to running Jetty in a whole separate > process.
> Thanks! I love jetty-runner! I slathered it with error checks to try > to avoid "ghost processes" if there is a build failure in that portion > of code, to make CI more bulletproof.
> > the README is good albeit a little advanced. maybe after I get a better > > understanding of that build process I will have some suggestions for > > changes, but for the time being it seems pretty good.
> Rock'n. Contributions are always welcome! The complete picture is too > big to fit in one page, I think we'll need to break the bits down and > use an index of topics, which we should pull from the wiki maybe (or at > least link up the content w/docs in github).
> > being able to debug in an IDE like you suggested would be awesome! and > > there's definitely room for video tutorials. I was thinking of creating > > some myself and hopefully will get to that at some point in the near > future.
> > so is this build project planned to go into the main Railo project on > > Github?
> That's the idea. We want it to be as painless as possible to get from > nothing, to pull requests. :)
> > can it be used to build from local folders? say that I make some > > changes to code locally and then want to build it, is it possible with > > these scripts?
> Totally! To be safe, commit your changes locally before running a > build, so they will be there even if you do a "forced checkout" (happens > when you specify a different branch or tag to build). The plain "build" > command won't check out anything if the source is already there (thus > builds after that first build are *much* faster =]).
On Monday, February 27, 2012 12:51:01 PM UTC-8, Denny Valliant wrote:
> On 2/27/12 1:26 PM, Igal wrote: > > your build script is really cool. I was especially impressed with the > > use of Jetty-Runner as opposed to running Jetty in a whole separate > process.
> Thanks! I love jetty-runner! I slathered it with error checks to try > to avoid "ghost processes" if there is a build failure in that portion > of code, to make CI more bulletproof.
> > the README is good albeit a little advanced. maybe after I get a better > > understanding of that build process I will have some suggestions for > > changes, but for the time being it seems pretty good.
> Rock'n. Contributions are always welcome! The complete picture is too > big to fit in one page, I think we'll need to break the bits down and > use an index of topics, which we should pull from the wiki maybe (or at > least link up the content w/docs in github).
> > being able to debug in an IDE like you suggested would be awesome! and > > there's definitely room for video tutorials. I was thinking of creating > > some myself and hopefully will get to that at some point in the near > future.
> > so is this build project planned to go into the main Railo project on > > Github?
> That's the idea. We want it to be as painless as possible to get from > nothing, to pull requests. :)
> > can it be used to build from local folders? say that I make some > > changes to code locally and then want to build it, is it possible with > > these scripts?
> Totally! To be safe, commit your changes locally before running a > build, so they will be there even if you do a "forced checkout" (happens > when you specify a different branch or tag to build). The plain "build" > command won't check out anything if the source is already there (thus > builds after that first build are *much* faster =]).
> am I the only one this happens to? any idea why this would happen? > weird...
Ah! Now I remember that one (I think).
Which makes it even odder, because the problem is that the class in question is an internal Sun class, which Eclipse doesn't have trouble including (one of the reasons I like ECJ), but that Sun compilers can have trouble including (and not always) because it doesn't import correctly (and again, not always *shrug*).
Are you using custom compiler options in Eclipse? Maybe specified the Sun compiler (javac) instead of the Eclipse compiler (ECJ)?
I think that would explain the troubles, and why the new build script worked where the old one didn't (old one uses javac by default, though you can configure Ant to use ECJ with some compiler properties).
For giggles, you could try importing the Railo projects into a new Eclipse workspace, and see if things compile using the defaults... or maybe just check your build options, and see what it's using now.
I don't think that I specified explicitly the Sun compiler, but anything is possible. especially since it didn't work from the beginning and I started tweaking things in an attempt to "fix" it. I'm learning how to use Eclipse as I go (personally prefer NetBeans).
I tried creating a new workspace and importing the projects there. this time, unlike before, I checked the box that reads "copy projects". after fixing the build-paths I had to manually copy the libs folder (I guess it's specified in the build script). this time it worked like you suggested.
the question is that if the * com.sun.xml.internal.messaging.saaj.util.ByteInputStream* doesn't do much, and the *PDDocument.load( InputStream in )* doesn't care for the implementation -- maybe changing to *java.io.ByteArrayInputStream* will solve similar problems in the future. probably a question for Michael? maybe I'll open a ticket in the JIRA.
anyway, thank you Denny, you've been a great help. I owe you a beer (more like a six pack by now).
On Monday, February 27, 2012 6:11:59 PM UTC-8, Denny Valliant wrote:
> On 2/27/12 5:59 PM, Igal wrote: > ... > > am I the only one this happens to? any idea why this would happen? > > weird...
> Ah! Now I remember that one (I think).
> Which makes it even odder, because the problem is that the class in > question is an internal Sun class, which Eclipse doesn't have trouble > including (one of the reasons I like ECJ), but that Sun compilers can > have trouble including (and not always) because it doesn't import > correctly (and again, not always *shrug*).
> Are you using custom compiler options in Eclipse? Maybe specified the > Sun compiler (javac) instead of the Eclipse compiler (ECJ)?
> I think that would explain the troubles, and why the new build script > worked where the old one didn't (old one uses javac by default, though > you can configure Ant to use ECJ with some compiler properties).
> For giggles, you could try importing the Railo projects into a new > Eclipse workspace, and see if things compile using the defaults... or > maybe just check your build options, and see what it's using now.
