Last Call for Branch Testing - before it gets merged to trunk

[Charlie Collins]

If anyone can help with testing the branch -
http://groups.google.com/group/gwt-maven/browse_thread/thread/d2e35d5fb546099a
- it would be greatly appreciated. It does a few things differently
(see the thread for details), and though it's more elegant, I am not
sure it addresses all situations, as it hasn't been extensively tested
- yet.

It's been around a few weeks though, and several people are using it
successfully (myself included).

If you can, it would be much appreciated if you grab it, build it, and
test it with some existing projects.

I want to get all the feedback I can, to address stuff, BEFORE it gets
merged (I will get feedback after, that I am sure of, but trying to
mitigate that if I can ;)).

I might try to merge it sometime this weekend if I get time, unless I
have any other feedback about problems.

[Arthur Kalmenson]

I'd like to test this branch out, hopefully it'll solve my problem
running the gwt:gwt goal with GWT 1.5.1 (i.e. not working). However, I
checked out the branch and tried to run 'mvn package' but the build
failed because it required jdom 1.1 (which isn't in the central repo).
I'm fairly new to Maven and I'm not even sure how I would use this
plugin from disk. Is it possible to put it into your Google Code Maven
repo?

Regards,
Arthur Kalmenson

On Aug 26, 3:17 pm, Charlie Collins <charlie.coll...@gmail.com> wrote:
> If anyone can help with testing the branch -http://groups.google.com/group/gwt-maven/browse_thread/thread/d2e35d5...

[John Kroubalkian]

You might consider pulling the jdom 1.1 from the main jdom site and then manually installing it in your local repository.

[Charlie Collins]

Yeah, sorry about that, JDOM 1.1 is a pain. I knew JDOM wasn't in
central, so I added a repo to the POM of the support jar for it (the
support jar is really what needs it, but maven is smart enough to try
to get transitive deps). I forgot that this would be a problem for
people that didn't build the support jar locally, my bad.

This is the repo though, if you add it to the POM, should work.:

<repository>
<!-- needed at the moment for jdom 1.1 (not in central) -->
<id>random-for-jdom</id>
<url>http://www4.rothamsted.bbsrc.ac.uk/ondex/maven2</url>
</repository>

(Also, I will build the branch and put it in our repo somewheres with
a different classifier on the name, so people that want to test don't
have to build it - one moment please - building it now . . . . . . )

[Charlie Collins]

Try just using "2.0-ccbranch-beta22" in your POM - the branch build as
of seconds ago is now in our repo. Anyone else that wants to test,
please try that too.

NOTE - you would still need to do "mvn site" on your own, to get the
docs (in target).

ALSO NOTE - there is a sample project INSIDE the branch that is also
handy in terms of showing you what a POM should look like - if you
don't have the branch source you can also just browse it here -
http://gwt-maven.googlecode.com/svn/branches/cc_20080814_automaticrefactor/simplesample/pom.xml.

On Aug 26, 4:49 pm, Arthur Kalmenson <arthur.k...@gmail.com> wrote:

[Mirko Nasato]

2008/8/27 Charlie Collins <charlie...@gmail.com>

Try just using "2.0-ccbranch-beta22" in your POM - the branch build as
of seconds ago is now in our repo.

Version numbers can be tricky.  Because of the way version strings are compared, "2.0-ccbranch-beta22" comes after, i.e. is considered newer, than any "2.0-beta*" version.  If you declare the plugin without version, it will use the latest version.  As long as it's not referenced in the maven-metadata.xml it won't download the "ccbranch" one, but if you have it in your local repository I think it will always use that one.

[Mirko Nasato]

I get some noise from the shell script trying to move files that don't exist when doing gwt:compile:

Compiling module publisher.Publisher
Compilation succeeded
Linking compilation into /path/to/module
mv: cannot stat `/path/to/module/std/*': No such file or directory
mv: cannot stat `/path/to/module/xs/*': No such file or directory
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL

What's supposed to be in /std/* and /xs/* ?  I'm on Linux BTW.

2008/8/26 Charlie Collins <charlie...@gmail.com>

[Charlie Collins]

I will remove that version later then (so it doesn't cause
unintentional issues), good to know.

On Aug 27, 7:07 am, "Mirko Nasato" <mirko.nas...@gmail.com> wrote:
> 2008/8/27 Charlie Collins <charlie.coll...@gmail.com>

[Charlie Collins]

Those are compiler output dirs, but that code isn't new in the branch
(been there a while).

From Bruce's GWT 1.5 release announcement.
"The compiler output now goes into a subdirectory (e.g. ".../std" or
".../xs", depending on your linker
settings<http://code.google.com/p/google-web-toolkit/wiki/
LinkerDesign>
) "

We need to double check that existing code to make sure it's looking
in the correct place for those files (and understand what it's trying
to do to them), and we probably should make it smart enough to skip
them when they are not there - if that is a possible case. I will
check into it further.

On Aug 27, 7:19 am, "Mirko Nasato" <mirko.nas...@gmail.com> wrote:
> I get some noise from the shell script trying to move files that don't exist
> when doing gwt:compile:
>
> Compiling module publisher.Publisher
> Compilation succeeded
> Linking compilation into /path/to/module
> mv: cannot stat `/path/to/module/std/*': No such file or directory
> mv: cannot stat `/path/to/module/xs/*': No such file or directory
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
>
> What's supposed to be in /std/* and /xs/* ?  I'm on Linux BTW.
>

> 2008/8/26 Charlie Collins <charlie.coll...@gmail.com>

>
>
>
> > If anyone can help with testing the branch -
>

> >http://groups.google.com/group/gwt-maven/browse_thread/thread/d2e35d5...

[Arthur Kalmenson]

Hello Charlie,

Thank you for that. I've tried out the plugin, but it's still failing
to find com/google/gwt/dev/GWTShell. This is the same problem I had
with the older version. It seems to find 1.5.1 but it still somehow
has 1.4.61 in it's class path (I greped for it and still can't find
where in the world it's picking up gwt-linux-1.4.61). I'll post the
output from the gwt:gwt goal in the message below. I will make another
post for my simple build file:

Best regards,
Arthur Kalmenson

On Aug 27, 6:51 am, Charlie Collins <charlie.coll...@gmail.com> wrote:
> Try just using "2.0-ccbranch-beta22" in your POM - the branch build as
> of seconds ago is now in our repo.  Anyone else that wants to test,
> please try that too.
>
> NOTE - you would still need to do "mvn site" on your own, to get the
> docs (in target).
>
> ALSO NOTE - there is a sample project INSIDE the branch that is also
> handy in terms of showing you what a POM should look like - if you

> don't have the branch source you can also just browse it here -http://gwt-maven.googlecode.com/svn/branches/cc_20080814_automaticref....

[Arthur Kalmenson]

OK, it doesn't look like Google Groups wants to let me post that
output, perhaps it's too long.

Build output: http://eugeneciurana.com/pastebin/pastebin.php?show=32595

The simple pom.xml file: http://eugeneciurana.com/pastebin/pastebin.php?show=32596

Regards,
Arthur Kalmenson

[Mirko Nasato]

The plugin output says

  google.webtoolkit.home (gwtHome) set, using it for GWT dependencies - /usr/local/lib/gwt-linux-1.4.61

so you must have google.webtoolkit.home defined somewhere and pointing to 1.4.61  - if not in your pom.xml, then maybe in your settings.xml?

2008/8/27 Arthur Kalmenson <arthu...@gmail.com>

[Arthur Kalmenson]

Thanks Mirko! While it wasn't in my pom.xml or ~/.m2/settings.xml
(which I checked before), there happened to be a profile entry in the
global settings file at /usr/local/apache-maven-2.0.8/conf/
settings.xml. I've removed it and it sort of works.

It seems that the gwt-dev-1.5.1-linux-libs.zip that was downloaded by
the Maven, needs to be unzipped. I did it by hand, but is there a way
to do it automatically? After unzipping that file, I was able to run
gwt:gwt and everything worked!

Aside from the attempted mv, everything looks good Charlie.

Regards,
Arthur Kalmenson

On Aug 27, 9:28 am, "Mirko Nasato" <mirko.nas...@gmail.com> wrote:
> The plugin output says
>
>   google.webtoolkit.home (gwtHome) set, using it for GWT dependencies -
> /usr/local/lib/gwt-linux-1.4.61
>
> so you must have google.webtoolkit.home defined somewhere and pointing to
> 1.4.61  - if not in your pom.xml, then maybe in your settings.xml?
>

> 2008/8/27 Arthur Kalmenson <arthur.k...@gmail.com>

[Mirko Nasato]

The libs.zip will be unzipped if you add the unpack goal to your pom.xml, like in the simplesample project available in the new branch: http://is.gd/1YpX

2008/8/27 Arthur Kalmenson <arthu...@gmail.com>

[Arthur Kalmenson]

I just tried it out, works great! Thanks.

On Aug 27, 1:21 pm, "Mirko Nasato" <mirko.nas...@gmail.com> wrote:
> The libs.zip will be unzipped if you add the unpack goal to your pom.xml,
> like in the simplesample project available in the new branch:http://is.gd/1YpX
>

> 2008/8/27 Arthur Kalmenson <arthur.k...@gmail.com>

[Arthur Kalmenson]

OK, so while launching hosted mode works for a very small project that
uses only GWT widgets, I get classpath issues when I start importing
3rd party modules in my .xml.gwt file. This third party module lives
in my local repository and is included as a dependency in the same way
gwt-user is included. However, when I run gwt:gwt, the hosted mode log
shows that it was unable to inherit the third party module because
it's not in the classpath. I tried adding the module into the compile
targets, but to no effect (and it doesn't make sense that it would
since the compilation should pick up the additional modules). I'm not
sure if this is a problem with the new version or something that I did
wrong...

Regards,
Arthur Kalmenson

On Aug 26, 3:17 pm, Charlie Collins <charlie.coll...@gmail.com> wrote:

> If anyone can help with testing the branch -http://groups.google.com/group/gwt-maven/browse_thread/thread/d2e35d5...

[Charlie Collins]

I will try some third party modules too - I honestly haven't checked
that yet. Just one thing before I look into it though, make sure your
modules and dependencies have the SOURCE in them if they are GWT
libraries (third party modules usually do, but if they are your own,
either make sure the source is in them, or that you include a special
source jar as a dependency).

[Arthur Kalmenson]

Good point, I don't have the source code in my JAR. I created a
separate source jar using source:jar, placed that in my local repo and
made a dependency on it. Nevertheless, I'm still getting the same
errors. Maybe if I could package the class files and source files
together it might work (which is what I did when I was using Ant).
However, I looked around and I couldn't figure out how that would be
done.

Regards,
Arthur Kalmenson

[Mirko Nasato]

First question on the FAQ ;-)

  http://code.google.com/p/gwt-maven/wiki/M2FAQ

2008/8/27 Arthur Kalmenson <arthu...@gmail.com>

[Charlie Collins]

You can also use a source jar, if that is your preference, just so
long as the source is on the classpath. I will try some third party
lib stuff today to make sure it's not a classpath scope issue with the
branch (which is possible - but I don't think that's it, just need to
check).

[Arthur Kalmenson]

I tried Mirko's suggestion and it now the jars do include the source
files. I think I've also better understood the problem with the
classpaths. This seems to be a scoping issue (as you suggested). I
have the third party library scoped as provided so the gwt:compile
goal runs with it in the classpath:

DEBUG SCRIPT CLASSPATH LIST
/home/arthur/.m2/repository/com/google/gwt/gwt-user/1.5.1/gwt-
user-1.5.1.jar
/home/arthur/.m2/repository/com/google/gwt/gwt-dev/1.5.1/gwt-
dev-1.5.1-linux.jar
/home/arthur/work/mshab/mshab-demo/src/main/java
/home/arthur/work/mshab/mshab-demo/src/main/resources
/home/arthur/work/mshab/mshab-demo/classes
/home/arthur/work/mshab/mshab-demo/target/classes
/home/arthur/.m2/repository/com/sinai/mshab/mshab-format/1.0-
SNAPSHOT/mshab-format-1.0-SNAPSHOT.jar

However, when it gets to running gwt:gwt, the classpath changes and
doesn't include mshab-format:

DEBUG SCRIPT CLASSPATH LIST
/home/arthur/.m2/repository/com/google/gwt/gwt-user/1.5.1/gwt-
user-1.5.1.jar
/home/arthur/.m2/repository/com/google/gwt/gwt-dev/1.5.1/gwt-
dev-1.5.1-linux.jar
/home/arthur/work/mshab/mshab-demo/src/main/java
/home/arthur/work/mshab/mshab-demo/src/main/resources
/home/arthur/work/mshab/mshab-demo/classes
/home/arthur/work/mshab/mshab-demo/target/classes

This is why hosted mode says mshab-format.xml isn't in the classpath.
I tried to scope it as runtime, but that didn't do anything (except
not include it during the compile step).

Regards,
Arthur Kalmenson

[Charlie Collins]

Ok, several things here.

First, I updated the normal sample app (http://gwt-
maven.googlecode.com/svn/trunk/maven-googlewebtoolkit2-sample/) to use
the new ccbranch of the plugin. I did this to test multi-module,
including a GWT library from one project in another, and so on. I get
exactly the same problem, the build runtime classpath isn't getting
the compile scoped dependencies (those that are either scoped compile,
or have nothing, which means they inherit default scope - compile).
It should get the compile ones, as they are supposed to be available
in ALL scopes (the runtime should ADD the runtime stuff, but not have
just the runtime and above).

I will look at this ASAP.

[Charlie Collins]

I found the problem, the @requiresDependencyResolution in the GWTMojo
was provided. Not sure why (or even if I did it ;)). I changed it to
compile, and made one quick change to the BuildClasspathUtil, and it
works. That might give us too many dependencies in some contexts,
possibly, but it fixes this specific issue, and is arguably what we
will have to do. (I also updated the regular sample application to
use the new plugin and test this - (http://gwt-
maven.googlecode.com/svn/trunk/maven-googlewebtoolkit2-sample).

Thanks for reporting this.

ALSO NOTE - I changed the name of the build I just did to 2.0-beta22-
SNAPSHOT and removed the "ccbranch" one. I did this for 2 reasons,
one to avoid the latest version number thing brought up here, and two
to use the conventional SNAPSHOT so I can just overwrite the same one
if and when we find more issues.

USE 2.0-beta22-SNAPSHOT for testing the branch (but this is NOT an
official GWT-Maven release, yet)

[Arthur Kalmenson]

Great! I've filled a bug report with regards to this problem:
http://code.google.com/p/gwt-maven/issues/detail?id=139

Regards,
Arthur Kalmenson

[Arthur Kalmenson]

Great, thank you Charlie, it works. Just one note, I think that the
sample POM files shouldn't include compile in the goals for running
gwt:gwt. It confused me for a while there because it was taking an
awfully long time to launch hosted mode (it had to run the GWT
compiler on the app for each launch of hosted mode). The compile goal
should probably only run when you package the GWT app as a WAR file.

On Aug 28, 10:17 am, Charlie Collins <charlie.coll...@gmail.com>

[Charlie Collins]

I will check into that.

Note though that once you launch hosted mode, you don't have to keep
re-launching it, you can make changes, refresh, and see them there
(not server side changes of course, but you know what I mean).

[Charlie Collins]

I changed the GWTMojo to run compile phase, rather than package
phase. The makes the shell startup a LOT faster (don't need to run
GWTCompiler and make a war, just to run shell). I don't think there
will be any problems with this, but I still need to check some corner
cases.

[Charlie Collins]

Just an update - this branch will get merged soon, but it didn't
happen this weekend and may still be a few days.

I *DID* do a bunch of work this weekend, refactoring the code so that
we don't have repeated statements everywhere (a few interfaces, and a
util or two), and I worked on GWTTestCase based testing getting more
standardized/robustified. It's not done yet, but I do have a initial
approach working in the branch (I am writing a test script out, the
same way we write a compile script, shell script, etc - the difference
is that I do it for EACH testcase, so that I can run each
individually, and then catch the output and record results, etc).

Also, I spent a few hours more wrestling with Surefire and
GWTTestCase. I got it very close, but still ran into classpath issues
ultimately. I went down this in vain road again, because if we can
just get that to work the world would be so much better than gwt:test
hacks - but couldn't get it to work (long complicated story, the way
JUnitShell expects regular classpath, and surefire won't provide it).

Anyway, more in the branch now, try it again if you please - and
expect a merge to trunk soon.