On Jan 22, 7:57 am, Charlie Collins <[email protected]> wrote: > Jamie, I just went back and read your threads, and your approach seems > very nice - like it (couldn't remember which it was, there have been > many).
Thank-you. > As I get into the gwt-maven merging with Mojo I will make sure > something like this is applied. I would hope that the Mojo plugin does something similar, but probably in the existing Maven VM since that tends to be the Maven way. If not, I think spawning a new process as I had done works well, but leaves less control to Maven. >From what I gather you're working towards merging, but if there's still going to be a few more releases before then would you consider adding/applying my change? Note that as I wrote it it doesn't replace the compile mojo, but adds a new mojo named compileNg, so it would be up to the users to pick what mojo they want to use for compilation. > If anyone has a test project that > FAILS that they want to donate - something simple but has a crazy long > classpath just to test this - that would be good. I can probably create a test project for this once this crazy week is over. > I have never > personally seen the failure/issue, but the only time I run Windows is > a VM to test stuff - not real projects. I'm in the same situation, but collaborate with a few developers on Windows who's feedback I bring back to the group. > > On Jan 22, 7:53 am, Charlie Collins <[email protected]> wrote: > > > We have had about 8 different approaches to fixing this - but no one > > that volunteered to be the owner of it. I don't have a Windows > > machine, so it shouldn't be me. I have asked for contributors many > > times in the past - it's more than a patch, though those are very much > > appreciated - it really needed an owner. At this point I am going to > > concentrate on maintaining GWT-Maven with it's current setup/approach/ > > features, and not change it drastically, because I am planning to > > Merge with the Mojo gwt-maven-plugin anyway - when I get a chance > > (getting closer to being able to focus on that). > > > Nicolas claims they have solved the Windows long classpath issue > > there, but I am not sure about the details. > > > Seems like it might still be an issue based on threads I read, and all > > the different approaches I have seen have one or another drawback. > > > I think ultimately something along the same lines as what Surefire > > does will be > > needed:http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-... > > > But I am not sure that works with Embedded Tomcat or > > Jetty:http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse... > > > On Jan 21, 5:02 pm, Jamie Whitehouse <[email protected]> > > wrote: > > > > It's been a while since I've upgraded my projects build, and since I > > > had a break I thought I'd try the latest plugin version, 2.0-beta26. > > > The previous version I was using was 2.0-beta15 with my patch for in > > > JVM classpath assembly and compilation to work around the windows path/ > > > input line issues. See file > > > athttp://gwt-maven.googlegroups.com/web/CompileUsingJavaMojo.java > > > and discussion thread > > > athttp://groups.google.com/group/gwt-maven/browse_thread/thread/f2a1160... > > > . > > > > I noticed that there's been a lot of effort put into fixing this and I > > > was hopeful for beta26, but I still have the same issue. Has anyone > > > else on Windows experienced this path problem with this release? Is > > > there any chance of the previous patch being applied with a new > > > release? Should I continue to patch my local version? > > > > Any input is appreciated. > > > Jamie. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "gwt-maven" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/gwt-maven?hl=en -~----------~----~----~----~------~----~------~--~---
