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

[Radoslaw Rodak]

Mabe inside of modules  an modul dependencies xml definition for remote client modul.
Then small tool/ant which grab this xml and generate jboss-client.jar 
So patching modules and updating this remote client xml and the regenerating jboss-client.jar could be consistent way... 

Am 29.11.2011 um 17:29 schrieb 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev