Similar maven2 gwt plugin in mojo codehaus

1 view
Skip to first unread message

ankostis

unread,
Mar 12, 2007, 4:32:17 PM3/12/07
to gwt-maven
Hi to everyone,

i just want to bring to your attention the there is another effort to
build a gwt-plugin for maven2 at mojo. That plugin is not hosted yet,
but there are MOJO issues; here is the one with the code:

https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/gwt-maven-plugin/pom.xml

Are there any ideas for sharing the development (and the effort)?

(I'm currently using the mojo plugin and it is stable, but i think
that codehaus's stringent upload rules do not provide for easy
collaboration.)

Regards,
Kostis

Robert "kebernet" Cooper

unread,
Mar 12, 2007, 4:53:28 PM3/12/07
to gwt-...@googlegroups.com
Well, the gwt plugin at codehaus is just a compile task, and has been seemingly idle for a long time now. Honestly if it has seen any progress over the last little while I would never have written ours. In terms of our compile task, I would say ours is stable as well. Most of the places we still have issues revolves around the other things we are dealing with -- JUnit stuff and the web.xml munging.

I just got back from the Java Posse Roundup  this weekend and will look into clearing up the last Junit issue soon. I have about 64,000 things going on right now, though.

kebe...@gmail.com
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

charlie...@gmail.com

unread,
Mar 16, 2007, 12:18:22 PM3/16/07
to gwt-maven
I know I am a bit late with this response, but yeah, I second Cooper.
There are actually 3 or 4 other maven and GWT "plugins" around, but
most are only a shortcut to the shell or compiler (sometimes both).
They do not normally include goals for creating a war, generating
beans, manipulating the embedded Tomcat, and so on.

On that note, I have also seen a few people mention that the gwt-maven
plugins are Tomcat focused or "require" Tomcat - that is not quite
true. We did make them capable of setting up the embedded Tomcat
instance based on project web.xml and or context.xml files, for
specific reasons (we think that is important, especially with
inherited modules that may include RPC) - but both versions also
support noserver as well. You can use gwt-maven with Jetty, or BEA,
or whatever, etc.

Back around to these plugins, we welcome anyone's participation. We
wrote this thing originally as a Maven 1 plugin for our own projects,
but kept the "support" modules separate (the mergewebxml and
generatebeans stuff). We did this in anticipation of later creating
an M2 version. We now have an M2 version, and most parts of it work
in many cases, but it is newer than the M1 product and does still have
a few problems. We are working on resolving the M2 problems.

On Mar 12, 4:32 pm, "ankostis" <ankos...@gmail.com> wrote:
> Hi to everyone,
>
> i just want to bring to your attention the there is another effort to
> build a gwt-plugin for maven2 at mojo. That plugin is not hosted yet,
> but there are MOJO issues; here is the one with the code:
>

> https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/gwt-maven-plugi...

ankostis

unread,
Mar 17, 2007, 12:33:41 PM3/17/07
to gwt-maven

On Mar 16, 6:18 pm, "charlie.coll...@gmail.com"


<charlie.coll...@gmail.com> wrote:
>
> There are actually 3 or 4 other maven and GWT "plugins" around, but
> most are only a shortcut to the shell or compiler (sometimes both).
> They do not normally include goals for creating a war, generating
> beans, manipulating the embedded Tomcat, and so on.

For maven2: But i thought that generating the war should be left for
the war-plugin to do it.

Why would it be necessary for the gwt-plugin to undertake such a
burden?

Regards,
Kostis

charlie...@gmail.com

unread,
Mar 18, 2007, 5:52:37 PM3/18/07
to gwt-maven
Because there are some specialties with regard to a GWT project WAR
file that having a plugin handle is very convenient for. For one
example, rather than having to maintain configuration information in
two places, the gwt:war goal can inspect the GWT module file, and
automatically add the service servlet entries to the deployment
descriptor (we call this mergewebxml). Yes, it uses the war-plugin
ultimately, but sets up the deployment descriptor in a manner that is
necessary for GWT, before invoking the war goal.

And again, WAR is only one of the additional things that gwt-maven
handles, configuring the embedded Tomcat is another, as is generating
IsSerializable beans. It is much more than a shortcut way to run the
shell or compiler (but can do that also).

Reply all
Reply to author
Forward
0 new messages