More questions about modular-webapp archetype Maven actions

[Bryan Basham]

I am really enjoying the modular-webapp archetype that Thomas has put together.  I've been playing around with it in my public GitHub project ModularGwtSpringJpaApp; extending it to use Spring-based Services for the RPC components and JPA-enabled Entities in the GWT shared module.

I have two more questions about the Maven build process.

First of all, why doesn't mvn clean remove the target directories?  Isn't that the point of this Maven action?  Is there a way to modify the POM file to accomplish this or if not then please explain why.  I'm OK creating a simple BASH alias to do the cleanup but would rather use Maven if possible.

Second, is there a way to have Maven build the GWT Async classes at build-time rather than maintaining these files manually?  Remember, the generated source files also need to be bundled for the client module to use.

Thanks,

Bryan

[jieryn]

Greetings,

On Thu, Jun 12, 2014 at 1:04 PM, Bryan Basham <bash...@gmail.com> wrote:
> First of all, why doesn't mvn clean remove the target directories?

It does. You have a user error somewhere.

> Second, is there a way to have Maven build the GWT Async classes at
> build-time rather than maintaining these files manually?

http://mojo.codehaus.org/gwt-maven-plugin/generateAsync-mojo.html

I used to generateAsync as part of the build process, but I don't find
it useful anymore. It usually just causes problems for Eclipse because
we hadn't (at last time I checked) taught M2E how to handle these
automatically. Missing generated-sources directories, forcing you to
do Project>Clean on other modules, it's really a pain.

Nothing stops you from modifying your project once it is set up, but I
think the default simple mode of having the Async.java in the source
tree is the best for new people.

[Thomas Broyer]

The issue with generateAsync is that it generates methods with a 'void' return type, when Async methods can also return a Request (to be able to abort the in-flight request) or RequestBuilder (to be able to modify the request –e.g. add headers– before sending it).

I don't know about other IDEs, but Eclipse with the GPE can help you maintain the interfaces in sync, so in practice it shouldn't be a problem.

But we could also add some specific annotations somewhere (where?) to tell the gwt-maven-plugin how to generate the async interfaces.

[Jens]

But we could also add some specific annotations somewhere (where?) to tell the gwt-maven-plugin how to generate the async interfaces.

Wouldn't it be better to have an APT processor in GWT proper to generate the Async interface based on annotations in the synchronous interface? That way everyone can profit not just maven users and the gwt-maven-plugin would need a little bit less code to maintain.

-- J.

[Thomas Broyer]

On Sunday, June 15, 2014 4:13:13 PM UTC+2, Jens wrote:

But we could also add some specific annotations somewhere (where?) to tell the gwt-maven-plugin how to generate the async interfaces.

Wouldn't it be better to have an APT processor in GWT proper to generate the Async interface based on annotations in the synchronous interface? That way everyone can profit not just maven users and the gwt-maven-plugin would need a little bit less code to maintain.

+1

…but not everyone uses @RemoteServiceRelativePath ;-)

(I know it's technically possible to process types without annotations –RfValidator does this– but I'd prefer not relying on that kind of anti-patterns) 

[Jens]

Wouldn't it be better to have an APT processor in GWT proper to generate the Async interface based on annotations in the synchronous interface? That way everyone can profit not just maven users and the gwt-maven-plugin would need a little bit less code to maintain.

+1

…but not everyone uses @RemoteServiceRelativePath ;-)

(I know it's technically possible to process types without annotations –RfValidator does this– but I'd prefer not relying on that kind of anti-patterns) 

Sure, I would treat it as a new feature and possibly deprecate the current situation in the future. 

So its either a simple interface with required annotation @RemoteService having relative path as optional parameter or you do it the "old" way by extending RemoteService and maybe applying @RemoteServiceRelativePath.

In addition you would have @GenerationStrategy(VOID | REQUEST | REQUESTBUILDER) that can be applied to the interface or single methods in that interface. If its absent, void is used (annotate @RemoteService definition with @GenerationStrategy.VOID as default strategy).

-- J.

[Thomas Broyer]

Hey, that can easily be built as a third-party lib!

(require extending RemoteService for backwards compat', trigger on RemoteServiceRelativePath and/or a new RemoteService and/or GenerationStrategy; the "extends RemoteService" requirement might be removed in GWT proper later, and the annotation processor possibly integrated)

[Jens]

Hey, that can easily be built as a third-party lib!

Sounds like a plan!

-- J. 

[Ignacio Baca Moreno-Torres]

A annotation processor done here https://github.com/intendia-oss/autorpc-gwt.

The @GenerationStrategy has not been applied because; I think that that return void has no advantage VS returning Request. So returning Request always is self explanatory and do not requires user configuration. Returning RequestBuilder might be useful in some cases, but IMO are limited situation and you can always cast the async runtime type and set a custom RpcRequestBuilder using RemoteServiceProxy#setRpcRequestBuilder.

Initial implementation required to always apply @AutoRpcGwt annotation, I like this because is pretty explanatory, this kind of explicit configuration help to easily understand what is happening (I mean, that is clear that you want to auto-generate something). But, after some test and applying to various project I changed my mind because if the generator applies to @RemoteServiceRelativePath it can be used without any dependency and in my test project, it just works perfectly just removing all manually created async interfaces. Using this annotation is a good idea anyways, so if the user is not using it, he probably should. In some rare cases you may want to disable the generation, you can apply any annotation named @SkipRpcGwt. Or if the user really want to generate an async interface without using the @RemoteServiceRelativePath, it can use the @AutoRpcGwt annotation too. Both this annotation included in the artifact autorpc-gwt-annotations, but, as I "said", this dependency can be omitted in most cases, so only the processor dependency is required (which also has zero dependencies).