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