At the moment we have two main concerns about jaxrs implementation choice:
in order to build their grails project, plugin users must have both jaxrs implementations (namely jersey and restlet) available from configured dependencies repositories at compile time. At the moment restlet artifacts are not available on default configured maven repos (see issue #16 ).
plugin users always gets both jaxrs implementations artifacts included in the generated war (unless they tweak their build in order to exclude the unneeded stuff). And this could lead to some issues.
Both of them are caused by the fact that the plugin includes some jaxrs implementation specific sources.
In case that's not a viable solution, I feel we have two alternatives:
splitting the plugin into a core plus two implementation specific plugins (jersey and restlet). This way we would remove the root cause, simply avoiding plugin users to compile unneeded implementation specific code
extract implementation specific code into pre-compiled separate libraries and then find a way to simply exclude unneeded jaxrs implementation jars from the generated war
IMHO the former solution is cleaner, but it would introduce some additional complexity in plugin management (i.e. 3 github projects instead of the actual one, issue tracking and so on).
At the moment we have two main concerns about jaxrs implementation choice:
Both of them are caused by the fact that the plugin includes some jaxrs implementation specific sources.
In order to mitigate the first one we could see if restlet artifacts become available on maven central (see https://github.com/restlet/restlet-framework-java/issues/481). For the second one I've opened a dedicated thread to see if there's a way to control optional deps at application build time.
In case that's not a viable solution, I feel we have two alternatives:
IMHO the former solution is cleaner, but it would introduce some additional complexity in plugin management (i.e. 3 github projects instead of the actual one, issue tracking and so on).