Hi Brian, Do you mind if I take your "PS" below and put it onto the River website? I'm trying to make the River documentation more comprehensive and I figure having little tid-bits of knowledge like that on the site will prevent others having to trawl (seemingly unrelated) mailing list threads to find them.
Thanks, Tom On Thu, Aug 26, 2010 at 5:27 PM, Brian Murphy <[email protected]>wrote: > On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <[email protected]> wrote: > > no one should need to depend on the *-dl.jar artefacts, > > > > > he API that clients and services depend on are in the platform.jar The > > *-dl.jar artefacts are free to change there is no coupling, > > > Peter, > > I'm not sure I understand what you mean above. Could you > explain what you mean regarding the *-dl.jar artifacts? > > For what it's worth, from a maven (hopefully someday public) > repository point of view, the product my company is currently > working on depends on the following river artifacts: > > browser.jar > classserver.jar > jsk-lib.jar > jsk-platform.jar > jsk-resources.jar > reggie.jar > start.jar > (and hopefully someday outrigger.jar and mahalo.jar) > > browser-dl.jar > jsk-dl.jar > reggie-dl.jar > sdm-dl.jar > (and hopefully someday outrigger-dl.jar and mahalo-dl.jar) > > Currently, we have placed the above artifacts in a > locally maintained maven repository that is updated > when new versions come out. We would like to someday > be able to pull these artifacts from a public repository > that would be automatically updated by the river > community. So, as you can see, we actually are > dependent on *-dl.jar files, and we're a bit concerned > by some of the discussion we've seen from time to > time regarding re-packaging the jar artifacts (although > since we're committed to river, I guess we'll just have > to adjust). > > Anyway, with the above in mind, I think you can see > why your comment about no one depending on *-dl.jar > artifacts is a bit confusing. > > Regards, > Brian > > PS For those who might be wondering about artifacts like > jini-core.jar, jini-ext.jar, sun-util.jar, etc., although there > have been previous postings discussing how they are no > longer needed, it might help some of the new folks on the > list to hear a repeat of the history of those artifacts; and why > they should not be used, and why they should probably be > removed from the build. > > Back in the old jini 2.x release time frame, there was quite > a bit of time and thought put into how the distribution should > be re-packaged to address deployment issues; for example, > better modularity, supporting overlays when upgrading, etc. > That work resulted in the current artifact structure we now see; > jsk-platform/jsk-lib/jsk-resources/jsk-dl/<service>/<service>-dl. > > But because the team did not want to break existing deployments > that relied on the old jar structure, they decided to also include the > old artifacts in the release; along with a detailed release note > explaining the new philosophy and encouraging folks to move to > the new model, and be prepared for the removal of those old jar > files down the road. Unfortunately, due to unforeseen events, the > removal of the old unnecessary jar files never occurred, and people > seem to still be using them (at least, based on postings on the > various user lists out there). > > With that in mind, one strategy regarding river and maven to > consider might be that, rather than maven-izing the whole build > process as the first step (which may be a huge undertaking), > one might consider first placing the artifacts the current build > process produces -- minus the unnecessary artifacts described > above -- into a public maven repository; which is something that > has been discussed in the past by Jeff Ramsdale and other > maven experts on this list. This would then make it quite clear > what jar files are necessary to use river. Additionally, although > doing this as a first step is aimed at the users of river as opposed > to river developers/contributors, it still may be a useful thing to > do with respect to ease-of-use/deployment; and it may actually > provide a bigger bang for the buck than one might expect. > > Anyway, it's just a thought. >
