[Resteasy-developers] Optional Libraries/distribution structure WAS Re: Providers and Future Bloat

[Bill B. <bb...@re...>]

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

Well, there's two different types of users.  One set just wants it as 
easy as possible to run things, the other wants a fine tuned 
distribution.  IMO, the majority of users just want things to run. 
That's why the zip just has a war file within it with everything so that 
they can just plop the WAR file into Tomcat or their application server. 
Since Resteasy is young, you want as few steps as possible to get things 
to run.  So, I'd like to keep a WAR that has everything within it 
(except probably the client-framework pieces and tjws/grizzly).

For the 2nd type of user, I think we can solve that with documentation. 
  Specify which jars are optional which aren't.

So, maybe the distribution should look like this?

/lib/
     /client/
            httpclient.jar
            resteasy-jaxrs-client.jar
     /server/
            resteasy-jaxrs.jar
            tjws.jar
            servlet-api.jar
            (anything required by core server engine)
     /providers/
               resteasy-providers.jar
               jettison.jar
               (...any libraries optional providers pull in)

Another thought here is to just distribute a maven repository of 
resteasy and its dependencies.


/resteasy-jaxrs.war/
                    WEB-INF/lib/
                               ...all from lib/server
                               ...all from lib/providers

Here we'd have duplicate libraries in distribution, but again, I want it 
very easy to start up.


/docs/
      javadocs/
      docbook/
              html/
              html_single/
              pdf/


Don't know if you've seen my previous email, but I wrote a tool to 
scrape JBoss Wiki to generate docbook.

/examples/
          example1/
                   build.xml (ant using /lib directories)
                   pom.xml (using repository.jboss.org)

We should have both ant and maven support.  Many (most?) developers 
still use ant.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com