Mavenize the project

[GoogleCodeExporter]

Let's go all the way and mavenize the project. We should still try to make it 
easy for anybody to run it in eclipse even if they don't have the Maven plugin 
(which I find is always a headache to install).

Original issue reported on code.google.com by philippe.beaudoin on 22 Sep 2010 at 4:54

[GoogleCodeExporter]

Original comment by philippe.beaudoin on 22 Sep 2010 at 2:03

• Added labels: Component-Global

[GoogleCodeExporter]

Need help with this?
Do you want to refactor the project to use maven project layout or just have a 
working build?

Original comment by kuhnro...@gmail.com on 23 Sep 2010 at 12:44

[GoogleCodeExporter]

Yes, the goal is to refactor to use the maven project layout. Thanks for 
proposing to help. ahhughes is already working on this, you can see with him if 
he needs your help.

Original comment by philippe.beaudoin on 23 Sep 2010 at 5:06

[GoogleCodeExporter]

Update on this? I've made it high priority.

Original comment by philippe.beaudoin on 29 Sep 2010 at 6:54

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

See update in 
https://wave.google.com/wave/#restored:wave:googlewave.com%252Fw%252BZYi_Prc-A

Original comment by kuhnro...@gmail.com on 30 Sep 2010 at 8:51

[GoogleCodeExporter]

Hi Guys,

I made some decent progress tonight... but not ready to push (to a new repo or 
branch) yet.

Looking at this codebase I think maven multi module's should def be used. 
client, server and shared code all have discrete scopes (some are compile time, 
some runtime and some not visible to parts of your app (for instance someones 
client code should NEVER see server code on their development/IDE classpath).

I suggest...

./gwt-platform/pom.xml <packaging>pom</packaging>
./gwt-platform/gwt-platform-client/pom.xml <packaging>jar</packaging> includes 
*.class and *.java
./gwt-platform/gwt-platform-shared/pom.xml <packaging>jar</packaging> includes 
*.class and *.java
./gwt-platform/gwt-platform-server/pom.xml <packaging>jar</packaging> includes 
*.class (source jar independent)

At the end of the day this would produce...
gwt-platform-client-1.0.0.jar
gwt-platform-shared-1.0.0.jar
gwt-platform-server-1.0.0.jar

This is very much the norm in gwt-maven and I would strongly recommend it.

QUESTION:
Should dispatch, mvp, crawler all be isolated modules too??? This would have 
modules named...

gwt-platform
gwt-platform-dispatch-client
gwt-platform-dispatch-shared
gwt-platform-dispatch-server
gwt-platform-mvp-client
gwt-platform-mvp-shared
gwt-platform-mvp-server
...

Don't be scared to created modules, they define very sensible boundaries :)

QUESTION:
What's the best showcase if I add one as a module? This really should be done 
for the peoples sake (my own learning included!).

QUESTION:
What's the role of the web.xml in the project source???? This project is not an 
executable webapp right????

Original comment by ahhug...@gmail.com on 30 Sep 2010 at 3:12

[GoogleCodeExporter]

This is becoming a bit overkill. I don't think we should split in 
client/shared/server because:
1) GWT will not compile the unused code to javascript anyway
2) The server code can (and often does) depend on classes in the client module. 

Note for (2): it probably should never depend on code in client, but 
historically it does, because GWT advises placing RPC interfaces in client (but 
they are needed in the server). In GWTP it's worse: things like TokenFormatter 
are often useful on the server.

So for the moment I propose:

gwtp-crawler-0.5.0.jar
gwtp-dispatch-0.5.0.jar
gwtp-mvp-0.5.0.jar
gwtp-tester-0.5.0.jar
gwtp-tester-mockito-0.5.0.jar

Let's take this opportunity to rename the "test" module to "tester": Issue 221

Also, what will we do with the new shared classes coming up in Issue 216?

Original comment by philippe.beaudoin on 2 Oct 2010 at 4:35

[GoogleCodeExporter]

I so agree with Philippe (below are my comments initially written for a post in 
the group):
--
I thing that it is a good idea to split gwtp in modules as it grows bigger. As 
you know, GWT has its own modularization system (using *.gwt.xml files) and its 
easy to mess it up when trying to use maven as well. From my experience, I 
think that the most reasonable and simple way to structure a GWT project with 
maven is to have a one-to-one relation between a gwt-module and a maven-module 
(i.e. one gwt.xml file in regard to one pom.xml). 

