Access to public API jars from (remote) client applications

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Access to public API jars from (remote) client applications

Jaikiran Pai
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

Thoughts? Is this something that we could target for 7.1 Beta1?

-Jaikiran

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Access to public API jars from (remote) client applications

jtgreene
Administrator
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.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Access to public API jars from (remote) client applications

David Lloyd-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Access to public API jars from (remote) client applications

Radoslav Husar
In reply to this post by David Lloyd-2
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.
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev