river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Closing out release 2.2.0
Date Thu, 26 Aug 2010 16:48:20 GMT
Hi Brian,

I think Peter is referring to an earlier discussion that surrounded adding specific <dependency>
declarations in your pom for -dl.jar artifacts. The discussion centered on breaking out a
Jini service's constituent architectural elements, where a service creates an API (interfaces
and any classes required to communicate with the service), a DL that contains any proxy classes
and other details the service's proxy requires, and of the course the impl. Any client will
only need to declare a dependency on the API, never the DL. 

From a Maven point of view you're absolutely correct, you'll need to push these artifacts
up. 

Regards

Dennis

On Aug 26, 2010, at 1227PM, Brian Murphy wrote:

> On Thu, Aug 26, 2010 at 8:31 AM, Peter Firmstone <jini@zeus.net.au> 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.


Mime
View raw message