[
http://jira.codehaus.org/browse/MGWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177351#action_177351
]
nicolas de loof commented on MGWT-76:
-------------------------------------
I've another option to avoid full scan : use */pom.xml as expression (instead
of **/pom.xml) and when a POM is detected having modules, add them to the
to-be-processed list (some ~recursivity)
I'd like to support a simple solution for better productivity, but don't plan
to create a silver bullet that should anyway be handled by maven core itself,
not it's plugins. User projets should be present in the same workspace / share
a common root directory.
If this workspace mix trunk / branches, the versions will not be the same so
the check will choose the correct one (or do you use same version in a branch ?
it's a bad practice !)
You seem not to understand that even we can use some hack, any dependency used
by GWT compiler MUST in the jar have the associated .java files, so your other
modules MUST include the required <resource> settings to copy .java files to
target/classes (see the reactor sample in src/it).
Seniors developpers will use advanced setup and custom home made plugins ;p
using a non standard POM file name is possible, but not following maven
conventions you can understand it will require manual tweaks. Cnahging the
scanner pattern could be a solution.
I understand the use case : mutliple modules, no need to package a full reactor
build to see a java source change in the final gwt module.
I'll add documentation on this feature with the requirement so that you can
better understand my point of view
> 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
