river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0
Date Mon, 31 Aug 2015 14:07:35 GMT
Although Peter has indicated approval, from a licensing point of view it 
might be best if he were the one to check it in.

On 8/31/2015 6:11 AM, Bryan Thompson wrote:
> Fine by me.  I am pretty sure Peter already indicated approval for this.  I
> was just offering to help remove a potential blocker for the release.
> +1 for publishing apple custard as a river artifact.
> Bryan
> ----
> Bryan Thompson
> Chief Scientist & Founder
> 4501 Tower Road
> Greensboro, NC 27410
> bryan@systap.com
> http://blazegraph.com
> http://blog.bigdata.com <http://bigdata.com>
> http://mapgraph.io
> Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
> graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
> APIs.  Blazegraph is now available with GPU acceleration using our disruptive
> technology to accelerate data-parallel graph analytics and graph query.
> CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
> for the sole use of the intended recipient(s) and are confidential or
> proprietary to SYSTAP. Any unauthorized review, use, disclosure,
> dissemination or copying of this email or its contents or attachments is
> prohibited. If you have received this communication in error, please notify
> the sender by reply email and permanently delete all copies of the email
> and its contents and attachments.
> On Mon, Aug 31, 2015 at 9:04 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
>> If Peter is OK with it, it’s simpler for the project if the code gets
>> integrated into River.  At some point I saw an
>> ‘org.apache.river.collections’ package, which I thought was the
>> custard-apple thing.
>> If there’s a strong need for the artifact to be published on its own, it
>> could also be done through River.  We’re perfectly free to publish more
>> than one artifact under the org.apache.river.* group id.  We would need to
>> create a subversion or git repository for it and then vote a release, the
>> same as any other release.
>> Cheers,
>> Greg Trasuk
>>> On Aug 31, 2015, at 3:37 AM, Peter <jini@zeus.net.au> wrote:
>>> I'd appreciate it Bryan,  use the version in the qa_suite, the version
>> on Sourceforge is older.
>> http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/dep-libs/rc-libs/
>>> Thanks,
>>> Peter.
>>> On 30/08/2015 9:54 PM, Bryan Thompson wrote:
>>>> Peter,  would you be open to having someone else publish the artifact to
>>>> maven? We are pretty deep in the process of publishing out a variety of
>>>> maven artifacts.  Brad  (cc) might be amenable to doing this to help
>> remove
>>>> possible blockers from a 3.0 river release.
>>>> Just fyi, we are in US eastern so the time zone difference is pretty
>> large.
>>>> Bryan
>>>> On Aug 30, 2015 6:47 AM, "Peter"<jini@zeus.net.au>  wrote:
>>>> My uploading custard-apple to Maven Central will be dependant on me
>>>> creating new PGP Keys in a Unix environment, which I also have to
>> install,
>>>> I do intend on getting this done in the near future, however I'm also
>> quite
>>>> busy, but given Rivers pace of devlopment, I'll probably get this done
>>>> before 3.0 is released.
>>>> I'm not against any options below, the project is free to choose.
>>>> Regards,
>>>> Peter.
>>>> On 13/08/2015 6:49 PM, Patricia Shanahan wrote:
>>>>> Good point. That seems to eliminate my option 1.
>>>>> On 8/13/2015 1:45 AM, Greg Trasuk wrote:
>>>>>> If we have a dependency on a library that’s not in Maven Central,
>>>>>> then using River in a Maven-based project (for example, the River
>>>>>> Examples project) will effectively be impossible (it can be done
>>>>>> is a royal nuisance for downstream users).
>>>>>> As such, I’d vote against any release that has a dependency on
>>>>>> library that’s not in Maven Central.
>>>>>> If Peter’s not able to put custard-apple into Maven Central, then
>>>>>> think we have no choice but to accept it as contributed code and
>>>>>> it into River.
>>>>>> A third option would be to accept it as a contributed code, but treat
>>>>>> it as a separate deliverable and publish it on its own into Maven
>>>>>> Central.  The only caveat is that we would have to rename the
>>>>>> packages to ‘org.apache.river….’, since we can only publish
under the
>>>>>> ‘org.apache’ and ‘net.jini’ group ids.  Peter (or anyone
here) could
>>>>>> maintain it under River’s aegis, and other users could still get
>>>>>> out of Maven Central.
>>>>>> Cheers,
>>>>>> Greg
>>>>>> On Aug 12, 2015, at 3:24 PM, Patricia Shanahan<pats@acm.org>
>>>>>>> wrote:
>>>>>>> Thanks, Peter.
>>>>>>> It appears to me that we have three options for dealing with
>>>>>>> "custard apple":
>>>>>>> 1. Do not include it in the release, but include a download link
>>>>>>> the installation instructions.
>>>>>>> Pro: easy for us. Con: more work for users.
>>>>>>> 2. Include a selected source subset that River currently needs.
>>>>>>> Pro: minimize source code volume. Con: more complicated maintenance
>>>>>>> - if Peter makes a change, we would need to check whether it
>>>>>>> involves the subset.
>>>>>>> 3. Include the whole library source.
>>>>>>> Pro: simpler maintenance - if Peter makes a change, we just copy
>>>>>>> the change. Con: Distributing source code that is not used by
>>>>>>> River.
>>>>>>> Any other options we should consider? Other pros or cons I have
>>>>>>> thought of? Opinions?
>>>>>>> On 8/12/2015 5:34 AM, Peter wrote:
>>>>>>>> It's AL2 licensed, the source is in a jar file in dep-libs,
>>>>>>>> consider it already contributed.
>>>>>>>> The library contains more code than you need, as it covers
>>>>>>>> type of Java Collections interface, up to Java 7 (it will
>>>>>>>> updated at some point to support Java 8&  9 collections
>>>>>>>> interfaces also).
>>>>>>>> The code itself is scalable, it has a single JVM thread that
>>>>>>>> performs garbage collection of references, api calling threads
>>>>>>>> don't perform this task.  The references themselves are often
>>>>>>>> created and destroyed without being shared among other threads,
>>>>>>>> large number never leave CPU cache and safe publication is
>>>>>>>> to avoid synchronization.  Overhead is low and its public
API is
>>>>>>>> compact.
>>>>>>>> For the most part use of soft references is advised against,
>>>>>>>> however there is a case for a cache that degrades gracefully
>>>>>>>> under load in the form of a Map where keys are timed and
>>>>>>>> softly reachable (or vice versa), to avoid extreme cases
where a
>>>>>>>> JVM is running out of memory, the jvm gc can clear entries
>>>>>>>> aren't strongly reachable (even though timed keys haven't
>>>>>>>> expired) at its descretion potentially avoiding or at least
>>>>>>>> delaying an OOME.  Timed references will prune infrequently
>>>>>>>> cache values, even though they're still strongly reachable.
>>>>>>>> Unlike other cache libraries, custard apple only implements
>>>>>>>> reference capabilities, allowing the user to wrap this over
>>>>>>>> preferred collection, such as ConcurrentHashMap,
>>>>>>>> ConcurrentSkipListMap, NonBlockingHashMap etc, it reduces
>>>>>>>> duplication and allows the user to benefit from new performance
>>>>>>>> improvements in popular collections.
>>>>>>>> Regards,
>>>>>>>> Peter.
>>>>>>>> On 12/08/2015 8:57 PM, Patricia Shanahan wrote:
>>>>>>>>> Does it have a license that lets us do that?
>>>>>>>>> (If you are the writer, and copy it in yourself, it would
>>>>>>>>> covered by your ICLA, just like any other code you contribute
>>>>>>>>> to Apache.)
>>>>>>>>> On 8/12/2015 12:00 AM, Peter wrote: ...
>>>>>>>>>> I'm a little busy right now to consider moving custard
>>>>>>>>>> If you wan't you can always copy only the code in
use into
>>>>>>>>>> org.apache.river.impl
>>>>>>>>> ...

View raw message