search

neo09 / gwt-platform

Automatically exported from code.google.com/p/gwt-platform
0 stars 0 forks source link

Mavenize the project #211

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
Update on this? I've made it high priority.

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

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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