What would you like help on? about gwt-maven-plugin HOT 24 CLOSED

Don't try to replace it, don't try to automate it.

Add you Async interfaces to your src/main/java and move on. If/when you change you sync interfaces, GWT compilation will fail, forcing you to update the async ones. And AFAIK, there are tolling in IDEs to help you keep interfaces in sync too (before you even try to compile your project).

Actually (and I said it numerous times over the years), if one interface could be generated from the other, it would be the reverse, inferring the sync methods' return type from the RequestCallback type parameter and ignoring the async method's return type, letting you use void, Request or RequestBuilder at your convenience. Of course, it couldn't tell if you'd prefer an Integer or an int, for example, as a return type; which is why I strongly believe this shouldn't be automated in any way. Assisted in the IDEs, but not automated.
And as I said above, if done anyway, this could (should?) be done with an annotation processor (processing the @RemoteServiceRelativePath? possibly adding another annotation for cases where you don't want to use @RemoteServiceRelativePath?) and, in any case, better left out of scope of this plugin.

from gwt-maven-plugin.

There are several things I'd like to add, none of them being a showstopper for a first 0.1 version. The first goals are gwt:compile (done) and gwt:test (I'm working on it), and the packagings.

• include metadata in the JAR giving the (main) GWT module being packaged (something akin to Main-Class in the JAR manifest); this means reworking the whole lifecycle, replacing jar:jar with a gwt:jar (and then maybe we no longer need the gwt:import-sources and gwt:import-test-sources if we move them to gwt:jar and gwt:test)
• based on the above, automatically generate the gwt.xml based on the Maven dependencies (see Ray's comments in https://gwt-review.googlesource.com/1243), for everything other than <inherits>, either configure everything in the POM as plugin configuration (using Maven's Xpp3), merge the <inherits> into an optionally provided gwt.xml file, or include an XML fragment stored in a file (this is what Google is doing apparently)
• one thing I'd love to have is proper support for DevMode/SuperDevMode in multi-module builds (of the kind of the e2e integration test). Ideally, it would also seamlessly support multiple GWT modules. See https://groups.google.com/d/msg/codehaus-mojo-gwt-maven-plugin-users/Y0dqogsT1Zw/92v5yXdqj7UJ, we should support both standalone apps (apps without servers, or using CORS) and traditional apps (with a server-side part just like the e2e integration test). This task probably requires a lot of brainstorming and design, starting with listing the pros and cons of each possible approach (after making a list of goals and non-goals); feel free to use the wiki for that if you want. See DevModeDesignDoc
• the gwt:generateAsync goal from the CodeHaus plugin is interesting, and would be great to have here too. Not sure I want to use QDox though for parsing Java. We have Eclipse JDT in GWT already so maybe use that (we should be able to borrow code from the GPE here I guess), or simply an annotation processor for the @RemoteServiceRelativePath annotation.

Feel free to use the wiki and/or open a specific issue if you want to work on any of the above. Pull-requests welcome, I use the same coding style as GWT.

from gwt-maven-plugin.

Wow, I'm impressed with how much you've done so far. My aim is to figure out how to slot time out for this project. I'll start the discovery process and see if I can helping.

• Automatic gwt.xml build, now that would be cool.
• It would be nice to use goals that integrate with Eclipse m2e Lifecycle, so m2e doesn't complain when using maven in Eclipse.

Are you deploying this as a snapshot to sonatype?

from gwt-maven-plugin.

Yes, using the BuildContext to integrate nicely in Eclipse is on the roadmap too; will depend whether the import-*-sources are still needed though (will be used by gwt:generateAsync –we need a better name, with rpc in it– though)

I'm not deploying to Sonatype OSS (too early-stage for that if you ask me); will try to set it up in Travis at some point though (seems like it's possible with a bit of hack: https://gist.github.com/neothemachine/4060735)

from gwt-maven-plugin.

Nice. No problem.

