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

[Radoslav Husar]

If anyone takes this on there is a Jira from UX workshop:

https://issues.jboss.org/browse/AS7-2362

It would be nice to have this outlined so that productization and others 
can get ready for it.

On 11/29/2011 05:29 PM, David M. Lloyd wrote:
> 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.
>