Building separate client jar

[Tatu Saloranta]

Quick question: when building a service, there is often desire to also
provide a client library or libraries to make access easier (even for
"REST" services... leaving aside philosophical question of whether
this is the Right Thing To Do).
This in turn suggest producing multiple jars (one for service, one
client). I have seen this done with various Maven set ups, like
sub-projects, but I am hoping there might be even simpler way to do
that.

So, does anyone have cookie cutter examples of how to produce both
no-deps server jar (which rules btw!), and a separate (no-deps or
with-deps, either way) client jar?

-+ Tatu +-

[Ryan Kennedy]

What we've started doing internally at Yammer is to create maven parent project in the top level directory. So {service name}-parent is the name. We then create modules of the project. {service name}-api contains API request/response objects (Jersey resource inputs and outputs). {service name}-service is the actual running service, which depends on {service name}-api. {service name|}-client is the client implementation, which also depends on {service name}-api.

You won't have to make separate JARs if you use shading. We use the maven shade plugin internally to build fat JARs of our services. I imagine you can trick maven into doing the same for the client library if you'd like, so the API and client libraries get bundled together. That way users of your client JAR don't have to pull down both dependencies. At Yammer, we don't worry about shading the client since the services that will use the client are shaded anyway.

Hope that helps.

-- 

Ryan Kennedy

[Tatu Saloranta]

On Sat, May 5, 2012 at 1:56 PM, Ryan Kennedy <rcke...@yahoo.com> wrote:
> What we've started doing internally at Yammer is to create maven parent
> project in the top level directory. So {service name}-parent is the name. We
> then create modules of the project. {service name}-api contains API
> request/response objects (Jersey resource inputs and outputs). {service
> name}-service is the actual running service, which depends on {service
> name}-api. {service name|}-client is the client implementation, which also
> depends on {service name}-api.

I was afraid that multi-project Maven might be the way to go... but in
this case it might be ok; scary cases are ones where there are a dozen
loosely related components. Here dependency is direct so it makes more
sense.

> You won't have to make separate JARs if you use shading. We use the maven
> shade plugin internally to build fat JARs of our services. I imagine you can
> trick maven into doing the same for the client library if you'd like, so the
> API and client libraries get bundled together. That way users of your client
> JAR don't have to pull down both dependencies. At Yammer, we don't worry
> about shading the client since the services that will use the client are
> shaded anyway.

Right, I would want just 2 jars; for service it's ok to have
everything (client is relatively is small part), but for client would
at least want to eliminate server-side only pieces.
Ideally it should shade in deps client has, to eliminate version
conflicts (even at expense if bit fatter jar).
But alternatively it'd be ok to include deps via client pom.

-+ Tatu +-

ps. Very excited to have completed first limping version of a new
clustered storage service, including functional client, running on
DropWizard (using AsyncHttpClient for http, so far works pretty
nicely) -- so much fun developing, and possibly serving as a sort of
sales speech for DropWizard as a new base for services.