One thing that I find eclipse does with the other plugin is Exclude the resources by default, where I include ** by default so it adds the resources to the build path. I find it strange when the m2e excludes resource by default, but not sure if it's m2e or the GPE plugin setting the exclusion on resources, but as soon as the m2e updates it resets. But if the resources were included by default and generated resources included by default, then generation of resources like async wouldn't be as painful as they are now, at least for me. I've been steering clear of resource generation in general b/c I dislike configuring manual settings everytime maven config is updated. Anyway, I can see some time savers and looking forward to helping. :)

from gwt-maven-plugin.

See http://wiki.eclipse.org/M2E_FAQ#Why_resource_folders_in_Java_project_have_excluded.3D.22.2A.22 for the reason why M2E adds an excludes="**" to resource folders.
For the CodeHaus gwt-maven-plugin, I had reverted the BuildContext integration at gwt-maven-plugin/gwt-maven-plugin@6d7a276 because of other issues with the plugin (details here), this is now fixed at gwt-maven-plugin/gwt-maven-plugin@9e2e26b though so I should be able to reapply the change (or try it yourself so you can make sure it now works; you're a committer now!)

from gwt-maven-plugin.

Are you using 4 spaces in your source in this project?
What does e2e stand for?

Wow, committer. I see I've got read-write. I'll take great care. :)

Now that you mentioned the excludes I've noticed I've read that before. But when I tell pom resources to include all, it won't update/override the eclipse lifecycle configuration, exclude configuration with the pom resource includes configuration. I've recently tried different pom configurations, b/c I wanted to be able to make the archetype import a one step. I could be reading my configurations wrong. Or maybe I'm expecting that eclipse maven update will restructure the resource folders to packages so the main source can read it like source. At any rate, this is something I want to figure out at some point.

from gwt-maven-plugin.

I should be using 2-space indents everywhere (if I didn't, it was a mistake; I'll setup checkstyle).
e2e stands for end-to-end.

from gwt-maven-plugin.

Since your already integrated in this project and know the ins and outs. May I ask if you had a choice what specifically would you like me to help start on? My next goal is to figure out how to setup, debug and possibly run tests and wondering how to do that yet.

from gwt-maven-plugin.

The class I looked at with spacing: https://github.com/tbroyer/gwt-maven-plugin/blob/master/src/it/e2e/e2e-client/src/main/java/it/test/client/E2E.java

from gwt-maven-plugin.

Ah, yes, integration tests might not follow the coding style.

from gwt-maven-plugin.

Are you hard coding sample generation? > https://github.com/tbroyer/gwt-maven-plugin/blob/master/src/it/e2e/e2e-client/src/main/java/it/test/client/E2E.java

from gwt-maven-plugin.

Maybe I should have phrased it, generating the sample...

from gwt-maven-plugin.

Integration tests (not samples) are hand-coded.
Eventually the gwt-maven-archetypes (which look a bit like the e2e integration test) will use this plugin.

from gwt-maven-plugin.

I've found a nice way to test the Archetypes with TeamCity. In the Archetype project, I include tests. This way I can have teamcity import the archetype and then have it run the tests that exist in the project. I have the archetypes deploy on each monitor pull to the sonatype snapshot repo then I use a shell script to download, then I have teamcity run the tests inside the project created from snapshot. Anyway, once I get module variable in place to rename the module and files accordingly, I'll look at updating the archetype gwt maven plugin.

https://github.com/branflake2267/Archetypes/blob/master/archetypes/gwt-basic/test-archtype.sh

I can't seem to attach an image or I could show you the config. If your interested I could show you more...

from gwt-maven-plugin.

For archetypes, I use archetype:integration-test but, well, this discussion starts to really drift away from the net.ltgt.gwt.maven:gwt-maven-plugin topic.

from gwt-maven-plugin.

Good point. :) Back on track, did you have a specific item you'd like me to work on?

from gwt-maven-plugin.

Any word on auto-gen .gwt.xml files?
I would be very down to take a crack at this.

