I don't particularly have anything meaningful to add to this discussion, but I think it's worth remembering that anything that affects other people (particularly users) should probably be cross-posted to the users mailing list also.
Maybe when some kind of consensus is reached or when the options have been whittled down somewhat? Having said that, it's brilliant to see so much debate kicking off again! On Wed, Jan 5, 2011 at 8:42 AM, Dan Creswell <dan.cresw...@gmail.com> wrote: > On 4 January 2011 23:53, Dennis Reedy <dennis.re...@gmail.com> wrote: > >> First, thanks Dan and Gregg for reminding me :) >> >> > :) > > And thanks for providing some balance. > > >> 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. >> >> > Well, I'm no fan of classdepandjar but removing it is build hassle for me. > Hassle is no big deal so long as I have a clear path forward. What can you > do in terms of putting together an example or doc that shows how the > "typical" Jini service would be built from now on (not sure Blitz is typical > but there you go)? > > >> 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.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. >> >> >> >> >> >> >> >> >> > >> >> >
