[
http://jira.codehaus.org/browse/MGWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=181613#action_181613
]
Ladislav Gazo commented on MGWT-76:
-----------------------------------
Well I investigated it thoroughly and I have couple of findings. In general I
agree that the problem can be solved within Eclipse IDE and now also think it
is cleaner and not hacky solution.
- having java sources in separate jar is not a design breaker for GWT library,
it is easily possible to include them on the classpath, it doesn't influence
this thing in any way. There is also a note about it here:
http://code.google.com/p/gwt-maven/wiki/M2FAQ
- the solution of multi-module change detection lies in correct Eclipse
launcher configuration - there must be a user entry directed to required module
sources where the change needs to be detected
- Google Eclipse Plugin (GEP) solves the thing, you don't need to do the step
manually
- GEP is forcing you to new GWT 1.6 structure what can be a problem for older
projects
- but there is possibility to generate standard Java application launcher
(using gwt-maven plugin) and add these entries manually - it works also for old
projects
- I hope the functionality to generate standard Java application launcher will
be preserved :)
- I'll write a guide about it so it is clear how to work with it
- GEP in conjunction with m2eclipse plugin (with which I had some problems)
automatic dependency resolution within Eclipse is really comfortable way
Thanks for hints and constructive discussion.
P.S. Personally I think the patch is now obsolete.
> 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
