GWT 1.6 with Maven and build system questions/survey...

[Benju]

I am curious if anybody using Maven+GWT has tried moving to GWT 1.6
yet. I noticed there is no public repository containing the 1.6
realease only RC, Beta, and Milestones. I can always manually deploy
GWT to our internal repository but it's a bit of a pain.

Also, if anybody is using GWT+Maven who prefers the Codehaus plugin
and who the Google Code GWT-Maven plugin? From what I understand
these two Maven plugins are merging in the long term so that only the
Codehaus plugin will be actively developed.

Finally I would also like to post the following question to the GWT
community. What do you use for setting up your builds? I've always
been of the opinion that a good build system is of cardinal
importance, especially on larger projects. At this time I have seen
the following options...

Hand written Ant file
-Calling the GWT compiler directly
-Maven
-with the codehaus plugin (http://mojo.codehaus.org/gwt-maven-
plugin/)
-with the Google Code GWT-Maven plugin (http://code.google.com/p/
gwt-maven/)
-Intellij Idea's built in GWT support
-eclipse with special GWT support (I believe some plugins exist
including the recently released Google one)
-Netbeans gwt4NB (https://gwt4nb.dev.java.net/)

[Tony Strauss]

I also believe in the importance of build systems! :)

My company's current project (medium size, about 32,000 lines of code)
uses a handwritten Ant build system. We do, however, use the Maven
Ant tasks to manage our project's external dependencies. In addition
to using Ant in our builds, we also use it for most of our deployment
tasks. We develop on Windows (eclipse) and Linux (command-line and
emacs), and the build system accommodates this.

From our build files, we:
1.) Call the GWT compiler directly.
2.) Massage the output to fit our deployment needs.
3.) Run jetty
4.) Run GWT hosted mode (with --noserver, which then interacts with
the jetty instance from step 3).

In general, I'm pretty happy with the build system. It is flexible
enough for our needs, and is smart enough to build only what it needs
to. It is, however, a large portion of our code base (about 4,000
lines of Ant XML, which is over 10% of the code base).

Tony
--
Tony Strauss
Designing Patterns, LLC
http://www.designingpatterns.com
http://blogs.designingpatterns.com

[maku]

Currently we use maven and http://code.google.com/p/gwt-maven/ for our
build process.

When we upgrade to GWT 1.6 we will check the codehaus plugin and how
the new Google Eclipse plugin + new app structure can be used in a
more comfortable way.

Regards,
Martin

[johann_fr]

Hi,

I just tried to enable maven dependencies management with google
eclipse plugin and m2eclipse. The plugin complains about project
output folder not set to war/WEB-INF/classes.

I know I can switch my maven project output, but is there any chance
the plugin can be set up to adapt to my project layout in a near
future ? I want to stick to standard maven project layout.

GWT should really take care of beeing well integrated with existing
build tools and plugins. We can not always bend our projects just to
keep GWT tooling happy...

Regards,
Johann

On Apr 10, 7:40 am, maku <martin.k...@gmx.at> wrote:
> Currently we usemavenandhttp://code.google.com/p/gwt-maven/for our

> build process.
>
> When we upgrade to GWT 1.6 we will check the codehauspluginand how

> the newGoogleEclipseplugin+ new app structure can be used in a

> more comfortable way.
>
> Regards,
> Martin
>
> On Apr 9, 5:03 pm, Benju <b...@fastcastmedia.com> wrote:
>

> > I am curious if anybody usingMaven+GWT has tried moving to GWT 1.6

> > yet.  I noticed there is no public repository containing the 1.6
> > realease only RC, Beta, and Milestones.  I can always manually deploy
> > GWT to our internal repository but it's a bit of a pain.
>
> > Also, if anybody is using GWT+Mavenwho prefers the Codehausplugin

> > and who theGoogleCode GWT-Mavenplugin?  From what I understand
> > these twoMavenplugins are merging in the long term so that only the
> > Codehauspluginwill be actively developed.

>
> > Finally I would also like to post the following question to the GWT
> > community.  What do you use for setting up your builds?  I've always
> > been of the opinion that a good build system is of cardinal
> > importance, especially on larger projects.  At this time I have seen
> > the following options...
>
> > Hand written Ant file
> > -Calling the GWT compiler directly
> > -Maven
> >     -with the codehausplugin(http://mojo.codehaus.org/gwt-maven-
> >plugin/)

> >     -with theGoogleCode GWT-Mavenplugin(http://code.google.com/p/

> > gwt-maven/)
> > -Intellij Idea's built in GWT support

