Yes, if there is no group specific to GWT Maven at Mojo I will lobby there to start a group specifically for that, if that doesn't fly we will just start one on our own. Maybe not THIS group, but one that is focused to that project for sure.
That's one of the things that frankly annoys me so far about the Codehaus stuff, a lot clunkier to work with, but I am trying to grit my teeth and do things the way the Maven guys say they should be done ;). On Mar 30, 7:06 am, Mirko Nasato <[email protected]> wrote: > GWT 1.6 seems to work fine with the current version of the plugin > anyway, apart from the warnings due to the use of the legacy > GWTCompiler and GWTShell. > > Of course that doesn't support the new project structure, but it's > unlikely that we'll want to restructure all our existing projects > immediately. > > Charlie: it seems like at the Codehaus there's no discussion group > specific to gwt-maven, but a single mailing list for all the maven > plugins? If that's the case, would it make sense to keep this group > for the unified plugin as well? > > Thanks > > Mirko > > 2009/3/30 Charlie Collins <[email protected]>: > > > > > Please don't do the 1.6 stuff on the trunk of this project. Make a > > branch for that if it has to be done here. Better yet, do it on the > > codehaus codebase. > > > I don't plan to add any new features here, new features will go in the > > Mojo codebase. If you want to be a committer there, I will get you > > voted in to that one. > > > For this project, I plan to make a final release soon, without new > > features (just including all the patches, and my own cleanup, with > > documentation and archetype). Then I plan to move over and work on > > things at Codehaus. Yes, Codehaus is a lot more restrictive about > > stuff, but it was the decision we made (after discussing things with > > this group) because it is the Maven preferred way to handle 3rd party > > plugins. > > > Once I feel like the Codehaus plugin does everything this one does, > > and does it correctly, I would like to just freeze this project. > > Having the two of them is just too confusing (Codehaus has issue > > tracking and people can submit patches and so on, anyone who wants to, > > people can't commit unless they get voted in, but they do have > > access.) > > > On Mar 22, 7:41 pm, "Robert \"kebernet\" Cooper" <[email protected]> > > wrote: > >> On Sun, Mar 22, 2009 at 7:27 PM, Mirko Nasato > >> <[email protected]>wrote: > > >> > 2009/3/22 Robert "kebernet" Cooper <[email protected]>: > > >> > > On Sun, Mar 22, 2009 at 6:36 PM, Mirko Nasato <[email protected]> > >> > > wrote: > > >> > >> GWT 1.6 has new Compiler and HostedMode tools, with GWTCompiler and > >> > >> GWTShell deprecated but still supported for legacy behaviour. I'm > >> > curious as > >> > >> to which ones will you be using when you add 1.6 support? > > >> > > We will be using the new versions. There are some caveats there > >> > > depending > >> > on > >> > > your project. There are new *ScriptWriter16.java files in SVN for this > >> > that > >> > > will use the new version, however... :) > >> > > The <runTarget> will change since the new system will deploy to a > >> > property > >> > > context, so you can take that [ModuleName]/Whatever.html stuff out and > >> > > it > >> > > will be based on the simple startup. > >> > > If you are using 1.6, the mergewebxml goal will be somewhat > >> > > superfluous, > >> > but > >> > > since the new Jetty bootstrap is tighter than Tomcats, you will no > >> > > longer > >> > be > >> > > able to configure datasources/etc in a context.xml file at all. I am > >> > > thinking we might need a new goal that will let you merge a > >> > > "testweb.xml" > >> > > into the web.xml file for the :gwt and :debug goals so you could put a > >> > > ContextListener in for test mode that will bootstrap your > >> > datasources/JNDI > >> > > stuff. > >> > > Personally, I think the gwt team made a bonehead call getting rid of > >> > > <servlet> from the module defs. Having that there meant you could > >> > seamlessly > >> > > package server deps into modules and inherit them. Now you will have to > >> > > hand-add all the servlets for any inherited modules, which poses a > >> > > documentation challenge. Either way, I think the <servlet> tag can stay > >> > in > >> > > the modules and will just get a complain at build time, so until they > >> > take > >> > > it all the way out, you can continue to use mergewebxml. > >> > > There are also new parameters on the plugin config to support > >> > workerThreads, > >> > > etc. These will only work with 1.6+ > >> > > Also on the plus side, they are properly kicking the classpath for > >> > > Jetty, > >> > so > >> > > surefire testing of GWTTestCase will likely no longer be a problem. > > >> > It almost feels like you could have two separate versions of the > >> > plugin if GWT 1.6 is so different. It may be easier to say "if you're > >> > using gwt 1.5 then use gwt-maven 2.0, if you're using gwt 1.6 then use > >> > gwt-maven 2.1", rather than having lots of different options, some of > >> > them applicable only to one gwt version and not the other. > > >> Yeah, I get that, but there is always a transition period too. 1.5 was some > >> big changes and we continued to have cases in the code for 1.4 for a while > >> too. The problem with doing that is you have to assume that we will > >> maintain > >> 2..N "prod" branches of the code and be replicating changes/bugfixes across > >> them. I personally hate doing that, but it might be the way to go. > > >> > >> But most of all I would appreciate some more info about the future of > >> > this > >> > >> project. In my company we decided to stick to the gwt-maven release we > >> > were > >> > >> using before Charlie announced that this plugin and the Codehaus one > >> > will be > >> > >> merged, waiting for developments. Now that you seem to be back and > >> > working > >> > >> on this project again, could you tell us how you see things evolving? > > >> > > I am honestly not sure on that. My priority right now is (a) get 1.6 > >> > support > >> > > ready before 1.6 final ships (this is mostly done, I just need to > >> > > verify > >> > the > >> > > windows code. (b) Ship 2.0 final that will let us ride out 1.6+ for > >> > > gwt-maven. > >> > > (The rest of this is IMHO qualified and not speaking for the project) > >> > > I'll be honest, if the Mojo group wants to own the GWT support, I am > >> > > all > >> > for > >> > > it. I don't have any ego in the game on gwt-maven. The reason gwt-maven > >> > > exists is because the GWT Mojo project just never met my needs as a > >> > > developer. If the new unified Mojo plugin does everything I need, I > >> > > would > >> > be > >> > > perfectly happing letting 2.0 GA of gwt-maven be the final release. > >> > > I would also be amenable to keeping GWT Maven around as an "early > >> > > access" > >> > > codebase. We have, with this project and all the other FLOSS projects I > >> > have > >> > > been on that I like, followed the PHP model for commit access: Ask and > >> > you > >> > > shall receive. People are generally not stupid and if they want to > >> > commit, I > >> > > say let them. In all the projects I work on, I can count on the fingers > >> > of > >> > > one hand the number of completely bone-headed commits we have gotten > >> > working > >> > > this way. Personally, I would be happy with Wiki-style commit privs on > >> > one > >> > > of the "Forge" sites if someone would support it :P > >> > > The Mojo group is generally much more controlling with commit access. > >> > > It > >> > we > >> > > want to keep this project around as a faster-moving version for people > >> > that > >> > > want it, that would be cool too, and we can back-apply changes to the > >> > Mojos > >> > > project. > >> > > But the long and short of it for me is, what do the you want to do? > >> > > Personally, I think having the two plugins out there is kind of a pain > >> > and > >> > > confusing to new users. It is possible that a lot of the stuff > >> > > GWT-Maven > >> > > manages (like mergewebxml) will become completely redundant, even if I > >> > like > >> > > the "new GWT" way less. > > >> > Personally I wouldn't mind a plugin with a slower release cycle and a > >> > bit more stable, i.e. without a beta tag and incompatible changes > >> > between minor releases. :) But GWT 1.6 means it's the right time to > >> > make big changes now. > > >> Yeah, and I suspect the Mojo version of the plugin might be that plugin for > >> a while. To be honest, some of this has to do with the GWT team themselves: > >> they are making an effort to preserve API compatibility while they really > >> don't care about changing tooling at all. I know some of this has to do > >> with > >> Google internal issues, but becomes a pain for us every release. To be > >> honest, if they would stop doing this hacky classpath stuff and replicate > >> the javac sourcepath/classpath build style, it would make life way easier > >> on > >> us. Now that multi-threaded builds are in, hopefully that will be coming > >> soon. > > >> I do hope this will be the last big batch of "breaks your stuff" changes. > >> If > >> you move to 1.6 you will have to change your stuff, but you were biting > >> down > >> on changing your stuff anyway because of the new 1.6 environment anyway. > >> For > >> some stuff, I am doing hacky things in my own projects with 1.6 (using 1.6, > >> but declaring version 1.5.3 in the plugin conf so it uses Tomcat, rather > >> than Jetty, for instance). > > >> > Cheers > > >> > Mirko > > >> -- > >> :Robert "kebernet" Cooper > >> ::[email protected] > >> Alice's cleartext > >> Charlie is the attacker > >> Bob signs and > >> encryptshttp://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
