Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

On 9 Jul 2008, at 14:44, Ryan J. McDonough wrote:

>
> 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.

Okay. I agree the separation of the client code solves the dependency  
and is a nice thing to do.

On 9 Jul 2008, at 14:46, Bill Burke wrote:
> tjws is required by the server.  It is our shipped "embedded" JAX-RS  
> server.


Yeah. I understand what tjws is, but is it your intention to always  
include the tjws-jar file for everyone linking to resteasy?

> 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?

I don't think I've got insight enough to have an opinion on how  
RESTEasy sits compared to the JAX-RS RI. I should leave the strategy  
to you guys. I agree that providing lots of interesting providers and  
other value adds is a good way of differentiating. Another would be to  
be robust, fast and lean. These objectives don't preclude each other.

I guess my main thought is to make it possible for the user to chose  
what functionality to use in RESTEasy. I.e. let the user decide  
whether they want those 3rd party jars (and the functionality that  
provides in RESTEasy) by declaring them <optional>. That way we can  
both ship the value-add at the same time as we don't clutter our  
user's project with jars they're not using.

M