Following this assumption, and by looking to the current state of trunk I 
suggest to create a multi-module maven project with the following children 
modules:
gwtp (parent pom.xml - common configuration, dependency and plugin management)
  \- gwtp-mvp (pom.xml - Mvp.gwt.xml)
  \- gwtp-dispatch (pom.xml - Dispatch.gwt.xml)
  \- gwtp-crawler (pom.xml - Crawler.gwt.xml)
  \- gwtp-test-utils (pom.xml - not a GWT module)
and maybe:
  \- gwtp-all (aggregate project)

Although, I am not sure what should be done for annotation package.. maybe 
gwtp-utils?  

Other remarks: 
- the standard maven directory structure should be honored
- teamcity should be configured to build the artifacts with maven
- javadoc and sources should be attached for each artifact
- tools in maven should be used to automate the release process.

IMHO ant support can be completely replaced be maven. In case you take the step 
to create a multi-module project it will be just an overhead to try and keep 
ant in sync and vice versa. 
--

After seeing Issue 216 it makes more sense to create a gwtp-utils module to 
accommodate for all these common/shared/utility classes.

Original comment by jgon...@gmail.com on 2 Oct 2010 at 7:38

[GoogleCodeExporter]

I like the idea of an aggregate project. I agree we should drop ant support.

What do we do about the mockito dependancies? The tester module has some 
mockito-idenpendant classes interesting on their own.

Original comment by philippe.beaudoin on 2 Oct 2010 at 7:42

[GoogleCodeExporter]

I have to give it more thought but just to quick-reply I can see the following 
two solutions:

1) Either to include both mockito (in)dependent test helper classes into a 
single module (mockito will be a transient dependency)
2) or to have two separate modules as you described e.g. gwtp-tester and  
mockito-gwtp-tester (but isn't it an overkill?)

Original comment by jgon...@gmail.com on 2 Oct 2010 at 8:22

[GoogleCodeExporter]

I don't know what a transient dependency is. (Did you mean transitive 
dependency?) 

If all users of gwtp-tester.jar have to use mockito.jar then I don't see it as 
"overkill" to separate them.

Original comment by philippe.beaudoin on 2 Oct 2010 at 8:47

[GoogleCodeExporter]

I think the test classes should be in one module. Mockito can be an <optional> 
dependency but I don't see the point. The advantage of Maven is that you don't 
have to worry so much about dependencies.

The generators should go into the same module and then call it gwtp-dev. Would 
be just like GWT, people are used to that naming scheme.

Also I have to agree with ahhuges, the modules should mainly be created to 
seperate client/server/dev files and not so much the components.

At one point or another these components might get tied together, for example 
in the future I can imagine a presenter-action binding similar to GWT-2.1 
activities. Then the new classes will need another module again... this can 
very well end in a multitude of modules.

Original comment by kuhnro...@gmail.com on 2 Oct 2010 at 9:04

[GoogleCodeExporter]

Sorry, I meant to write transitive dependency 
(http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-proj
ect-dependencies.html#pom-relationships-sect-transitive). You have guessed 
correctly :)

Original comment by jgon...@gmail.com on 2 Oct 2010 at 9:22

[GoogleCodeExporter]

Guys, great to see some traction on this one!

I'll 2nd the recommendation of jgonian 
(http://code.google.com/p/gwt-platform/issues/detail?id=211#c8).... with gwt 
modules to maven modules having a 1:1 relationship and look similar too...

.gwtp (pom.xml)
  \- gwtp-mvp (pom.xml - Mvp.gwt.xml)
  \- gwtp-dispatch (pom.xml - Dispatch.gwt.xml)
  \- gwtp-crawler (pom.xml - Crawler.gwt.xml)
  \- gwtp-test-utils (pom.xml - not a GWT module)

The only significant issue I have with this is that client, shared and server 
code should be isolated into different maven modules. They have different 
scopes, different compilers and different constraints - they should be 
isolated. Isolating these is a very kind thing to do not so much for gwtp, but 
for all the projects that will depend on gwtp.

This would give something like...
.gwtp (pom.xml)
  \- gwtp-mvp-shared (pom.xml)
  \- gwtp-mvp-client (pom.xml - Mvp.gwt.xml)
  \- gwtp-mvp-server (pom.xml)
  \- gwtp-dispatch-shared (pom.xml)
  \- gwtp-dispatch-client (pom.xml - Dispatch.gwt.xml)
  \- gwtp-dispatch-server (pom.xml)
  \- gwtp-crawler-shared (pom.xml)
  \- gwtp-crawler-client (pom.xml - Crawler.gwt.xml)
  \- gwtp-crawler-server (pom.xml)

Which is actually a 1:3 mapping... 

Also, I agree with the comments about sicking to the stardard directory 
structure. This really helps developers feel at home (with a previously unseen 
project/codebase).

I'll make the multi-module changes in my local repo soon and prepare to push 
them out to a new repo for people to review :)

