Giter Site home page Giter Site logo

Comments (9)

foal avatar foal commented on May 24, 2024

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>

from gwt-maven-plugin.

tbroyer avatar tbroyer commented on May 24, 2024

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.

from gwt-maven-plugin.

foal avatar foal commented on May 24, 2024

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 :).

from gwt-maven-plugin.

branflake2267 avatar branflake2267 commented on May 24, 2024

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.

from gwt-maven-plugin.

foal avatar foal commented on May 24, 2024

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.

from gwt-maven-plugin.

tbroyer avatar tbroyer commented on May 24, 2024

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.

from gwt-maven-plugin.

foal avatar foal commented on May 24, 2024

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

from gwt-maven-plugin.

tbroyer avatar tbroyer commented on May 24, 2024

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.

from gwt-maven-plugin.

foal avatar foal commented on May 24, 2024

OK

from gwt-maven-plugin.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.