river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Need for jsk-dl.jar
Date Tue, 04 Jan 2011 13:15:33 GMT

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