Aggrogate project's aren't my forte, so I can't contribute to this yet sorry.

Cheers :)

Original comment by ahhug...@gmail.com on 3 Oct 2010 at 2:51

[GoogleCodeExporter]

Like I said, Mockito could be marked as optional dependency.

Original comment by kuhnro...@gmail.com on 3 Oct 2010 at 11:06

[GoogleCodeExporter]

On the one hand we can split GWTP into modules based on where the code is meant 
to be executed like this (@kuhnroyal please correct me if I am wrong):
.gwtp (pom.xml)
  \- gwtp-user (pom.xml, mvp.gwt.xml, dispatch.gwt.xml - client side code)
  \- gwtp-server (pom.xml, dispatch-server, crawler(?) - server side code)
  \- gwtp-dev (util classes, test helpers, generators)

PROS: Simple. Flexible. Resembles GWT structure
CONS: A user who wants to use just a single component of GWTP, e.g. the MVP, he 
will have to depend on gwt-user.jar but inherit just form Mvp.gwt.xml. 

On the other hand we can create a module hierarchy based on components:
.gwtp (parent pom.xml)
 \- gwtp-mvp (pom.xml - Mvp.gwt.xml)
 \- gwtp-dispatch (parent pom.xml)
   \- gwtp-dispatch-shared (pom.xml)
   \- gwtp-dispatch-client (pom.xml - Dispatch.gwt.xml)
   \- gwtp-dispatch-server (pom.xml)
 \- gwtp-crawler (pom.xml - Crawler.gwt.xml)
 \- gwtp-tester (pom.xml) (with optional dep on mockito)
 \- gwtp-commons/utils (pom.xml)

@ahhughes: Is there a reason to have "server" or "shared" code for MVP? Isn't 
it meant to run client code only? and I am not sure about crawler either.

PROS: Well-organized. A user can select just the components he wishes to use. 
It is possible to group these modules into aggregated projects like this:
(Read the following with a grain of salt since I have never used it in that 
extend before and maybe I am missing something. The concept is described here: 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-b
est-practice.html#pom-relationships-sect-grouping-deps ) 
.gwtp (parent pom)
 \- gwtp-user (packaging pom)
    has dependency to gwtp-mvp
    has dependency to gwtp-dispach-shared
    has dependency to gwtp-dispatch-client
    has dependency to gwtp-crawler
 \- gwtp-server (packaging pom)
    has dependency to gwtp-dispach-shared
    has dependency to gwtp-dispatch-server
    ...
 \- gwtp-dev (packaging pom)
    has dependency to gwtp-tester
    has dependency to gwtp-commons
    ...
Of-course all these can be enjoyed only by other maven projects which declare a 
pom dependency on an "aggregated" project e.g. gwtp-user. However, here is an 
example following the concept above to assembly a consolidated build (e.g. 
gwtp-all): 
http://docs.codehaus.org/display/MAVEN/Multi-modules+application+with+consolidat
ed+build

CONS: Advanced. More difficult for someone who is not familiar with maven. 
Over-engineered(?)

Over to you,

Original comment by jgon...@gmail.com on 3 Oct 2010 at 11:06

[GoogleCodeExporter]

@kuhnroyal Sorry. I don't have a clue what an optional dependency is. :) My 
question is: can we include mockito-dependant code in the .jar and not impact 
users who don't use mockito.

@jgonian I like your second proposal. I definitely think module-based 
separation is important. Somebody who wants to use only dispatch does not care 
about crawler at all. If your backend is appengine, minimizing the size of your 
server-side jar is important for cold-start performance.

Now I'm still not convinced it's worth splitting dispatch in 
shared/client/server, here's why:

The separation between client, shared and server is not important for the 
user's client code: GWT's compiler will never include any server code (or any 
unused code at all for that matter) in the javascript.

The separation between shared and server is not important for the server code: 
both jars will be required on the server anyway.

This suggest the following separation:
gwtp-dispatch-client  (contains com.gwtplatform.dispatch.client.**)
gwtp-dispatch         (contains com.gwtplatform.dispatch.server.** and 
                                com.gwtplatform.dispatch.shared.** )

The user's client code depends on gwtp-dispatch-client and gwt-dispatch, the 
server code depends only on gwtp-dispatch.

HOWEVER:
As I've said earlier, some of GWTP's classes in client are useful to the 
server. As a result, the server will still need both jars.

In conclusion, for the moment, there is no point at all in separating 
gwtp-dispatch in three jars. Also, I don't know if we'll ever get around to a 
clean separation between client and shared (there may be package visibility 
problems, and even GWT puts some server code in the client package). Therefore, 
in the spirit of Agile development, I propose YAGNI: let's not split 
gwtp-dispatch.

Original comment by philippe.beaudoin on 3 Oct 2010 at 4:37

[GoogleCodeExporter]

@philippe yes, optional does exactly that, it is not pulled by automatically by 
Maven :) You said you want to minimize the server-side jar size, that is 
exactly why you need to split the code into client/server jars, you don't want 
all the client classes to be picked up by the appengine classloader.

