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.re...@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.
