river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Need for jsk-dl.jar
Date Tue, 04 Jan 2011 22:14:51 GMT
Perhaps in keeping the platform minimal, as it is and having clients 
load their libraries into a client class loader like services do, we 
minimise the possibility of class conflicts.

If jsk-lib.jar is not part of the installed platform and clients and 
services have their own private copy, it would allow a lot of 
flexibility for River developers.  jsk-lib.jar classes are free to 
evolve, since clients and service have their own version copy.  
jsk-dl.jar would always be downloaded, by proxy's.

As per one of Dennis' earlier suggestions, we should include the version 
in the jar archive name.

Only jsk-platform and jsk-policy jar files must remain strictly backward 
compatible.

Cheers,

Peter.

Dennis Reedy wrote:
> On Jan 4, 2011, at 751AM, Dan Creswell wrote:
>
>   
>> So....
>>
>> On 4 January 2011 12:31, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>>
>>     
>>> On Jan 4, 2011, at 358AM, Dan Creswell wrote:
>>>
>>>       
>>>> I don't know about forgotten but as far as I recall the separation isn't
>>>> entirely about supplying what is needed by clients or services. Looking
>>>>         
>>> at
>>>       
>>>> the release notes below I can see a couple of critical things:
>>>>
>>>> (1) The reference in respect of assuming these classes will always be
>>>> present.
>>>> (2) The statement about what is bundled - definition of "the platform".
>>>> (3) The statement that any other classes present are to be considered "an
>>>> implementation detail".
>>>>
>>>> The notes also cover jsk-lib.jar of course and discuss the fact that
>>>>         
>>> these
>>>       
>>>> are the common utility classes that services or clients may want to make
>>>>         
>>> use
>>>       
>>>> of. Should a service make use of these utility classes for it's own
>>>> server-side implementation only it would include jsk-lib.jar on classpath
>>>> but I doubt it would expose jsk-dl.jar to clients. If of course, it wants
>>>>         
>>> to
>>>       
>>>> make use of the utility classes in its proxy implementation, jsk-dl.jar
>>>> would appear as codebase.
>>>>
>>>> In essence, although we see general usage of jsk-lib.jar, it's not part
>>>>         
>>> of
>>>       
>>>> the platform or expected to always be present on classpaths.
>>>>         
>>> This is true. But in practice, in the usage of Jini over the past few
>>> years, has that expectation proven accurate?
>>>
>>>
>>>       
>> Completely understand where you're coming from equally I can say:
>>
>> So in the next few years can we expect this to continue to prove accurate?
>>
>> It's a bit of an un-winnable argument IMHO so I'm not going to bother. My
>> focus is that I think how things get bundled right now is ultimately tied to
>> the fact that we've entertained:
>>
>> (1) Platform versus non-platform
>> (2) Specs and standard APIs separate from non-standard stuff
>>
>> That brings tensions in that there are extra .jars and such lying around as
>> a result that can cause developer friction.
>>
>> With that being the case:
>>
>> I think ultimately, we should discuss what is platform and what is not. Then
>> we can discuss what we make .jars look like. Unless we propose to give up on
>> the definition of a platform, differences between specs and impl etc
>> entirely and shove everything in a single .jar. Or we could agree on some
>> middle ground.
>>
>> And I think before we do any of that we should be making sure we've got the
>> namespace thing sorted or maybe cover that off as well.
>>     
>
> As part of my effort, I took the liberty of renaming all com.sun.jini packages to org.apache.river.
The net.jini namespace remains intact.
>  
>   
>> Last up, I gotta declare something of a personal bias: I think maven sucks,
>> and it kind of offends me to bend our packaging to fit with it.
>>     
>
> We are not bending our packaging to fit with Maven, at least I dont see it that way.
The same care that goes into determining what arguments to pass into classdepandjar will go
into determining what module classes belong in. And I should further note, what I am doing
as an individual experiment may have nothing to do with what the River project team ends up
doing.
>
>
>
>   


Mime
View raw message