There should not be a shared jar. The shared package only means that the code 
in this package needs to go into both (client/server) jars.

Therefor:
gwtp-dispatch-client  (contains com.gwtplatform.dispatch.client.** and 
                                com.gwtplatform.dispatch.shared.** )
gwtp-dispatch-server  (contains com.gwtplatform.dispatch.server.** and 
                                com.gwtplatform.dispatch.shared.** )

Original comment by kuhnro...@gmail.com on 4 Oct 2010 at 9:41

[GoogleCodeExporter]

@kuhnroyal Re: "You said you want to minimize the server-side jar size, that is 
exactly why you need to split the code into client/server jars, you don't want 
all the client classes to be picked up by the appengine classloader."

My problem is that, unfortunately, in the current state you need the client 
classes on the server.

Original comment by philippe.beaudoin on 4 Oct 2010 at 3:51

[GoogleCodeExporter]

@philippe.beaudoin Comment #19

When you have code required by both client AND server, these classes are 
normally placed in a maven module called '*-shared'. Both client and server 
both have a dependency on the shared code (it's pretty straight forward).

Example:

./cl2-moduleX-client/pom.xml
<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>gwtp-moduleX-shared</artifactId>
    <version>${project.version}</version>
</dependency>

./cl2-moduleX-server/pom.xml
<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>gwtp-moduleX-shared</artifactId>
    <version>${project.version}</version>
</dependency>

Original comment by ahhug...@gmail.com on 4 Oct 2010 at 11:37

[GoogleCodeExporter]

I've pushed some mavenization up for people to evaluate, but I still have a lot 
todo...

http://code.google.com/r/ahhughes-issue211mavenization/source/browse/

Q: At the moment my gwtp-dispatch-client module has to depend on 
gwtp-mvp-client. See ClientActionHandlerRegistry, 
DefaultClientActionHandlerRegistry and DefaultDispatchAsync. All three require 
IndirectProvider from gwtp-mvp-client. Im not sure IndirectProvider really 
belongs in with the MVP code.... idea's?

@jgonian - I'm not ignoring your comments about grouping modules. It' is really 
easy to move modules around (once we have them as modules). Identifying the 
discrete modules is something we need to do as a predecessor :D

Nighto.

Original comment by ahhug...@gmail.com on 5 Oct 2010 at 2:27

[GoogleCodeExporter]

@ahhughes: No worries, I just tried to illustrate how is it possible to create 
an "aggregated" project in maven. I 'm not even convinced that we need 
something like that. As you said the most important step is to identify the 
modules. 
Keep up the good work :)

Original comment by jgon...@gmail.com on 5 Oct 2010 at 9:09

[GoogleCodeExporter]

Progress Report: 
http://code.google.com/r/ahhughes-issue211mavenization/source/detail?r=025c8241a
7837a7dbb499ff59c457efa3be0d954

Got everything (excluding tests) compiling, building and the relationship 
between modules sorted (modules are still not clean tho).

The big news was that I added the basic sample to the project as a module. It 
now builds as the last module in the gwtp project and you can fire up gwt dev 
mode.

If anyone feels like testing this out (WITH THE REVSION POSTED ABOVE) from 
command line with maven...
cd ./gwt-platform
mvn clean install
cd ./gwt-sample-basic
mvn gwt:run

There's a few warnings an a lot of things still to be addressed, but since we 
have a working maven build and working maven app in the same build lifecycle.. 
thats something :)

Ciao
--AH

Original comment by ahhug...@gmail.com on 6 Oct 2010 at 2:05

[GoogleCodeExporter]

Great progress, thanks! I wont test it myself (my maven-fu is too poor), but I 
look forward to other's comments.

