[
http://jira.codehaus.org/browse/MGWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182974#action_182974
]
Stefan Raubal commented on MGWT-76:
-----------------------------------
Hi Nicolas, hi Ladislav,
sorry for not commenting on your solutions and thanks a lot for all the effort
you spent in solving this issue!
During the last days I finally had the time to try the current version and
especially tried to reproduce the steps described in
[http://mojo.codehaus.org/gwt-maven-plugin/eclipse/google_plugin.html] in the
section "Multiproject setup".
(I used the following configuration: Eclipse 3.4.1, m2eclipse plugin 0.9.8,
Tomcat Sysdeo plugin 3.2.1, Maven 2.0.10 and GWT 1.6.4.)
All I had to do was enable Maven Dependency Managament for the modules in the
reactor example, adding "gwt:resources" to the list of goals executed after a
change and after a clean (and I also added the goal war:exploded).
I didn't need GEP nor any launch configurations, all I did was starting hosted
mode via a m2eclipse plugin run configuration (gwt:debug).
I also tried the Sysdeo Tomcat plugin and the noserver-mode for hosted mode -
this also worked fine.
Using the WTP server tool to run the web application didn't work out - I think
the way WTP and m2eclipse both want to provide the classpath collides - at
least I couldn't get this combination running.
But the Sysdeo plugin is sufficientfor us - it very effeciently reloads class
changes without requiring a context reload, so I didn't test any further.
But the one thing that annoys me is:
When I define a breakpoint in GWT client code, the source lookup path mechanism
opens the Java file taken from the classes folder - which is marked as
"Derived". This is dangerous because Eclipse gives me the chance to edit this
file - a change that will be lost after the next compile/clean.
:-(
I don't know whether this is an issue of the m2eclipse plugin or Eclipse or
hosted mode - maybe all of these players "do it right" but in combination the
result is bad. The Sysdeo Tomcat plugin shows me the correct source files when
debugging server side code (that's not surprising as its classpath is much more
"Eclipse"-like than "Mavenish".
I am interested in how you deal with this problem. Or do you all use GEP? We
don't want to change our file structure (some comments from above indicate that
the plugin does not work with the pre-1.6 structure).
Regards,
Stefan
> Solution for multi module builds and hosted mode
> ------------------------------------------------
>
> Key: MGWT-76
> URL: http://jira.codehaus.org/browse/MGWT-76
> Project: Maven 2.x GWT Plugin
> Issue Type: Improvement
> Affects Versions: 1.1, 2.0
> Reporter: Stefan Raubal
> Assignee: nicolas de loof
> Fix For: 2.0
>
> Attachments: dir_structure.txt, gwt-maven-plugin-MGWT-76.rev9744.patch
>
>
> The suggested improvement would ease rapid application development for multi
> module environments:
> The sources of referenced modules should be added to the hosted mode
> classpath instead of the JAR dependency (if the projects are referenced in a
> reactor build).
> The totsp plugin was preparing a solution for multi module builds that share
> the source folders directly. This sounded very promising and was discussed
> here:
> http://code.google.com/p/gwt-maven/issues/detail?id=149
> Nicolas stated correctly in a discussion that the manual configuration step
> used in the totsp patch has drawbacks and proposed a different solution:
> <quote>
> The use of some external XML file to setup "artifact" path as a project path
> is not very maven-compliant, as Maven likes all the config to be in POM. Such
> a feature could be nice but should be supported at maven-core level, not just
> inside a plugin.
> An better option COULD be to reuse code from maven-eclipse-plugin that scans
> the workspace for other maven project and automagically replaces artifacts
> reference with project references. This is a stronger approach : user don't
> have to configure it's path in some XML (that is user dependent, so it SHOULD
> not be stored in SVN and refered from POM) and the plugin code will check the
> candidate project matches the expected version to avoid missconfiguration.
> </quote>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
