Nothing I can see has changed, this one is absolutely up-to-date Ubuntu 9.04 following apt-get update and upgrade after starting up a fresh image.
Then: apt-get install subversion apt-get install maven2 apt-get install jetty Then: svn checkout http://svn.apache.org/repos/asf/incubator/esme/trunk esme Then fixing the two files. Then problem :) Now: rm -rf esme and started over One never knows where I could have messed up, only mishap was that I lost contact with the server at some point during first mvn... so now I did & and logged out leaving it alone... lets see now: Nope, exact same error. Noticed that it starts saying compiling 49 packages, then dies after a bit, and when trying again it says compiling 8 packages. No other clues. 2010/1/26 Richard Hirsch <[email protected]>: > RE plug-in: I remember. > > I think something else (Scala, lift, etc.) might have changed. Has anything > else changed in the environment? > > It is all very strange. It is obviously a maven-related problem, because > ESME's code hasn't really changed at all in the last few weeks. > > On Tue, Jan 26, 2010 at 2:51 PM, Sig Rinde <[email protected]> wrote: > >> Then I get this: >> >> [ERROR] FATAL ERROR >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] null >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Trace >> java.lang.RuntimeException >> at >> com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299) >> at >> com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335) >> at >> com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:532) >> at >> net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCompressorMojo.java:178) >> at >> net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir(MojoSupport.java:151) >> >> BTW, it was you who suggested doing this last time, and then all was >> ok for basically same setup (that was Jan 5th) :) >> >> >> 2010/1/26 Richard Hirsch <[email protected]>: >> > what happens if you don't comment out the plug-in >> > >> > On Tue, Jan 26, 2010 at 2:25 PM, Sig Rinde <[email protected]> wrote: >> > >> >> Ethan, >> >> >> >> this is a completely new install so I'm using "mvn jetty:run" >> >> >> >> Prior to that: >> >> 1. svn the full esme >> >> 2. add line to default.props >> >> 3. comment out plugin in pom.xml >> >> >> >> using -e gave this at the end: >> >> >> >> [INFO] Trace >> >> org.apache.maven.BuildFailureException: command line returned non-zero >> >> value:1 >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:924) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:767) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:529) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) >> >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >> >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) >> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> >> at >> >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:616) >> >> at >> >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >> >> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >> >> at >> >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >> >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> >> Caused by: org.apache.maven.plugin.MojoFailureException: command line >> >> returned non-zero value:1 >> >> at org.scala_tools.maven.JavaCommand.run(JavaCommand.java:196) >> >> at >> >> >> org.scala_tools.maven.ScalaCompilerSupport.compile(ScalaCompilerSupport.java:124) >> >> at >> >> >> org.scala_tools.maven.ScalaCompilerSupport.doExecute(ScalaCompilerSupport.java:54) >> >> at >> >> >> org.scala_tools.maven.ScalaMojoSupport.execute(ScalaMojoSupport.java:208) >> >> at >> >> >> org.scala_tools.maven.ScalaCompilerSupport.execute(ScalaCompilerSupport.java:29) >> >> at >> >> >> org.scala_tools.maven.ScalaTestCompileMojo.execute(ScalaTestCompileMojo.java:58) >> >> at >> >> >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) >> >> ... 20 more >> >> >> >> >> >> >> >> 2010/1/26 Ethan Jewett <[email protected]>: >> >> > Hi Sig, >> >> > >> >> > Can you give the full stack trace - I don't think this once goes deep >> >> > enough for us to see if the error is in ESME or somewhere else? And >> >> > exactly what command are you running that results in this error? mvn >> >> > clean install? >> >> > >> >> > Thanks, >> >> > Ethan >> >> > >> >> > On Tue, Jan 26, 2010 at 4:55 AM, Sig Rinde <[email protected]> wrote: >> >> >> Thanks Ethan, >> >> >> >> >> >> planned to start over to test all fresh, so I created a new and fresh >> >> >> Amazon instance (same base image as the other live one), apt-get >> >> >> upgrade etc, now running 9.04 all latest. >> >> >> >> >> >> New svn from esme. >> >> >> >> >> >> Added new api_test user in default.props and commented out the >> >> >> compression plug-in in pom.xml. >> >> >> >> >> >> Then fired it up and got this error: >> >> >> >> >> >> [INFO] suggestion: remove the scalaVersion from pom.xml >> >> >> [ERROR] /home/files/esme/server/src/test/scala >> >> >> [ERROR] /home/files/esme/server/src/test/scala/../scala >> >> >> [INFO] Compiling 8 source files to >> >> /home/files/esme/server/target/test-classes >> >> >> [WARNING] Exception in thread "main" java.lang.StackOverflowError >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$ClassSymbol.owner(Symbols.scala:1563) >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:940) >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >> >> >> [WARNING] at >> >> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >> >> >> ... >> >> >> >> >> >> So what did I forget this time :) >> >> >> >> >> >> S >> >> >> >> >> >> 2010/1/25 Ethan Jewett <[email protected]>: >> >> >>> Hi Sig, >> >> >>> >> >> >>> Thanks for doing all that detective work. Unfortunately I don't have >> >> >>> an Ubuntu box to test on. :-( >> >> >>> >> >> >>> I wonder if there is some place that I pull in the setting for the >> >> >>> integration test user other than in the API2 code. Definitely >> >> >>> possible. I will try to look in to it. >> >> >>> >> >> >>> Question if you have the time: If you add another line in the >> property >> >> >>> file and assign a second user as integration admin, does that user >> >> >>> stop working in the web interface as well? >> >> >>> >> >> >>> Thanks, >> >> >>> Ethan >> >> >>> >> >> >>> On Mon, Jan 25, 2010 at 3:27 AM, Sig Rinde <[email protected]> wrote: >> >> >>>> Morning creative sleuth work: >> >> >>>> >> >> >>>> 1. Sorry, no difference between browsers: >> >> >>>> 2. If I log on as another user, then log out in anything but root, >> say >> >> >>>> "hosturl:8080/auth_view/" then no problem. >> >> >>>> 3. If I log out and log on as api_test in root same problem on all >> >> browsers. >> >> >>>> 4. This only for the aws instance, not for my local instance. (aws >> is >> >> >>>> ubuntu, local is OS X) >> >> >>>> 5. Did a diff between the two (local and aws) webapp folders and >> found >> >> >>>> nothing different (except the .svn stuff which I removed after >> first >> >> >>>> try). >> >> >>>> 6. Did a diff between full esme directories and found no diff >> except >> >> >>>> .svn folders and that esme on aws held a file named .gitignore. >> >> >>>> >> >> >>>> The server works though, and now I know how to get in there so I >> can >> >> >>>> live with problem and assume it'll go away with a later new and >> fresh >> >> >>>> install... :) >> >> >>>> >> >> >>>> >> >> >>>> 2010/1/25 Richard Hirsch <[email protected]>: >> >> >>>>> might be a lift-specific problem with those browsers. >> >> >>>> >> >> >>> >> >> >> >> >> > >> >> >> > >> >