Original comment by philippe.beaudoin on 6 Oct 2010 at 3:56

[GoogleCodeExporter]

@ahhughes: I tested it and it works as expected. You are definitely on the 
right track :)

As you said there is still quite a lot to address and I' ll try to keep up with 
the review in order to help. If you 'd like you could ask for a code review on 
rietveld (for the pom files) to make it easier.

Some thoughts after the pom-skimming:
1. I liked your idea with the sample project. From that, another idea was born. 
Mavenize gwtp samples as well :)
  .gwtp (parent pom)
   \- gwtp-mvp
   ... 
   \- gwtp-samples
      \- basic-sample
      \- hplace-sample
      \- nested-sample
      \- tab-sample
2. About gwt-dispatch, how do you plan to remove the dependency of 
gwt-dispatch-client on gwtp-mvp-client? Is it possible to extract common client 
code to another module? 
3. I agree that 'system' scoped dependencies should be removed. Use of this 
scope is discouraged. It was not a not a good choice to use it in order to deal 
with custom compiled dependencies. These jars should be uploaded to a repo so 
that they can be resolved as transitive dependencies.
4. I am pretty sure that you have it in mind, but just in case you missed it 
the groupId should be com.gwtplatform instead of com.philbeaudoin.  

gn

Original comment by jgon...@gmail.com on 7 Oct 2010 at 9:38

[GoogleCodeExporter]

@jgonian

re:
1. Samples should def be tied to the same lifecycle as gwtp... should we 
release a version of gwtp without working set of samples. I say NO :)

2. The gwtp-dispatch-client --depends--> gwtp-mvp-client (from the top of my 
head) was a single class. The GWT Event class that exposes the source of the 
event. That class should probably be in a single 'common-client' module, even 
if there is only one class now.. I'm sure there will be other common classes 
shared that will soon need the same place to live.

3. We can get rid of the system scoped depedencies when the next Gin release 
arrives, which is waiting on the next Guice release to arrive. I'm told this is 
a few weeks away, thanks to Peter Schmitt for the update 
http://groups.google.com/group/google-gin/browse_thread/thread/daa19057f76fac0 
I'm not sure when the next release of gwtp is scheduled, but the system scoped 
gin dependency is UGLY, if next Gin release is just a few weeks away I'd 
recommend we wait for this and iron out all the creases in the meantime :)

4. Yup, there's a pretty standard groupId to package to domain naming 
relationship that we should propose when the time is right :)

Cheers for the help :)

Original comment by ahhug...@gmail.com on 7 Oct 2010 at 11:50

[GoogleCodeExporter]

Issue 229 is asking to mavenize samples. Is this something we plan to do here?

Original comment by philippe.beaudoin on 9 Oct 2010 at 5:38

[GoogleCodeExporter]

Yes, but just a heads up.... There are several ways to associate the samples 
with gwtp using maven. None of which are particularly difficult, but they all 
have pro's and con's. Kinda like having your cake and eating it too.

I don't mean to overload people with info here, for the sake of simplicity, 
good practice, making things intuitive and for one small sacrifice I would 
recommend Option 1 (then maybe Option 2). But I've gone to the effort of 
covering two other options for those who want want to know (and also a see what 
maven can potentially do. Plus I am not a maven expert, I just know some of the 
options.

--AH :)

Option 1: Samples Become Modules of GWTP
+Pro when you release gwtp v1.2.3 you get a working set of samples against 
v1.2.3
+Pro when you change code in gwtp you can see if you are breaking a sample.
+Pro consumers download zip/bundles with all they need to use gwtp.
-Con because samples are released as a component of gwtp, you can't do a new 
release of just the samples without releasing+incrementing the version of gwtp. 
Should gwtp 1.2.4 be released if the only changes are in the samples? I can't 
answer this...

Option 2: Samples Become their Own Maven Project
+Pro You can release the samples without releasing a new version of GWTP
-Con you loose the three "Pro's" mentioned in option 1 (this is the cake and 
eat it too part).
-Con because samples and GWTP don't share the same release lifecycle it becomes 
a manual exercise with some kind of defined "process" developers need to 
follow. This is 'ok' but not not what I would call 'intuitive', and thats 
important to open source projects IMHO. How do others feel about this?

Please consider ignoring Option 3 below.... I don't have time to fully explain 
it and I don't think it's entirely appropriate for gwtp.

