[jboss-as7-dev] Access to public API jars from (remote) client applications

[David M. Lloyd]

On 11/29/2011 10:19 AM, Jason T. Greene wrote:
> On 11/13/11 8:18 AM, Jaikiran Pai wrote:
>> I'm writing up the documentation for invoking remote EJBs from a
>> (really) remote application like standalone Java applications. One of
>> the things that we have to decide about is how we want the users to
>> access some of our public API jars (I'm not calling this "client" jars
>> since one of the previous discussions around this suggested that it
>> would confuse things). Right now we don't have a way where users can
>> *easily* add these public API jars to their classpath. Some of the
>> requirements that I can think of are:
>>
>> 1) These jars must be available at a well known location within the AS
>> distribution. i.e. the users shouldn't have to drill down into
>> individual module path to find the jars.
>
> My only problem with this is that it bloats our JAR size. Perhaps we
> should do a separate client dist, or perhaps an ant/mvn script to
> assemble the "client" jars.
>
>> 2) The jar names shouldn't contain the version names (since that will
>> require changes to client scripts if some API jar version changes)
>> 3) Modular environment on the client side is not a requirement. i.e. the
>> client application should just be able add these jars to their classpath
>> and use them
>
> Agreed
>
>> 4) IDE and build tool requirements should be taken into account
>> separately. i.e. a "bom" or some other IDE specific way of getting
>> access to these API jars _shouldn't_ be the only way of referencing
>> these jars.
>> 5) Identifying the public API jars
>
> I think this should be:
>
> ejb client
> iiop client (only has a handful of classes)
> controller client
> [and all of the deps from the above]
>
> What's not so clear is what to do with:
>
> infinispan
> hornetq
>
> I don't think these have a "pure client" dist.

Maybe it still makes sense to have an aggregated jboss-client.jar for 
the non-modular case?  We can shade in all the basic stuff, and we can 
even pull in partial JARs if there are certain ones which include both 
client and server code and it can be done easily.

The reason I mention it is because we're going to have quite a lot of 
transitive dependencies to deal with otherwise.

-- 
- DML