> > -eclipsewith special GWT support (I believe some plugins exist

[Alan Hadsell]

We were using Maven "because that's what everyone uses", but found
that it did not meet our needs.

* It requires a great deal of configuration to properly build a GWT
project
* The tools to integrate Maven/GWT/Eclipse are always in a state of
flux
* Some of the really nice stuff in Maven (documentation, etc.)
doesn't work well in a GWT project

We switched back to Ant, using Ivy for external dependency management,
and have been much happier. Ivy's dependency "configurations" are
much more flexible than Maven's "scopes", and for a GWT project the
additional flexibility is needed.

[Daniel Kurka]

Currently we are trying to update our buildsystem from gwt 1.5 + gwt-maven from google code

We are trying to use the trunk of gwt-maven from codehaus since those two plugins are merging.

We were able to sucessfully compile a gwt project, but we still have some open issues.

Has anyone a working installation of GWT 1.6 and Maven?

 

[olivier nouguier]

Yes (mac os x, during week) linux && zindozs during week.
 

 

--
   “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

   Sir Charles Anthony Richard Hoare

[Gabriel Guerrero]

I use maven and GWT, and I just moved to GWT 1.6.4 they are published
I think in maven central repo, I use the antrun plugin to compile and
run the HostedMode in debug mode, I choose the antrun becase at the
time I started the project the maven gwt plugins where not mature
enough and I had not moved because the antrun is very simple and had
worked very well for me, by the way for those interested in using the
maven structure for GWT 1.6.4 , you have to pass -war /src/main/webapp
to the Compiler and HostedMode app to use the default maven structure

Cheers
Gabriel

[Salvador Diaz]

I work in a smallish-medium agile environment (12 developers for 3
teams, ~6 GWT 1.5 projects, of which 3 are actively developed during
an iteration) and we happily use maven to manage our projects'
lifecycles.

We used to compile our GWT app with the gwt-maven-plugin hosted at
google code but we recently moved to the mojo one (the merge between
the 2 plugins is finished as far as I can tell in version 1.1-
SNAPSHOT). The configuration is simpler and environment-agnostic (no
need to specify one profile for each OS, the plugin detects the OS and
sets up the correct dependencies automatically). We use the maven
project structure:
* sources in src/main/java
* unit tests sources in src/test/java
* resources in src/main/resources (including GWT module configuration,
html, css and image files, as well as text bundles (for localization
and such))
* war related files in src/main/webapp (currently only WEB-INF/
web.xml)

We set the GWT compiler to output files to target/gwt and then the war
plugin assembles the war file merging src/main/webapp and the gwt
compiler output. The resulting war is immediately deployable on a
tomcat.

We code in eclipse and let the m2eclipse plugin configure the project.
For debugging we create an eclipse launcher manually for each OS
(normally there's a goal in the gwt-maven-plugin to create a launcher
but we haven't tested it as the launcher doesn't change much over
time), and we add the following to the classpath: the project, the
maven classpath, the src/main/resources folder and the OS specific gwt-
dev jar

It all integrates very nicely and once the project is set up we rarely
think about configuration or building the project (as this is managed
automatically by a hudson build manager which polls the svn and builds
the war and deploys it when necessary). We can really concentrate in
coding with this setup.

I'm currently investigating the effort needed to migrate from GWT
1.5.3 to 1.6.4 and I have encountered some issues, mainly with the new
project structure and the hostedMode configuration. The new hosted
mode works quite differently, it now outputs the resource files
declared in the Module.gwt.xml file to a folder named like the module
(the location of this folder defaults to a folder named war at the
root of the project, but it can be configured with the argument -war)
and it now expects to find the WEB-INF folder and associated web.xml
file on that war folder. Currently I haven't managed to call RPC's due
to this change, but I guess I could configure the maven resources
plugin to copy the WEB-INF folder to the war folder during the process-
resources phase. I'll let you know if this works.

Cheers,

Salvador

PS: If you're interested in the project configuration I described
here, you can check out one of my pet projects at http://code.google.com/p/hellagwt/.
If you need any help with maven-gwt integration, I'll be glad to
answer any questions in this thread.

On Apr 12, 8:51 pm, olivier nouguier <olivier.nougu...@gmail.com>
wrote:

> On Sun, Apr 12, 2009 at 7:35 PM, Daniel Kurka

> <kurka.dan...@googlemail.com>wrote:

[Peterman]

Hi

I was using a maven plugin (http://gwt-maven.googlecode.com/svn/trunk/
mavenrepo) with GWT 1.5.3 without Hosted Mode (in Linux the hosted
mode gives a firefox browser older and doesn't support gears, for
example), I generate a war and the copy it to a jboss server to test
it. I know that it is not very useful, but it is the problem for linux
users :(

But when I try upgrade to GWT 1.6 it doesn't work: crash in the test
task.

If anybody has the same problem, please contact with me.

thanks

[Benju]

I find it somewhat odd that the GWT team does not just create an
official maven plugin. They can program the most amazing Java to
Javascript cross compiler, have the most shiny widgets and speedy RPC
services but if people are left in the dark as to how to build the
bloody thing it will never be used! Who agrees that having a solid,
feature complete Maven plugin from Google would increase adoption of
GWT faster than anything?

I used a great starter application created by Sam Brodkin...

http://code.google.com/p/gwt-maven2-starter-app/

It served as a good starting point for building my application in
Maven2. I use Teamcity for continuous integration which at this early
stage essentially means building the project, running one unit test,
and spitting out an artifact every time the SVN is updated.

[Jeff Chimene]

On 04/14/2009 02:39 PM, Benju wrote:
> I find it somewhat odd that the GWT team does not just create an
> official maven plugin. They can program the most amazing Java to
> Javascript cross compiler, have the most shiny widgets and speedy RPC
> services but if people are left in the dark as to how to build the
> bloody thing it will never be used! Who agrees that having a solid,
> feature complete Maven plugin from Google would increase adoption of
> GWT faster than anything?
>

Maybe file an enhancement request?

[Salvador Diaz]

> > Who agrees that having a solid,
> > feature complete Maven plugin from Google would increase adoption of
> > GWT faster than anything?

I think the google team is focusing in the basics first, and that
implies not being able to deliver all the goodies at the same time, I
think it all fits rather nicely with the agile mantra: deliver early,
deliver often. If they tried delivering the Eclipse plugin (and all
other popular IDEs' plugins for that matter) and the maven plugin at
the same time they deliver the actual product (GWT) they couldn't
possibly deliver that often. Not to mention that they don't seem to be
maven people, they're rather ant users, so why not leave it to the
community, in true open source spirit, to build the tools they need,
they even help out when there's something that doesn't work nicely
with our tools (one of the issues resolved in 1.6 was specifically
adressed to allow a nicer maven integration), I don't think we can
possibly ask for more cooperation from them.

> Maybe file an enhancement request?

I totally agree with Jeff, if you think a great maven plugin would
help with adoption, why not try the one from the mojo project (which
is quite nice by the way) and report any issues that you find with it.
I don't think we can have a more official plugin than that (after all,
they're the maven experts, not google )

Cheers,

Salvador

[Benju]

On second though I think I agree with Salvador. Looking closer at the
Codehaus plugin it should do the job job in the long term.

[Daniel Kurka]

I invested more ore less 8h and dont have a wokring configuration of the trunk of the mojo gwt plugin and gwt 1.6

Some things work, but many don't. Kinda anoying...

[Keith Willard]

Where is the snapshot respository where the versions 1.1-SNAPSHOT
codehaus gwt-maven-plugin lives? only the 1.0 is in the central
repository.

[Murray Waters]

It is in the snapshots repository.

http://snapshots.repository.codehaus.org/org/codehaus/mojo/gwt-maven-plugin/1.1-SNAPSHOT/

You will need to add the repository as http://snapshots.repository.codehaus.org/
I believe.

[johann_fr]

I totally agree on the fact that gwt team should not provide the maven
plugin, the codehaus one can do the job. They should just take care of
beeing able to integrate with any build system.

My problems with the current google eclipse plugin :
* If you enable gwt support on your project, GWT SDK library is
automatically added to the project, event if you already manage your
dependencies with maven. You should be able to configure if you want
the sdk to be included or not.
* The plugin complains about output directory not set to "war/WEB-INF/
classes". We should be able to configure this in order to work in a
standard maven way.

Johann

On 16 avr, 08:50, Murray Waters <murray.wat...@gmail.com> wrote:
> It is in the snapshots repository.
>

> http://snapshots.repository.codehaus.org/org/codehaus/mojo/gwt-maven-...
>
> You will need to add the repository ashttp://snapshots.repository.codehaus.org/

[Salvador Diaz]

> * If you enable gwt support on your project, GWT SDK library is
> automatically added to the project, event if you already manage your
> dependencies with maven. You should be able to configure if you want
> the sdk to be included or not.
> * The plugin complains about output directory not set to "war/WEB-INF/
> classes". We should be able to configure this in order to work in a
> standard maven way.

Those are pretty good remarks, and worth of opening an issue in the
issue tracker. We could do it the other way round though, and let the
maven plugin configure everything to conform to GWT's expectations,
remember that Googlers are not really maven guys.

Cheers,

Salvador

On Apr 16, 10:09 am, johann_fr <johann.vanack...@gmail.com> wrote:
> I totally agree on the fact that gwt team should not provide the maven
> plugin, the codehaus one can do the job. They should just take care of
> beeing able to integrate with any build system.
>
> My problems with the current google eclipse plugin :

>

[Arthur Kalmenson]

It would definitely be nice if the Google Eclipse plugin was build
system agnostic, or at least gave you more configuration options.
Maybe we should just file a issue with the Google Eclipse plugin (I
can't find the Google Code project...)?

--
Arthur Kalmenson

[Mark Renouf]

The maven-gwt-plugin from codehaus is looking quite good at this
point. I recommend trying 1.1-SNAPSHOT.

I just reported an issue with running unit tests (which has been fixed
in SVN, waiting on a new SNAPSHOT build). With that it does absolutely
everything I've expected (on all platforms, without local
configuration) and with very minimal setup (add the plugin, add a
dependency on gwt-user, done).

The one remaining issue is the new build output format (WAR), and how
resources are deployed. I'm totally against having GWT compile
directly into /src/main/webapp. It's completely against the principles
of keeping your source tree clean and putting all artifacts under
target. If you stick with traditional maven approach, it means you
need to execute war:exploded first before launching hosted mode (and
again if you want to change something without restarting the hosted
mode).

The other approach is stick with src/main/webapp and make sure the
clean plugin cleans out all GWT generated files. Again, this is really
not the right approach :-(

On Apr 16, 8:48 am, Arthur Kalmenson <arthur.k...@gmail.com> wrote:
> It would definitely be nice if the Google Eclipse plugin was build
> system agnostic, or at least gave you more configuration options.
> Maybe we should just file a issue with the Google Eclipse plugin (I
> can't find the Google Code project...)?
>
> --
> Arthur Kalmenson
>

[Salvador Diaz]

> I'm totally against having GWT compile
> directly into /src/main/webapp. It's completely against the principles
> of keeping your source tree clean and putting all artifacts under
> target. If you stick with traditional maven approach, it means you
> need to execute war:exploded first before launching hosted mode (and
> again if you want to change something without restarting the hosted
> mode).

I think your remarks are worth for filing a new issue. Somewhere in
the 1.6 announcement, Googler Miguel Méndez asked "What aspects would
you need to be able to change in order to make the plugin more Maven
friendly? " (http://groups.google.com/group/Google-Web-Toolkit/msg/
9a3b994595f129db)? Yours is a pretty good response to that question.

[Matt Bishop]

One of the big wins with Maven is the "rigid" directory structure,
where source files of all stripes are in src/ and build outputs are in
target/. It's good practice because it doesn't allow for intermingling
source files and build files.

The new GWT war/ dir next to src/ problematic because you have to be
careful how you clean up. I can see many an "aaargh!" being screamed
out in the early morning hours when a tired developer discovers a bug
in her ant script, or when he trashes the war/ dir accidentally.

I would much rather have seen src/java and src/war (better yet, src/
webapp) and the HostedMode compiler would copy src/webapp to war/
before compilation. It would be a whole lot safer and wouldn't really
cost that much, even for large projects with a whole lotta webapp/**

[P.G.Taboada]

> The one remaining issue is the new build output format (WAR), and how
> resources are deployed. I'm totally against having GWT compile
> directly into /src/main/webapp. It's completely against the principles
> of keeping your source tree clean and putting all artifacts under
> target. If you stick with traditional maven approach, it means you
> need to execute war:exploded first before launching hosted mode (and
> again if you want to change something without restarting the hosted
> mode).

I totally agree here. The "old" GWt build proceding was naive and we
needed twirks to get it running. When I first heard of the new
structure I was really happy: GWT is growing up! But than I had a
closer look at it and I could not believe it! How can the GWT
developer be so genious and so naive at the same time??? How could
they miss that point? Don't they use their own dog food? Did they
never see how projects are build outside? Or do they use something we
don't know?

It is hard to argue to get resources/ time/ budget for a build
infrastructure change.
We need budget now, because GWT 1.6 does it differently - and you know
what? It is naive again! We will need budget again!
We will probably need to wait for GWT 1.7, GWT 1.8, GWT 1.9, GWT 2.0
to have this issue fixed.

I can't tell how disappointed I am.


brgds,

P.G.Taboada

[Daniel Kurka]

same here...

2009/4/17 P.G.Taboada <pgta...@googlemail.com>

[Benju]

It would seem my original post has uncovered all sorts of aches and
pains with the new GWT structure. Personally I use maven with the GWT-
maven plugin from Google code and only had to change the version
number of GWT 1.6.4 and it worked. I don't actually fully understand
what was changed but I do know my program worked even after a full
clean/build (including manually wiping my local maven repo).

Perhaps it is not Google's place to write a Maven plugin, but rather
if one of people on the GWT team could take the time to write up a few
documents discussing working with GWT in envionments xyz (just an
idea). I know it's painful to write documentation sometimes but it
really really helps drive a project/product. I would write this up
myself but I don't really GWT well enough at this time to write this
kind of document myself.

Has anybody here given up on using a technology because the build
system wasn't playing nice with it? Honestly I'd like to hear. As an
example if Java EE's build system was easier to deal with we would all
be writing enterprise systems in 5-10 lines of code ;-)...

RIGHT???

[Keith Willard]

I have been struggling updating my older style (gwt 1.5 with the
older pre-codehause maven plugin) project working with the codehause
gwt-maven-plugin 1.1-SNAPSHOT.


So I resorted to start with a maven project created using the plugin's
archetype in my Eclipse environment which gives looks like it gives me
an appropriate project structure, and a few almost empty classes and
resources including a trivial entry point class.

The pom file you get from the architect needed a configuration section
so I added the following the the gwt plugin section more or less taken
verbatim from the documentation pages except using my test package
prefixes.

<configuration>
<logLevel>INFO</logLevel>
<compileTargets>
<value>cp.sink.client.Application</value>
</compileTargets>
<runTarget>cp.sink.client.Application/
Application.html</runTarget>
<style>DETAILED</style>
<noServer>false</noServer>
<!-- this parameter is VERY important with
automatic mode - has to match the version in your declared deps -->
<!-- if this does not match (default if left out
is 1.5.3) you will have mysterious errors -->
<gwtVersion>${gwtVersion}</gwtVersion>
</configuration>

the project compiles (I have never been having any compilation
problems:-) but when I try the gwt:run target I get the following

[INFO] [gwt:run]
[INFO] using GWT jars from project dependencies : 1.6.1
[INFO] Unpack native libraries required to run GWT
[INFO] source web.xml present - C:\workspaces\ha-serverworkspace\sink
\src\main\webapp\WEB-INF\web.xml - using it with embedded Tomcat
[INFO] establishing classpath list (scope = runtime)
[ERROR] java.lang.NoClassDefFoundError: and
[ERROR] Exception in thread "main"
[ERROR]

I know I am doing something dumb but any suggestions? Also why am I
getting the embedded Tomcat message--I thought things in 1.6 were
transitioning to Jetty?

--Keith

[Murray Waters]

Does the codehaus maven plugin have a decent mailing list? It seems like they don't have their own mailing list which is a bit of a pain.

[Andrew Pietsch]

> I can't tell how disappointed I am.

Yep, me too. Yet more time spent futzing around trying to keep my src
tree clean.

[Salvador Diaz]

> I know I am doing something dumb but any suggestions? Also why am I
> getting the embedded Tomcat message--I thought things in 1.6 were
> transitioning to Jetty?

If you run that goal in debug mode (mvn gwt:run -X) it should tell you
exactly what it's doing (it sounds like it's using a gwt-dev-1.5
instead of 1.6)

> Does the codehaus maven plugin have a decent mailing list?

The mailing list (http://mojo.codehaus.org/gwt-maven-plugin/mail-
lists.html) is for the whole Mojo project so you'll also get mails
from users of other maven plugins hosted at mojo. I agree it's a bit
of a pain, but since the issue tracker only has 11 open issues (http://
jira.codehaus.org/browse/MGWT) I think you should be able to report
any issues you've found and get a quick response.

> Yep, me too. Yet more time spent futzing around trying to keep my src
> tree clean.

Stop being disappointed (it doesn't help in anything) and help us in
making GWT better (http://code.google.com/webtoolkit/
makinggwtbetter.html)

Cheers,

Salvador

[Murray Waters]

I think i'm going to open a new issue saying that they should have their own mailing list :-)

[Mark Renouf]

The thing I'd not like to lose, is "live-edit" capability. ie: changes
take effect with a simple page reload in HostedMode (and also Restart
Server button in 1.6).

I think GWT provides enough options to make things work, but it's
harder than it should be. If I had a magic wand though, I'd say having
"war dir overlay" parameter would make life much simpler. If it could
do this, and still detect changes to the source, that would be sweet.
You'd just set -warOverlay /src/main/webapp -war /target/$
{project.build.finalName} That actually wouldn't effect existing users
one bit. Actually... maybe I should work on a patch and submit it to
GWT, you never know ;-)

[Mark Renouf]

I wanted to share some progress I've made in making things work
smoothly together.

First off, I discovered the new phase "prepare-package" in Maven
2.1.0. This is perfect for binding the gwt compile goal to. This means
the app gets compiled down to Javascript just before packaging, which
is exactly what you want. Hosted mode and unit tests don't require a
JS compile.

Second, I've got what appears to be a nice working solution involving
GWT-1.6.4 and maven, concerning the build path and src folder problem.
I've got GWT compiling into ${project.build.finalName} (this is
usually your artifact name... "/target/mywebapp-1.0"). Then, add this
to resources:

<resource>
<directory>src/main/webapp</directory>
<targetPath>${project.build.directory}/$
{project.build.finalName}</targetPath>
</resource>

What this does is overlay your source webapp to the target *before*
GWT gets started up (either Compiler or Hosted Mode). If you use the
m2eclipse plugin, then the resources goal is automatically executed
when you modify files.

This achives several important goals of mine:
Client java code changes are picked up immediately on the next
page reload (if you need resource filtering, put your java source in a
resource entry, and disable the "sourcesOnPath" option)
HostedMode is using a classpath containing target/classes (so any
modified servlet code can take effect with the reload server button)
No source tree pollution... a full clean is simply "rm -rf
target" (or more properly: mvn clean)
Packaging can still be controlled to filter out all uneccesary
files from the resulting WAR (.class and .java files from GWT client
side code, GWT module xml, etc)

I wish I had a place to put an example of all this (I need a blog or
something), but feel free to contact me if you'd like a sample of my
project if you can put this on a wiki and help document it, then I can
point people to a URL instead of clogging up mailing lists ;-)

Hope this helps people... big thanks to everyone else who's worked on
this already...

On Apr 19, 8:56 am, Mark Renouf <mark.ren...@gmail.com> wrote:
> The thing I'd not like to lose, is "live-edit" capability. ie: changes
> take effect with a simple page reload in HostedMode (and also Restart
> Server button in 1.6).
>
> I think GWT provides enough options to make things work, but it's
> harder than it should be. If I had a magic wand though, I'd say having
> "war dir overlay" parameter would make life much simpler. If it could
> do this, and still detect changes to the source, that would be sweet.
> You'd just set -warOverlay /src/main/webapp -war /target/$
> {project.build.finalName} That actually wouldn't effect existing users
> one bit. Actually... maybe I should work on a patch and submit it to
> GWT, you never know ;-)
>
> On Apr 16, 2:00 pm, Matt Bishop <m...@re-entry.ca> wrote:
>

> > One of the big wins withMavenis the "rigid" directory structure,

[Murray Waters]

Thanks heaps for this, its possibly exactly what i'm looking for.

For the 1.6 support, are you using the codehaus plugin or the other one.

I would encourage you to rename in your pom anything confidential, then post the entire pom here in another post if you can. I wouldn't worry too much about mailing list traffic :-). Also remember that naturally google groops are very google searchable, so there is a good chance people will find this through google if that is what they are after, so you don't need a blog.

[KaffeineComa]

I'm curious how folks are adapting to this new layout. How many of
you are letting GWT write its output to war/**, and how many are going
the maven approach and moving things to target/war/** ? Personally, I
much prefer the maven idea of keeping source and generated files
separate. However, I don't want to be continually swimming upstream
against this layout, in particular if it will cause pain for my
colleagues using Eclipse (I'm an Intellij user myself).

Thanks.
K

On Apr 16, 2:00 pm, Matt Bishop <m...@re-entry.ca> wrote:

> One of the big wins withMavenis the "rigid" directory structure,

[Laird Nelson]

On Thu, Apr 30, 2009 at 10:07 AM, KaffeineComa <kaffei...@gmail.com> wrote:

However, I don't want to be continually swimming upstream
against this layout, in particular if it will cause pain for my
colleagues using Eclipse (I'm an Intellij user myself).

I am most reluctantly following the GWT/Eclipse layout.  I don't like it at all, but a good number of our users will simply fire up Eclipse, add the plugin and do what it says, so by default it wins.

Fortunately it's not too terribly invasive.  I'm still keyboard-trained, however, to look for src/main/java....

Best,
Laird

[Salvador Diaz]

Hi guys,
I've posted a brief tutorial in my blog where I give some tips to
stick to maven conventions and force GWT 1.6 to play nice. Leave your
comments there and I'll update the post with the answers. There'll be
a followup with much more detailed explanations next week. Let me know
what you think:

http://blog.salvadordiaz.fr.nyud.net (use the cache please, if it
doesn't work, try the direct url http://blog.salvadordiaz.fr)

Cheers,

Salvador

On Apr 30, 5:17 pm, Laird Nelson <ljnel...@gmail.com> wrote:

[Murray Waters]

Excellent! I'll take a closer look next week and be sure to post. What I'm after is very similar to you although I don't know if I need to use GEP (what does it actually do?), and want to get it working under RAD 7.5 instead (which is based on eclipse 3.4).

You might also consider adding a link to your blog on the wiki for the maven eclipse plugin.

[Salvador Diaz]

Thanks Murray,

In fact I realised while writing the post that GEP doesn't do anything
in this configuration (I said it in the post) but the google team is
actively working to address the relevant issues. As for the link in
the m2eclipse wiki, I'm a little reluctant to do it now, it'd appear
as a shameless plug/blogspam and I don't really know how many people
will find this helpful so I'll just wait and see how people respond.

I'm making some updates to the post as there's a bug in m2eclipse that
borks the whole thing. Check back in a couple of hours.

Cheers,

Salvador

On May 2, 1:25 am, Murray Waters <murray.wat...@gmail.com> wrote:
> Excellent! I'll take a closer look next week and be sure to post. What I'm
> after is very similar to you although I don't know if I need to use GEP
> (what does it actually do?), and want to get it working under RAD 7.5
> instead (which is based on eclipse 3.4).
>
> You might also consider adding a link to your blog on the wiki for the maven
> eclipse plugin.
>

> On Fri, May 1, 2009 at 7:43 PM, Salvador Diaz <diaz.salva...@gmail.com>wrote:
>
>
>
> > Hi guys,
> > I've posted a brief tutorial in my blog where I give some tips to
> > stick to maven conventions and force GWT 1.6 to play nice. Leave your
> > comments there and I'll update the post with the answers. There'll be
> > a followup with much more detailed explanations next week. Let me know
> > what you think:
>

> >http://blog.salvadordiaz.fr.nyud.net(use the cache please, if it
> > doesn't work, try the direct urlhttp://blog.salvadordiaz.fr)

[Rajeev Dayal]

Hey Salvador,

Nice job on consolidating all of this information. I'm not a Maven user, but it seems like your information has been helpful to many.

I'm specifically interested in the problems that you're seeing with using GEP in this situation. Even though right-click launch behaviors may not work, you should be able to go to the Launch Configurations dialog, and create a new launch configuration manually. If the project is using GWT, navigate to the "Arguments" tab, and add the following to the "Program Arguments" section:

-war <targetpath>

Unfortunately, if your project is App Engine only, there is no way to override the computed war directory value via the Arguments tab.


Rajeev

[Salvador Diaz]

> Nice job on consolidating all of this information. I'm not a Maven user, but
> it seems like your information has been helpful to many.

Hi Rajeev,

Thanks for your input !

> I'm specifically interested in the problems that you're seeing with using
> GEP in this situation.

You can take a look at issue #3583 for more information on the issues
I'm seeing

> Even though right-click launch behaviors may not
> work, you should be able to go to the Launch Configurations dialog, and
> create a new launch configuration manually.

Thanks, I talked about that in my post, in the last bullet point in
the section "Eclipse project configuration" i describe how to
configure it.

>
> Unfortunately, if your project is App Engine only, there is no way to
> override the computed war directory value via the Arguments tab.

That's a pity, however I haven't yet had the chance to play with GAE
so I cannot further comment on that.

Cheers,

Salvador

[Rajeev Dayal]

Hey Salvador,

Replies inline:

On Mon, May 4, 2009 at 2:59 PM, Salvador Diaz <diaz.s...@gmail.com> wrote:

> Nice job on consolidating all of this information. I'm not a Maven user, but
> it seems like your information has been helpful to many.

Hi Rajeev,

Thanks for your input !

> I'm specifically interested in the problems that you're seeing with using
> GEP in this situation.

You can take a look at issue #3583 for more information on the issues
I'm seeing

Ah, great! We'll definitely take these issues into consideration when working on future releases of the plugin.
 

> Even though right-click launch behaviors may not
> work, you should be able to go to the Launch Configurations dialog, and
> create a new launch configuration manually.

Thanks, I talked about that in my post, in the last bullet point in
the section "Eclipse project configuration" i describe how to
configure it.

Great!
 

>
> Unfortunately, if your project is App Engine only, there is no way to
> override the computed war directory value via the Arguments tab.

That's a pity, however I haven't yet had the chance to play with GAE
so I cannot further comment on that.

Yes, it is unfortunate, and will be something that we look at in a future release.
 

Cheers,

Salvador

[Ed]

I use 1.6.4. from a maven repo..
I used http://code.google.com/p/gwt-maven/ for my maven build but
moved to the codehouse gwt maven plugin as indicated on the
http://code.google.com/p/gwt-maven/ site, as this latter one will not
be developed anymore and they adviced to move to the codehouse plugin.
It works fine here,
Ed

[Ed]

Just point your output dir to your target dir with the codehouse
plugin and simple ignore it...
That what I do....
Works fine...

--Ed

[mgrouch]

Where can I get pom.xml examples for GWT 1.6?
Something more elaborate like combo with GWT-EXT or smartgwt would be
nice.

Thanks

On May 5, 5:06 am, Ed <post2edb...@hotmail.com> wrote:
> Just point your output dir to your target dir with the codehousepluginand simple ignore it...

> That what I do....
> Works fine...
>
> --Ed
>
> On Apr 16, 3:27 pm, Mark  Renouf <mark.ren...@gmail.com> wrote:
>

> > Themaven-gwt-pluginfrom codehaus is looking quite good at this

> > point. I recommend trying 1.1-SNAPSHOT.
>
> > I just reported an issue with running unit tests (which has been fixed
> > in SVN, waiting on a new SNAPSHOT build). With that it does absolutely
> > everything I've expected (on all platforms, without local
> > configuration) and with very minimal setup (add theplugin, add a

> > dependency ongwt-user, done).

>
> > The one remaining issue is the new build output format (WAR), and how
> > resources are deployed. I'm totally against havingGWTcompile
> > directly into /src/main/webapp. It's completely against the principles
> > of keeping your source tree clean and putting all artifacts under

> > target. If you stick with traditionalmavenapproach, it means you

> > need to execute war:exploded first before launching hosted mode (and
> > again if you want to change something without restarting the hosted
> > mode).
>
> > The other approach is stick with src/main/webapp and make sure the

> > cleanplugincleans out allGWTgenerated files. Again, this is really

> > not the right approach :-(
>
> > On Apr 16, 8:48 am, Arthur Kalmenson <arthur.k...@gmail.com> wrote:
>

> > > It would definitely be nice if the Google Eclipsepluginwas build

> > > system agnostic, or at least gave you more configuration options.
> > > Maybe we should just file a issue with the Google Eclipseplugin(I
> > > can't find the Google Code project...)?
>
> > > --
> > > Arthur Kalmenson
>
> > > On Thu, Apr 16, 2009 at 4:33 AM, Salvador Diaz <diaz.salva...@gmail.com> wrote:
>

> > > >> * If you enablegwtsupport on your project,GWTSDK library is

> > > >> automatically added to the project, event if you already manage your

> > > >> dependencies withmaven. You should be able to configure if you want

> > > >> the sdk to be included or not.

> > > >> * Theplugincomplains about output directory not set to "war/WEB-INF/

> > > >> classes". We should be able to configure this in order to work in a
> > > >> standardmavenway.
>
> > > > Those are pretty good remarks, and worth of opening an issue in the
> > > > issue tracker. We could do it the other way round though, and let the
> > > >mavenpluginconfigure everything to conform toGWT'sexpectations,
> > > > remember that Googlers are not reallymavenguys.
>
> > > > Cheers,
>
> > > > Salvador
>
> > > > On Apr 16, 10:09 am, johann_fr <johann.vanack...@gmail.com> wrote:
> > > >> I totally agree on the fact thatgwtteam should not provide themaven
> > > >>plugin, the codehaus one can do the job. They should just take care of
> > > >> beeing able to integrate with any build system.
>
> > > >> My problems with the current google eclipseplugin:
>
> > > >> Johann
>
> > > >> On 16 avr, 08:50, Murray Waters <murray.wat...@gmail.com> wrote:
>
> > > >> > It is in the snapshots repository.
>
> > > >> >http://snapshots.repository.codehaus.org/org/codehaus/mojo/gwt-maven-...
>
> > > >> > You will need to add the repository ashttp://snapshots.repository.codehaus.org/
> > > >> > I believe.
>
> > > >> > On Apr 16, 12:33 pm, Keith Willard <Keith.Will...@gmail.com> wrote:
>
> > > >> > > Where is the snapshot respository where the versions 1.1-SNAPSHOT

> > > >> > > codehausgwt-maven-pluginlives?  only the 1.0 is in the central
> > > >> > > repository.

[mgrouch]

So far I got this. This seems just a beginning

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.sf.gwtstarter.gwt16</groupId>
<artifactId>gwt16</artifactId>
<version>0.0.1-SNAPSHOT</version>
<repositories>
<repository>
<id>gwt-maven</id>
<url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/</url>
</repository>
<repository>
<id>gwt-ext</id>
<url>http://www.gwt-ext.com/maven2/</url>
</repository>
<repository>
<id>gwt-ext-ux</id>
<url>https://gwtstarter.svn.sourceforge.net/svnroot/gwtstarter/
trunk/m2repo/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>snapshots.repository.codehaus.org</id>
<url>http://snapshots.repository.codehaus.org/</url>
</pluginRepository>
<pluginRepository>
<id>gwt-maven</id>
<url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/</url>
</pluginRepository>
</pluginRepositories>
<properties>
<gwtVersion>1.6.4</gwtVersion>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>${gwtVersion}</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwtVersion}</version>
</dependency>
<dependency>
<groupId>com.smartgwt</groupId>
<artifactId>smartgwt</artifactId>
<version>1.0b1</version>
<type>jar</type>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>${gwtVersion}</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwtVersion}</version>
<classifier>${platform}</classifier>
</dependency>
</dependencies>
<profiles>
<profile>
<id>gwt-dev-windows</id>
<properties>
<platform>windows</platform>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
<os>
<family>windows</family>
</os>
</activation>
</profile>
<profile>
<id>gwt-dev-mac</id>
<properties>
<platform>mac</platform>
</properties>
<activation>
<activeByDefault>false</activeByDefault>
<os>
<family>mac</family>
</os>
</activation>
</profile>
<profile>
<id>gwt-dev-linux</id>
<properties>
<platform>linux</platform>
</properties>
<activation>
<activeByDefault>false</activeByDefault>
<os>
<name>linux</name>
</os>
</activation>
</profile>
</profiles>
<build>
<!-- To define the plugin version in your parent POM -->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.1-SNAPSHOT</version>
</plugin>
</plugins>
</pluginManagement>
<!-- To use the plugin goals in your POM or parent POM -->
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.1-SNAPSHOT</version>
<configuration>

<gwtVersion>${gwtVersion}</gwtVersion>
</configuration>

<executions>
<execution>
<configuration>
<module>com.mycompany.gwt.Module</module>
</configuration>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<additionalProjectnatures>
<projectnature>
com.google.appengine.eclipse.core.gaeNature
</projectnature>
<projectnature>
com.google.gwt.eclipse.core.gwtNature
</projectnature>
<projectnature>
com.google.gdt.eclipse.core.webAppNature
</projectnature>
<!--

<projectnature>org.springframework.ide.eclipse.core.springnature</
projectnature>
-->
</additionalProjectnatures>
<additionalBuildcommands>
<!--
<buildcommand>
org.springframework.ide.eclipse.core.springbuilder
</buildcommand>
-->
<buildcommand>
com.google.gdt.eclipse.core.webAppProjectValidator
</buildcommand>
<buildcommand>
com.google.appengine.eclipse.core.enhancerbuilder
</buildcommand>
<buildcommand>
com.google.appengine.eclipse.core.projectValidator
</buildcommand>
<buildcommand>
com.google.gwt.eclipse.core.gwtProjectValidator
</buildcommand>
</additionalBuildcommands>
</configuration>
</plugin>
</plugins>
</build>
</project>