On Jan 4, 2011, at 751AM, Dan Creswell wrote: > So.... > > On 4 January 2011 12:31, Dennis Reedy <[email protected]> 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.
