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 Wed, 05 Jan 2011 01:49:34 GMT
https://issues.apache.org/jira/browse/RIVER-300

While ClassDep will remain a useful tool for investigating dependencies, 
I think the modular approach will lead to much faster builds and testing. 

I'd prefer if ClassDepAndJar was no longer part of the build process, as 
Dennis has pointed out, it's simplified greatly.

If the same directory structure can be used for Maven or Gradle, then 
this is a big positive also, since we're not dependant on one build tool.

Currently the issues the existing build system doesn't address:

   1. Long build and test runs means tests aren't run often enough by
      developers, when problems occur, it takes longer to track them
      down as your not sure which change caused the issue.
   2. Java platform compatibility is reduced to the most popular
      platforms, given our resources, this prevents other developers
      from expanding River's java platform support.

There are probably others I haven't thought of.

Cheers,

Peter.

Dennis Reedy wrote:
> First, thanks Dan and Gregg for reminding me :)
>
> I do think that this sort of thing needs to be documented. For example; if a distributed
system is developed & deployed using River n a 'typical' [1] enterprise setting, and the
developers/deployers of the system are aware that each of the clients in the distributed system
do include jsk-lib.jar in their classpath, then trimming the export codebase for services
can be done. This not only provides a performance advantage (one less jar to download), but
also provides a simpler configuration.
>
> All that being said, I am in total support of the needs & requirements for jsk-dl.jar.
Knowing how it may impact a deployment is a good thing though.
>
> BTW, on the modularization front, as I had mentioned earlier, I took some time and split
up the codebase into constituent modules. I have created a maven and a gradle based build
using the same structure. While I'm a complete newbie to gradle, it is amazing how concise
it is. I'll be glad to attach the example to the correct issue in Jira, can someone tell me
what that issue # is?
>
> Key to the modularization was to remove reliance on classdepandjar. I see this as a positive,
I'm not sure sure others do. IMO, it really simplifies the project to not rely on classdepandjar,
and have modules that produce a single jar. If you all feel very strongly about having classdepandjar
AND a modularized project, I still doable, it will just take more work to put classdepandjar
back into the mix.
>
> Considering that the total gradle configuration encompasses 95 lines (over 11 files)
for building and assembling reggie, outrigger, platform, jsk-dl, and jsk-lib, the ease of
use is fairly compelling. Adding classdepandjar will certainly add to the complexity.
>
> Regards
>
> Dennis
>
> 1. Granted that everyone's typical is not the same, in this case I'm referring to most
(if not all) of the Jini technology based systems that I have seen that do include the 'extended'
platform. The 'extended' platform includes jsk-lib.jar. Yes, this may limit evolvability going
forward, but the rate of change of core infrastructure components has always been slower than
iteration of application domain components.
>
>
> On Jan 4, 2011, at 514PM, Peter Firmstone wrote:
>
>   
>> 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