Option 3: Run Multiple Maven Projects with a Single RELEASED Parent (one 
RELEASED parent project, many child projects gwtp-* and sample-*). From 
10,000ft where 'modules' are not visible this is how all maven projects are 
related.
+Pro Shared config between gwtp and samples because they share the same 
RELEASED <parent>.
+Pro Can release each project independently (but this is also a Con... more 
cake).
-Con have to release each independently (also a pro).
-Con we don't have the infrastructure todo things like snapshot deploy's 
already setup.
-Con to explain all this would take too long and I need to get some work done...

Original comment by ahhug...@gmail.com on 9 Oct 2010 at 11:50

[GoogleCodeExporter]

I vote for option 1, it solves some problems I had with the samples. Samples 
are really tests too.

Original comment by philippe.beaudoin on 10 Oct 2010 at 12:10

[GoogleCodeExporter]

I am in favor of the first option as well.

Original comment by jgon...@gmail.com on 10 Oct 2010 at 8:19

[GoogleCodeExporter]

Issue 229 has been merged into this issue.

Original comment by philippe.beaudoin on 13 Oct 2010 at 4:09

[GoogleCodeExporter]

I've just committed and pushed the places and tab sample. I can't get the 
hplaces sample to work so I have left these out for now. Not that this still is 
not clean.... but it proves it does and can work.

If anyone would like to run these... install maven 2.2.1+

mvn clean install
cd gwtp-sample-***
mvn gwt:run

If anyone would like to open these projects in eclipse...

Install maven 2.2.1+
Install m2eclipse, and configure external maven instance Window -> 
Preferences.. etc
Import Existing Maven project

http://code.google.com/r/ahhughes-issue211mavenization/source/detail?r=69ee5213c
c77f5a0826a2701eeb59bd9d39c9760

Original comment by ahhug...@gmail.com on 19 Oct 2010 at 10:25

[GoogleCodeExporter]

I tested gwtp-sample-basic/nested/tab with maven 2.2.0 and all worked as 
expected :) Let us know if you need any help.

Original comment by jgon...@gmail.com on 19 Oct 2010 at 2:40

[GoogleCodeExporter]

Thanks for testing and the offer of help.

I need help determining which module the annotations should reside in. 
Currently these are in a module called 'gwtp-annotation', but I feel this is 
wrong. If anyone can explain the role of ALL the annotations (are they used 
ONLY for client side code gen?) then I can probably work it out. But now I'm 
not so sure :)

Cheers.

Original comment by ahhug...@gmail.com on 19 Oct 2010 at 10:27

[GoogleCodeExporter]

We discussed the annotation issue in chat, but for the benefit of others 
following this issue:

I believe all the annotations in com.gwtplatform.annotation really belong to 
com.gwtplatform.dispatch.shared.annotation. I don't mind moving them to that 
package for release 0.5.

Also:
- I have been picking up on Maven recently, and really like it. I will be 
actively contributing to this issue from now on.
- I've extracted com.gwtplatform.tester.mockito to another project (check 
http://jukito.org) so there will no longer be a dependency between GWTP compile 
scope and mockito, but there will be one between GWTP test scope and jukito.
- Jukito is mavenized, but I'd like to deploy it to some public maven repo. Any 
expert here can help me do this?

Original comment by philippe.beaudoin on 1 Nov 2010 at 11:20

[GoogleCodeExporter]

Some remarks after trying it out:
- It works out of the box! Very easy! Great job.
- I notice a dependency on GAE in the main pom. I believe only the samples 
depend on AppEngine (and then, only some of them). Should we change this 
somehow?
- I'd like to have a way to mvn package only the main gwtp jars without having 
to compile all the samples. Do you think there is a way to do this?

Original comment by philippe.beaudoin on 1 Nov 2010 at 12:00

[GoogleCodeExporter]

In response to #35 
(http://code.google.com/p/gwt-platform/issues/detail?id=211#c35)

"Jukito is mavenized, but I'd like to deploy it to some public maven repo. Any 
expert here can help me do this?"

Sonatype provide opensource project with repositories to release/deploy 
artifacts too. These repositories are then optinally sync'd with maven's 
central repository and  is now the means by which you can release to all maven 
users by default. They have some good doco on this here:

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage
+Guide

Original comment by ahhug...@gmail.com on 1 Nov 2010 at 12:59

[GoogleCodeExporter]

In reply to #36 (http://code.google.com/p/gwt-platform/issues/detail?id=211#c36)

"- It works out of the box! Very easy! Great job."

Philippe, I am sure you are gonna love it. Most people become maven addicts 
immediately after grasping the basics. :)

