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.

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

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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev