Hi Paul,
I think the only way to reflect a dependency contingent on API
utilization is to extract out the optional code into a separate asset,
with it's own dependency. So you could have the resource config classes
in a separate jar that specifies asm 3.1. Kind of a pain for just a
couple classes though.
I would think that a faq entry/documentation on usage with Spring should
take care of this. Sounds like the 3.1 maven availability issue was
just unfortunate timing.
--Joachim
Paul Sandoz wrote:
> Hi Joachim,
>
> The ASM developers have now pushed 3.1 to their repo (see attached
> email).
>
> The ASM dependency is required when using the following ResourceConfig
> implementations:
>
> - com.sun.ws.rest.api.core.ClasspathResourceConfig
> - com.sun.ws.rest.api.core.PackagesResourceConfig
>
> where the first is used by default if a ResourceConfig implementation
> is not specified. So you are OK not depending on ASM. I don't know how
> to reflect this type of dependency in the pom. I will update the
> dependencies documentation to reflect this.
>
> Farrukh has also posted some helpful information on the ASM
> incompatibilities with Spring and Hibernate, see this thread [2].
>
> I would like to put some sort of Spring (and Guice) utilities [1] as
> part of the Jersey distribution. Currently our Spring example is out
> of date and is not regularly tested... by providing something with the
> distribution we ensure things are up to date and that other developers
> don't have to keep writing the same thing. Not sure if I can get that
> done for the 0.6 release as we have quite a lot to get through...
>
> Paul.
>
> [1] http://wikis.sun.com/display/Jersey/IoC+utilities
> [2]
> https://jersey.dev.java.net/servlets/BrowseList?list=users&by=thread&from=987148
>
>