river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Need for jsk-dl.jar
Date Tue, 04 Jan 2011 12:51:48 GMT

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.

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. There I've
said it, I'll not say it again and my personal bias against maven does not
influence my acceptance of the value of getting our packaging "right" (for
whatever definition of right we agree).

For my modularization to proceed, it is easy for me to create a module that
> contains the jsk-dl.jar contents, and have a jsk-lib module depend on the
> jsk-dl module. This is no problem.
> I am using Maven for modularization experiment. It looks okay so far, seems
> to fit well into the project (with a couple of classes being forced to
> reside in the platform due to dependencies.  The modularization separates
> the project in modules that each produce an artifact in the River distro. So
> river-platform module produces river-plaform.jar (was jsk-platform.jar), and
> (now) river-dl will produce river-dl.jar and river-lib produce
> river-lib.jar. The river-lib module will depend on river-dl, so when
> river-lib is resolved it naturuall will have river-dl.jar and
> river-platform.jar as part of it's classpath.
> I am doing it this way because I really want to move away from
> classdepandjar. Although classdepandjar has been a standard bearer in the
> Jini service construction realm for years, I think it has been one of the
> major confusion points for developers.
> Regards
> Dennis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message