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.
