river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Closing out release 2.2.0
Date Thu, 26 Aug 2010 23:25:35 GMT
Yes, thanks Dennis, that's what I was trying to say ;)

Seeing as we've touched on Maven again, is anyone with some Maven 
experience able to help out with an implementation of Maven Provisioning 
of proxy jar artifacts.  Seeing as everyone is starting to do this I'd 
like to see a standard way adopted.  The proxy jar's can themselves 
depend on other Jar's since maven can provision those.  By provisioning 
artefacts, it reduces the risk of denial of service.

Patrick proposed an Entry format for the download jar's.

N.B. We've got a draft up for review about archive names and API 
Evolution on JIRA River-341.

We also need a URL format and handler for Maven archives, I noticed that 
mvn:// isn't quite right since it doesn't include the version 
information or a checksum for integrity, perhaps someone can elaborate, 
I don't want the URL to be location dependant, rather it should be name, 
version and checksum dependant.  This makes CodeSources with identical 
jar archives, identical, rather than different, simply because they were 
downloaded from different servers.  It also could eliminate codebase 
annotation loss.  This change would improve reliability.

https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12465786

Thanks,

Peter.



Dennis Reedy wrote:
> 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