small fixes

[noamt]

Thanks for this. The JAX-RS plugin bundles special base REST-API integration spec classes, and these extend classes provided by the Spock plugin. So we either have to export the Spock plugin, or every user of the JAX-RS plugin will have to explicitly add a dependency on the Spock plugin. Is there a preferable solution?

[davidecavestro]

Just committed da334f1 into a new branch called downgrade_to_grails_2_0 in order to separate the grails version issue from the spock one. That commit would be a partial merge of this pull request, but I've tied it to the issue #34 that another guy filed in the meantime.

[davidecavestro]

Now I understand why Burt tied the two issues into a single pull request: the spock plugin dependency is strictly related to the groovy (and hence grails) version used by the application. If we depend on a certain version of it, we get a strict dependency on a certain version of groovy, and hence of grails.

Since this is not the first time we have problems with the spock plugin (see https://code.google.com/p/grails-jaxrs/issues/detail?id=74 ) I just wonder what other plugins in the same needs do!

If there are no other solutions than letting the application developers add the explicit dependency on the right version on the spock plugin, we could go temporarily for this solution, and propose to grails guys to introduce a way for plugin developers to declare a coarse/virtual dependency on another plugin (i.e. the spock one).

That should result in:

• automatically resolving that dependency using actual plugin dependencies coming from various sources (other plugins, BuildConfig, grails internal)
• optionally resolve the virtual dependency using a hypothetical new registry that let grails guys declare the compatibility with a certain version of some critical plugins
• if no resolutions are available, fail with a intelligible error message saying that the application developer should resolve the virtual dependency declaring an explicit dependency

Sorry for the long digression... Thoughts?

[noamt]

Perhaps we could pull our Spock specific classes out of the plugin and offer them as a third party jar?

[davidecavestro]

I'm sorry, I don't know enough about Spock and the relevant integration spec classes... I expect that extracting them into a separate library we would end up with a plugin companion library whose versions should reflect spock/groovy versions compatibility.

Taking a wild guess on which use cases we should support:

1. developers that don't use spock should simply use the jaxrs plugin with no other induced dependency
2. developers that want to write tests using spock should add a dependency to the additional jar and to the spock plugin

[noamt]

Correct. I'll take a look at it and see if it's feasable

[davidecavestro]

If needed, it could also become a companion plugin (dedicated to spock-related jaxrs tests)

[aruizca]

Hi @burtbeckwith

This pull request should fix issue they are talking about: https://github.com/krasserm/grails-jaxrs/pull/36

The problem was that they had test related code outside the test scope, so they change the test dependencies scope from test to compile to make it work, but breaking compatibility with any other Grails version that is not 2.2 due to changes in spock support in Groovy 2.

Cheer

[noamt]

I'm closing this as I've applied the fixes separately.