Re: [Resteasy-developers] Providers and Future Bloat

[Ryan J. M. <ry...@da...>]

On Jul 9, 2008, at 5:49 AM, Martin Algesten wrote:

> I just ran into a snag here. I'm working on the pom.xml  
> straightening out the dependencies. When depending on resteasy-jaxrs  
> we currently pull in things like tjws and httclient. Basically I  
> want all dependencies that are not required to fulfil the spec to be  
> optional and not pulled in.

I this case, we've been talking about separating the client and common  
code from the resteasy-jaxrs code base. No doubt, client will have a  
dep on HTTPClient whereas resteasy-common and resteasy-jaxrs will not.  
I'd rather manage the dependencies that way than try and manage this  
in a single pom. I also don't want to get too carried away with this  
too. RESTEasy is still pretty small and we'd also like to the project  
to bring additional value over other JAX-RS implementations. I have  
some concerns with making every non-JAX-RS provider optional, even if  
it doesn't add any additional dependency to the developer. If we've  
got nothing to offer over the JAX-RS RI, why choose RESTEasy at all?

I think we need to be a bit more pragmatic as to what is include in  
the stock RESTEasy distribution vs. what will be optional. No doubt,  
separating out client from server will help resolve some of those  
issues. My thinking is that if we have providers that require heavy  
3rd-party dependencies, meaning you'd be pulling in more than 1  
additional JAR that wouldn't likely be available by the JDK or an  
appserver, then it should be optional. With this line of thinking, the  
Multipart provider would be ok since the dependencies are generally  
included with the app server. Things like a POI  or SVG provider would  
be optional since you'd now be looking at 2MB of dependencies. Thoughts?

Ryan-