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 <j...@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"<j...@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 but >>>> is a royal nuisance for downstream users). >>>> >>>> As such, I’d vote against any release that has a dependency on a >>>> library that’s not in Maven Central. >>>> >>>> If Peter’s not able to put custard-apple into Maven Central, then I >>>> think we have no choice but to accept it as contributed code and roll >>>> 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 it >>>> out of Maven Central. >>>> >>>> Cheers, >>>> >>>> Greg >>>> >>>> >>>> On Aug 12, 2015, at 3:24 PM, Patricia Shanahan<p...@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 in >>>>> 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 in >>>>> the change. Con: Distributing source code that is not used by >>>>> River. >>>>> >>>>> Any other options we should consider? Other pros or cons I have not >>>>> 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 every >>>>>> type of Java Collections interface, up to Java 7 (it will be >>>>>> 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, a >>>>>> large number never leave CPU cache and safe publication is used >>>>>> 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 values >>>>>> softly reachable (or vice versa), to avoid extreme cases where a >>>>>> JVM is running out of memory, the jvm gc can clear entries that >>>>>> 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 used >>>>>> 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 their >>>>>> preferred collection, such as ConcurrentHashMap, >>>>>> ConcurrentSkipListMap, NonBlockingHashMap etc, it reduces code >>>>>> 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 be >>>>>>> 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 apple. >>>>>>>> If you wan't you can always copy only the code in use into >>>>>>>> org.apache.river.impl >>>>>>>> >>>>>>> ... >>>>>>> >>>>>>> >