"- I notice a dependency on GAE in the main pom. I believe only the samples 
depend on AppEngine (and then, only some of them). Should we change this 
somehow?"

As I am describing below (#2) I think that samples should share a common 
ancestor to keep their dependencies. This way, the GAE dependency can be 
removed from the main pom if not used in any other module.

By the chance, I would like to mention one more related thing. Apart from the 
GAE dependency, I consider the "dependencies-part" as still a "work in 
progress". Currently, each dependency declared in the parent pom is inherited 
by sub-projects. This obviously isn't correct. Instead, a dependencyManagement 
section should be introduced in the parent pom. When this is done, the GAE (or 
any other dependency) will be explicitly declared in the correct sub-projects 
and leaving them declared in the main pom will not effect any of the rest 
modules. 

"- I'd like to have a way to mvn package only the main gwtp jars without having 
to compile all the samples. Do you think there is a way to do this?"

I can think of 3 ways to do this:
1. the quick and dirty: use -pl (project list) option like this:
<gwtp root>$  mvn package -pl (or -projects) gwtp-mvp-client,gwtp-crawler,... 
to select the modules you want to build (but this one doesn't really count as 
an option :)

2. split gwtp into sub-projects, for the sake of example gwtp-core and 
gwtp-samples. Then you simply build gwtp-core and its children regardless of 
gwtp-samples. This approach has the benefit of a parent pom which can 
accommodate for shared dependencies and plugin configuration between its 
children sub-projects. 

3. create a maven profile to include just the modules you want to build e.g. 
you would run
mvn package (to build everything) 
mvn package -PexcludeSamples (activate the profile to build only selected 
modules)

or the other way around i.e. exclude sample modules by default and create a 
profile to include them in the build process e.g.
mvn package (to build everything except the samples)
mvn package -PincludeSamples (activate the profile to build everything 
including the samples)

This is not the most sophisticated use of profiles. The usual stuff is to 
create different profiles for different environments or systems (e.g. 
development, staging, windows, e.t.c) or profiles for a "release" build (e.g. 
generate and attach javadoc when release profile is activated).   

I think that #2 is more clean and simple solution. In case you are interested I 
could perform necessary changes (for the dependencies and/or for the samples) 
and upload them in a repo so that you can review.

Original comment by jgon...@gmail.com on 1 Nov 2010 at 7:21

[GoogleCodeExporter]

I like option 2. My take on this is that we should try to bring oven a 
"working" mavenized version in the trunk, even if it's not perfect. That way we 
will not have to evolve and maintain a parallel branch. Once it's in trunk we 
can start making adjustments, like the one you propose.

What do you guys think?

Original comment by philippe.beaudoin on 1 Nov 2010 at 7:31

[GoogleCodeExporter]

@ahhughes Thanks for the tip! I now have a snapshot version of Jukito on 
sonatype repo. Still amazed by how easy it all was.

Original comment by philippe.beaudoin on 1 Nov 2010 at 9:01

[GoogleCodeExporter]

In response to #39 
http://code.google.com/p/gwt-platform/issues/detail?id=211#c39

this was "2. split gwtp into sub-projects"...

This was discussed earlier in comment #28, and we decided it was a good idea 
after looking at the pro's and con's....
http://code.google.com/p/gwt-platform/issues/detail?id=211#c28

Splitting the samples into their own sub project means that the samples are not 
bound to the release lifecycle. There are probably many ways to speed up gwtp 
compilation. Maven has a few options.

To build everything upto module called "gwtp-xyz" (but skip everything 
after)....

mvn -am -pl gwtp-xyz

Original comment by ahhug...@gmail.com on 2 Nov 2010 at 4:49

[GoogleCodeExporter]

I thought this meant submodules. Ie:
+ Top-level gwtp module
+-- gwtp-core module
|   + mvp module
|   + dispatch module
+-- gwtp-samples module
    + basic sample module
    +...

(Note: Maybe my terminology is wrong.)

Given such a setup could we easily build just core with some maven fu?

My point is: I'd love the CI server to build both core and sample every time, 
but when I run it locally I don't want to be bothered with the samples.

Original comment by philippe.beaudoin on 2 Nov 2010 at 4:59

[GoogleCodeExporter]

In comment #38 (option #2) I meant what Philippe explains in comment #42. There 
is a top level pom.xml with two modules.The CI will build both modules and 
these modules belong to the same release lifecycle. 

To build only the core sub-project (in a development environment) you just have 
to change directory and build (not really maven fu stuff just a cd and a mvn 
package will do the job).

Original comment by jgon...@gmail.com on 2 Nov 2010 at 8:20

[GoogleCodeExporter]

Is it me, it seem that the the pom doesn't work with latest trunk.

Original comment by goudreau...@gmail.com on 13 Nov 2010 at 5:37

[GoogleCodeExporter]

We badly need to have Maven right in the trunk, even if it's not perfect. I 
will start working on it.

Original comment by philippe.beaudoin on 14 Nov 2010 at 12:45

[GoogleCodeExporter]

Agreed, sorry I have been a bit busy lately to give this more time.

The clone I took a few weeks back has prooved hard to merge :'( Do you want to 
fix that clone up with me or create a new clone? Depends what you think is the 
lesser of two evils.

Original comment by ahhug...@gmail.com on 14 Nov 2010 at 10:34

[GoogleCodeExporter]

Hi, 

I put some effort to this one during the weekend and got some results. Since it 
proved almost impossible to merge ahhughes' clone, I cloned trunk and started 
from scratch. I combined the previous work of ahhughes and went one step 
further. Still it's far from perfect but I think that it's possible to continue 
on this clone until it's ready to be merged on trunk (hopefully soon). 

highlights:
* split project in submodules (gwt-samples and gwt-core).
* ported annotations from com.gwtplatform.annotation to gwtp-dispatch-shared 
(comment 35) and configured annotation processor in maven to run tests 
successfully
* ported gwtp-tester and its tests successfully
* bumped up to GWT 2.1
* factored out samples' common configuration and upgraded to gwt-maven-plugin 
v2.1.0  
* used dependencyManagement instead of dependency inheritance. Modules 
explicitly ask for a dependency now, thus, it is easier to grasp whats going on 
and spot dependency problems. 
* gwtp-samples and gwtp-core do not share dependencies anymore.
* got rid of system scoped dependencies (custom compiled dependencies need to 
be uploaded to a public repo)

TODO: 
- upload custom compiled dependencies to a public repo and update POM 
configuration 
- we need a stable release of jukito 
- port JRE and GWT tests for gwtp-mvp-client
- port more samples (gwtp-sample-nested, gwtp-sample-tab)
- configure checkstyle
- dependencies cleanup (e.g. dispatch-client should not depend on mvp-client 
e.t.c)
- project cleanup (remove build.xml, lib e.t.c)
- update continuous integration system to use maven
- someone must setup the project on eclipse and update configuration files, 
since I don't use eclipse, sorry :(

to Review:
hg clone https://jgonian-211.googlecode.com/hg/ gwtp-Issue211
cd gwtp-Issue211
mvn install
cd gwtp-samples
cd gwtp-sample-basic
mvn clean gwt:run

cheers,
- Yannis

Original comment by jgon...@gmail.com on 21 Nov 2010 at 3:31

[GoogleCodeExporter]

Hi Yannis,

Much appreciated! I will spend some time to review it soon and will try to 
merge it sooner than later, even if it makes the trunk a little flaky, at least 
we'll be ready for next release.

@ahhugues Do you mind if we switch ownership of this issue to Yannis, he seems 
to have a bit more time to work on it these days.

Original comment by philippe.beaudoin on 21 Nov 2010 at 4:59

[GoogleCodeExporter]

Thanks Also,

I'd already done most of that, and probably a little bit more.... but merge 
issues have killed my ability to push. Also, I'm incredibly short on time at 
the moment.... but this work project is nearly finished :) I'm happy to change 
the owner. If possibly you can probably remove the clone and we just use the 
new one.

Cheers :)

Original comment by ahhug...@gmail.com on 21 Nov 2010 at 10:08

[GoogleCodeExporter]

Hi,
I tried to port some of the remaining samples today but then I realized that 
since the samples are under a different SCM repository, they will loose their 
history. I googled around a bit and found that mercurial can merge unrelated 
repos (http://mercurial.selenic.com/wiki/MergingUnrelatedRepositories). I also 
tried the solution described there and merged with conflicts (attached: hgtags, 
hgignore, build.xml). The only problem seems to be the .hgtags file, since 
both, samples and default repos have a '0.4' tag. In case we merge these repos 
we should remove one of the two tags.

On the other hand, If loosing the history is not a case please let me know.   

Also I attach the hg log (hglog.txt) after merging the two repos  in order for 
you to see the result. Since I barely know how to use mercurial any comment or 
suggestion is more than welcome.

Original comment by jgon...@gmail.com on 22 Nov 2010 at 10:05

Attachments:

• hgtags
• hgignore
• build.xml
• glog.txt