The same script can run the shell with a "inlined" classpath : set CLASSPATH=D:\platina\repository\com\google\gwt\gwt-user\1.5.3\gwt-user-1.5.3.jar;D:\platina\repository\com\google\gwt\gwt-dev\1.5.3\gwt-dev-1.5.3-windows.jar ... java -cp %CLASSPATH% -Dcatalina.base="D:\projets\apache\gwt-maven-plugin\target\it\gwt-compile\target\tomcat" com.google.gwt.dev.GWTShell -gen ...
But this option fails on windows whith command line limitation on large projects with lot's of dependencies. So I don't thing this issue is related to some jarjar packaging. It seems the TomcatEmbedded doesn't support to run inside a hierarchized classloader (looks really strange) and is fine only when all dependencies are set in the Classpath. 2009/1/21 Scott Blum <sco...@google.com> > Jarjar is a trunk issue that I believe is unrelated. > > > On Tue, Jan 20, 2009 at 10:08 PM, John Tamplin <j...@google.com> wrote: > >> On Tue, Jan 20, 2009 at 9:41 PM, Scott Blum <sco...@google.com> wrote: >> >>> Thanks, nicolas. Your test reproduced an issue, but I was unable to get >>> Tomcat to work properly. We will probably not fix this for 1.6 since Jetty >>> works fine. >>> http://code.google.com/p/google-web-toolkit/issues/detail?id=1032 >>> >> >> Actually, I think jetty has a similar issue (see the internal error report >> Lex is looking at) -- I think the root cause is jarjar missed some >> reflective references to classes, so code is looking for classes under the >> un-mangled name yet the classes have been renamed inside our jar. >> >> Can you try it with surpressing the jarjar mangling? >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