The necessary flow would be (I think) to
a) determine all the code accessed from a given entry point. (simple dependency visitor)
b) identify existing .gwt.xml files which include the required packages,
c) remove all types that can be included with existing modules
d) export a PackageNameAuto.gwt.xml in any packages missing code.

Given how easy it might be to leak something that touches a lot of other code, it might be wise to make it an interactive plugin by default, or at least have a preview operation of some kind. The exported files should like in target/, so they can be cleaned without touching client code...

The ugly part is when clients might have some classes in a shared package that have jre-only code. So, generating explicit includes="" statements might be wise (I do this for some codegen at work). In theory, we could do an integration test that runs a precompile using the autogen modules.

The main hard part here (at least for me), would be in coercing the existing JDT impl to choke down source without explicitly including all possible source. I think we'd have to do the dependency visit entirely outside of the TypeOracle / ResourceLoader phase, since I have tried to make it "auto-add missing source", with little to no avail. Standard JDT would be a much better option, imho.

from gwt-maven-plugin.

"proper support for DevMode/SuperDevMode in multi-module builds (of the kind of the e2e integration test). Ideally, it would also seamlessly support multiple GWT modules. " - I'm running a vert.x server with compiler that gets some multi-module support, though source maps default to name all evals 0.js, so, proper multi-module support would probably require naming the eval'd source something more deterministic (gwt strong name / hash might be wise).

I've also got a somewhat ugly but effective super dev mode gui in a maven plugin which scans the projects dependencies to create a compile classpath automatically (and scans for .gwt.xml that have an entry-point). It's currently "good enough for me", but would need quite a bit of polish before I would deem it 1.0. Currently you can edit the given classpath, but ideally I would like to save a config file somewhere for reuse / distribution.

It could be adapted to have multiple search strategies; look for gwt-maven-plugin and use that, if not, just scan all compile time artifacts... I also have a flag for running it on test dependencies, as 95% of my entry points are for testing anyway.

Is there any work done yet on a new dev mode mojo? The implementations I currently have are all dependent on my as-of-yet unreleased framework, but I would be happy to contribute a skeleton project or to develop a standalone mojo from scratch.

I'm pretty busy until I finish my move to DC on April 15th, but after that, count me in on making mojos!

from gwt-maven-plugin.

@JamesXNelson I want to keep things as simple as possible. My first and foremost goal with this plugin was to add specific packaging types to avoid boilerplate, and start from scratch so as to not inherit the crappiness of the legacy gwt-maven-plugin. I don't want to make too fancy things, because those things will have to be maintained. I primarily want to lay down best practices and make it easy to call GWT tools (compiler, primarily).

from gwt-maven-plugin.

Ya, I got that impression when I dug into the source and saw everything nice 'n concise.

I'll do my best to avoid poisoning the project with my natural verbosity ;-)

Given the progress you've made on generated .gwt.xml, I'll leave that alone for now.

What do you think about the dev plugins: cli or gui? Everyone hates writing java gui, but for the sake of end users, giving buttons and a proper branching logger would go a long way. I could look into adapting the existing jetty + gwt gui to add super dev mode support, or we could just aim for a simple cli server...

Either way, I do have some code to grab classpath from maven modules, and launch a recompiler-per-module. There are still some small issues surrounding a tab with more than one live gwt module (the naming of sourcemaps), but the process of launching a compile process with a maven classpath and routing logs back to the client is pretty much done. Exposing and routing all the options to forward to the compiler is not.

If there is anything existing to work against, let me know. Otherwise, I can clean out all external dependencies from the simple codeserver I'm using, and you can decide how much you want to reuse or rewrite to fit with the rest of the plugin.

from gwt-maven-plugin.

The remaining item (generateAsync) could be done with an annotation processor and would be better left outside the scope of this project. Closing.

from gwt-maven-plugin.

I am considering (and currently testing) migration from legacy plugin. However, I haven't find how to deal with the generateAsync.

Any suggestions?

from gwt-maven-plugin.

Thanks Thomas, that was very helpful and I agree, it is pointless to have this as a goal.

from gwt-maven-plugin.