Generate the module to generated sources by default instead of target

[foal]

Now the goal gwt:generate-module generate the module directly to target. It will be better to use ${project.build.directory}/generated-sources/resources by default. It will allows to another tools (e.g. Eclipse) correct work with generated module file

[foal]

Current workaround:

            <plugin>
                <groupId>net.ltgt.gwt.maven</groupId>
                <artifactId>gwt-maven-plugin</artifactId>
                <version>1.0-rc-3</version>
                <extensions>true</extensions>
                <configuration>
                    <moduleName>org.jresearch.logbackui.gwt.app.module</moduleName>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate-module</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/generated-sources/resources</outputDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

[tbroyer]

Interesting. Would you mind shedding some light on the specific issue with Eclipse? Is it somehow related to the GPE not picking the module when trying to launch DevMode from within Eclipse (as opposed to using the gwt:devmode or gwt:codeserver goals) ?

BTW, even inside a single plugin there doesn't appear to be a "standard way" as even inside a single plugin (https://maven.apache.org/plugins/maven-remote-resources-plugin/) they use both approaches. The difference I can see is that remote-resources:process can be told to not attach the resources to the project, meaning that you could configure that resource yourself to additionally filter them (or use resources:copy-resources to a similar effect).
And in our case we don't really want the generated file to be possibly processed/filtered by resources:resources.

Pending further information, I'd tend to say the issue is on the GPE side rather than this plugin.

[foal]

Yes, you are right about GPE - in case of your plugin it can't find the generated module.
Regarding the Maven Remote Resources Plugin - I never use it, but in out case is more suitable example (IMHO) some code generation plugins (e.g.JAXB: http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.2/). About filtering - I do not use it in current project, but easy can imagine situation that it will necessary. Not it is not possible. In case of using [${project.build.directory}/generated-sources/resources] as output folder it will possible - one more reason to change default :).

[branflake2267]

By default M2e (Maven Builder) in Eclipse will ignore including resources by default. Or resources directory get the exclusion = "**", and if changed they get clobbered. This is intentionally done assuming the maven builder should do the inclusion into the cp. Are you saying there is a way to around having resources included with a plugin? Just so happens I'm really annoyed by this today and looking at getting around this in the GPE fork. I've got a project that has classes that are generated but get excluded when added as a resource by default.

[foal]

I am sorry no way to around (Igor is to strong). In my projects based on the "classic" gwt-maven plugin I put all module configuration files to the java source folder. In this plugin I change the default and looks like the m2e does not apply the excludes to generated source folder.

[tbroyer]

When importing a Maven project, M2E apply exclusions to resource directories (e.g. src/main/resources), not source roots (i.e. src/main/java). Reasons are a) to avoid compiling *.java files and b) to avoid conflicting with Maven resource filtering and relocation; because Eclipse has no such concepts of "resource directories" or "resources processing".

@branflake2267 I think GPE should possibly just go look into the output folder (target/classes); that way it'll see the resources that'll end up in the classpath, and that'll include both those from src/main/resources and the module generated by gwt:generate-module.

@foal Judging from the code on GitHub, jaxb2:schemagen won't add the generated folder as a resource; it's left to the user (because that's not necessarily what he'd like to do; e.g. he might want to generate the XSDs and attach them as additional artifacts, or include them in the project's site, or just ship them through out-of-bands mechanisms: mail, upload to some web/ftp server, commit to some source repository, etc.); so it's not comparable.
As to "filtering" the module, if you need it, you'd probably want to do it before it's parsed as XML by gwt:generate-module.
All those things are relatively easy to configure but not path is hard-coded in the plugin: you can change the input file (after filtering by the maven-resources-plugin or another plugin, or even generation by a Maven plugin or, why not, an annotation processor) or change the output directory (to post-process it with the maven-resources-plugin or another plugin, or workaround the above-mentioned GPE limitation); even the name can be changed through the moduleName property (e.g. if you have your own module that would <inherit> the generated one; just configure a different moduleName for gwt:generate-module than the one used for other goals – that would reference your other module).
And last, but not least: you're not forced to use that feature of the plugin either! You can just continue to put your module in src/main/java or src/main/resources; just set skipModule to true to skip gwt:generate-module.

[foal]

I know the reason why the m2e exclude the resources and will be happy if GPE (@branflake2267) will check the target as well as the source folders. Nor only for the module descriptions but and for another GWT related resources.

@tbroyer I mean Java code generation by WSDL :) But may by you are right. Anyway your plugin allows to customize the [outputDirectory] and it is quite enough. And I like the dependencies generation and don't want to skip it :)

BTW. If you will change the mind, there few links to "generated sources/resources path conventions":
http://maven.40175.n5.nabble.com/generated-sources-resources-path-conventions-td109308.html
http://stackoverflow.com/questions/19325525/maven-generated-source-folder-document

[tbroyer]

Generated sources (as opposed to generated resources) are different: they must be added to the source roots if you want them compiled by the maven-compiler-plugin.

Generated resources on the other hand can either be generated into a folder that's attached as a resource directory and then copied to the build output directory by the maven-resources-plugin (if you disable attaching the folder –as can be done with remote-resources:process–, then you can manually add it and configure filtering and/or relocation), or you can directly generate into the build output directory (and provided it's configurable, users can change the output to a folder that they then process using the maven-resources-plugin or whatever).
Whether a plugin does one or the other would, I suppose, depend whether it's supposed to be used in specific types of projects (e.g. a gwt-lib or jar, where we know that the build output directory will be simply packaged), how the generated resources is supposed to be used (in our case, packaged within the gwt-lib or as input to gwt:compile; but we saw that jaxb2:schemagen is different), whether (and how) it wants to enable filtering (it could also do the filtering itself), etc.

[foal]

OK