Understanding gwt.dependencies configuration

[Benjamin Wolff]

Hi,

it would be great if someone with more insight could help me understanding the gwt.dependencies configuration in the BuildConfig.groovy.

As the documentation states, dependencies declared in the gwt.dependencies are given to the hosted mode and the GWT compiler so that they can be resolved when needed. The following questions are not yet clear to me:

1) The dependencies need to be available as source for the GWT compiler, so the mechanism apparently resolves the source bundles automatically. Does it use the default Grails dependency mechanism for this (maven repos, local folders, cache)?

2) How does this GWT configuration block relate to the default Grails dependencies configuration block? If I want to use a library in Grails and GWT (ex. Google Guava), is it enough if I declare it in gwt.dependencies and in the default Grails dependencies, or does the gwt.dependencies put it implicitly in the project's scope?

3) As I understand it, it does only make sense to specify libs in gwt.dependencies that are fully compatible with GWT compilation. Otherwise the compilation would fail if a non-GWT-compatible class is used in client code. However, we have a case where we need to put a not fully compatible in the gwt.dependencies, otherwise the classes could not be resolved. In this concrete case it was the Google guava-gwt library, which also required to put the default Google guava library in the GWT dependencies scope to get rid of a ClassNotFound error.

I would really appreciate if someone could help us understand the GWT plugin dependency resolution a bit better, because GWT dependencies are a constant headache cause in our projects.

Thanks a lot!!

Cheers,
Ben

[Benjamin Wolff]

No one? :(

[David Dawson]

Hey Ben, so sorry I missed your email in my email chatter and a bit of a hectic week.

answers in line.

On 15 April 2013 10:15, Benjamin Wolff <welten...@gmail.com> wrote:

No one? :(

Am Dienstag, 9. April 2013 10:33:43 UTC+2 schrieb Benjamin Wolff:

Hi,

it would be great if someone with more insight could help me understanding the gwt.dependencies configuration in the BuildConfig.groovy.

As the documentation states, dependencies declared in the gwt.dependencies are given to the hosted mode and the GWT compiler so that they can be resolved when needed. The following questions are not yet clear to me:

1) The dependencies need to be available as source for the GWT compiler, so the mechanism apparently resolves the source bundles automatically. Does it use the default Grails dependency mechanism for this (maven repos, local folders, cache)?

Yes, it uses the default grails dependency mechanism, Ivy.  So you can add a new repo and have libraries resolved out of GWT for it.  It does this by adding libraries into the scopes before grails finished resolving the libraries. No modifications beyond this have been made to library resolution.   

So, it works for IDEs (STS and Intellij notably) that re-use the grails compile command for updating libraries.

 

2) How does this GWT configuration block relate to the default Grails dependencies configuration block? If I want to use a library in Grails and GWT (ex. Google Guava), is it enough if I declare it in gwt.dependencies and in the default Grails dependencies, or does the gwt.dependencies put it implicitly in the project's scope?

It is implicitly put into the project compile, test and runtime scopes.  This can be seen at https://github.com/dawsonsystems/grails-gwt/blob/master/scripts/_ClasspathHandling.groovy

 

3) As I understand it, it does only make sense to specify libs in gwt.dependencies that are fully compatible with GWT compilation. Otherwise the compilation would fail if a non-GWT-compatible class is used in client code. However, we have a case where we need to put a not fully compatible in the gwt.dependencies, otherwise the classes could not be resolved. In this concrete case it was the Google guava-gwt library, which also required to put the default Google guava library in the GWT dependencies scope to get rid of a ClassNotFound error.

There is no hard check to ensure that classes provided on the gwt build path are suitable for compilation to javascript.  This can only be discovered during compilation.   However, if the classes are simply referenced, but never actually used in the code, then the GWT compiler will notice this and trim them from the compiled javascript.

 

I would really appreciate if someone could help us understand the GWT plugin dependency resolution a bit better, because GWT dependencies are a constant headache cause in our projects.

What kind of issues are you having?

 

Thanks a lot!!

Cheers,
Ben

--
 
---
You received this message because you are subscribed to the Google Groups "grails-gwt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-gwt+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
David Dawson

Dawson Systems Ltd

Email    : da...@dawsonsystems.com
Mobile : 07866011256
Jabber : da...@dawsonsystems.com
Skype   : davidadawson
Twitter : @davidthecoder

http://davidadawson.wordpress.com

[Benjamin Wolff]

Hi David,

thanks for the clarification!

Just to make sure I understand you description and the ClasspathHandling script correctly, putting a lib in the gwt.dependencies block implicitly adds them to the Grails compile, runtime, and test scope. I don't need to specify them in these blocks again, they will be picked up automatically in the next Grails compile cycle. Only difference is that the libraries declared here are passed to the GWT compiler and hosted mode, as it is described in the plugin documentation.

Me mostly struggled with GWT dependency resolution problems and NoClassDefFound errors. We provide our GWT components via a separate plugin, which uses the Grails-GWT plugin, which in turn can't provide a GWT configuration block, since it is stripped out from the plugin and transformed into a lightweight dependencies.groovy file. So every application that uses the plugin needs to declare the full GWT configuration block again. However, thanks to the new gwt.dependencies and gwt.plugins settings the problems with GWT compilations were significantly reduced. It's just the challenge to keep the overview about all the many dependency configuration spots in the Grails application (Grails plugins/dependencies, GWT plugins/dependencies) ;)).

Cheers,

Ben

[David Dawson]

On 15 April 2013 10:42, Benjamin Wolff <welten...@gmail.com> wrote:

Hi David,

thanks for the clarification!

Just to make sure I understand you description and the ClasspathHandling script correctly, putting a lib in the gwt.dependencies block implicitly adds them to the Grails compile, runtime, and test scope. I don't need to specify them in these blocks again, they will be picked up automatically in the next Grails compile cycle. Only difference is that the libraries declared here are passed to the GWT compiler and hosted mode, as it is described in the plugin documentation.

yes, totally correct.

 

Me mostly struggled with GWT dependency resolution problems and NoClassDefFound errors. We provide our GWT components via a separate plugin, which uses the Grails-GWT plugin, which in turn can't provide a GWT configuration block, since it is stripped out from the plugin and transformed into a lightweight dependencies.groovy file. So every application that uses the plugin needs to declare the full GWT configuration block again. However, thanks to the new gwt.dependencies and gwt.plugins settings the problems with GWT compilations were significantly reduced. It's just the challenge to keep the overview about all the many dependency configuration spots in the Grails application (Grails plugins/dependencies, GWT plugins/dependencies) ;)).

Cheers,

Ben

Yes, this is an issue that hasn't been fully solved yet.  None of my projects use that particular style, so I don't get bitten by it often.

What could be done is to externalise the GWT configuration out from BuildConfig into some other file that would be maintained.  This would then have to be read in by the GWT scripting somewhere as well as or in place of the current build config references.

If you fancy having a go at making that change, I'd be pleased to assist.

David.