[
http://jira.codehaus.org/browse/MGWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177332#action_177332
]
nicolas de loof commented on MGWT-76:
-------------------------------------
* having multiple workspace is not a so common use case - this suggest the
projects you link in the compilation process are not all available in your IDE.
In such case I'm not sure you would like to see the compiler use sources you
are not working on yourself.
* I don't understand the notrion of beeing "connected".
* multiple versions detected will be filtered by the
group/artiftact/version/type check. maven-eclipse-plugin does the same check.
* for any module project that expect to be used as GWT library the "resources"
(.java and gwt.xml) must be defined as resources and will then be copied in
target/classes. Having a productivity hack in the plugin does not allow you to
NOT have a well buildable project with valid GWT modules.
* I really don't think the junior developper "knows" what he wants exactly.
maven-eclipse-plugin and m2eclipse allready resolve exisitng projects in
Eclispe workspace this way. I'm ok the full file scan could be consuming, but
have no better option fo now with beeing IDE-agnostic. I know a far better
solution but only working on Eclipse (the one I used on
sysdeo-tomcat-maven-plugin, copied from maven-eclipse-plugin)
* are you considering POM not to be in file "pom.xml" ??? does this even work
with any maven integration ?
Please remember that if any module is expected to be used from GWT we cannot
just point to it's source folders : it HAS to copy .java as resources to
target/classes, so we can use this path safelly.
> 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
> Attachments: 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
