Blue Thomas commented on Improvement MGWT-332

Thomas, I've added the configuration for build-helper-maven-plugin to add sibling mvn modules' source paths during build as I found in an example pom file (containing the comment "FIXME: workaround for MGWT-332" -> which is how I found this issue). I set my pom up with 2 mutually exclusive profiles:

1. 'notdev' which pulls sibling and other source modules as required during GWT compile via gwt-maven-plugin's "compileSourcesArtifact" configuration (which I quite like as I am not sending those sibling modules to external build servers [eg Heroku] so that build will need to find those dependencies from the repos I deploy them to anyway)

2. 'dev' which I use for local gwt:compile and gwt:run/gwt:run-codeserver

The issue I'm seeing with #2 is that upon an initial successful gwt:compile, I still need to blow away the 'target/{packaging}' directory (my GWT client module is a war packaging type) for any subsequent runs of gwt:compile to look back into the sibling source paths added by build-helper-maven-plugin for changes. Without blowing that directory away, the GWT module doesn't pick up changes to those sibling sources, even with -Pdev forcing the helper plugin to do its thing.

I would love this to work so I can use gwt:run-codeserver, make changes to sibling sources, and recompile the GWT module via the SuperDevMode bookmarklet. As of now, I have to clean the target dir between recompiles.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
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

Reply via email to