tag for 3.0.16? about paguro HOT 6 CLOSED

Thanks for your interest!

Yes, that's the latest commit. You are of course welcome to build from source, but you shouldn't need to. 3.0.16 shows up in the Maven Repository, so not sure where the issue might be:
http://mvnrepository.com/artifact/org.organicdesign/Paguro/3.0.16
Maven is a little slow/weird about refreshing the local cache sometimes. If my IDE doesn't find the latest version, I either wait a bit, or build client code from the command line once and IntelliJ then fixes itself.

The "master" branch is always the most stable branch. Features go in new branches, though bug fixes often get made to Master.

If you use Paguro and do a lot of .filter().map().any() operations on the collections the way you would in Clojure, please let me know. I much prefer Paguro's Transformations to Java 8 Streams. Kotlin has transforms built in that are a little nicer even. I ask because I could interpret a lot of feedback as, "We just want the collections, don't give us anything else." Either that means they want to incorporate collections into other tool kits, or it means, "We hate your streams." So far, I can't tell.

Compiled Kotlin is nearly indistinguishable from Java. It's not like Scala where you end up calling (Whatsit) Thingy.$SOMETHING.another(). In my speed tests Kotlin is comparable to Java. I'm not expecting trouble from the conversion. I think it's the best way to maximize compatibility with both languages. If it gets too different, I'll branch off to a different branch or repository so that the Java folks can stay happy. I still write some Java and rely (heavily) on Paguro there. Since Paguro added mutable versions of the Immutable collections, I haven't instantiated any java.util.Collections and always use BaseList/ImList/MutableList instead of the java.util.List interface. Similarly for other collections.

from paguro.

Re: maven - yeah I can see the artifacts up there. The issue is just that we have a custom set of build tools at work where we have to build third-party libs from source. Typically I go to maven central to determine the latest release version, then go look for a corresponding tag in GitHub. In the absence of tags it's a matter of making sure I can identify the right commit by poking through the history.

This is where my questions about kotlin come into play as well. Since I have to build from source, if there is a compile-time kotlin dependency then I'll have to sort that out. I know that our build tools have some support for kotlin but I don't know how mature it is, if it supports mixed java/kotlin projects, etc.

These aren't concerns I'd expect to be high on your priority list :) Just trying to get a sense of your plans since it might effect my ability to upgrade the library over time, which might weigh into the decision on taking it as a dependency. Or, at least, prompt me to understand the state of our kotlin build tooling before choosing paguro.

One other note that might be of interest - our build system runs findbugs automatically. With (as far as I know) a pretty basic findbugs setup, there are 4 or 5 "high priority" warnings on the project, and a few dozen "medium priority" ones. Based on your unit test coverage i somewhat doubt that the things findbugs is calling out are critical bugs, so that won't prevent me from evaluating the lib or anything... But I thought you might be interested to know. The kind of stuff that findbugs picks up in general are spiritually similar to what you are doing with equality tests in your testutils lib, so you might find them interesting.

Lastly, re: transformation functions: personally I am interested in them and may play with them some for my own edification, but initially if I end up being able to use the lib for work, it'll be for the collections. Having spent some years in clojure, I am 100% sold on immutable persistent data structures. But what I'm finding is that while anyone who has worked in clojure for a while comes out feeling that way, almost anyone who hasn't just looks at you like you are bananas when you try to sell them on it in a 5-minute pitch :) Most of my teammates don't have much or any previous FP experience and are still leery of the java 8 lambdas and stream methods, but are willing to consider them since they are built in to the language. They get more skeptical when I start advocating for bringing in FP things from outside the core language. So, baby steps :) The data structures are definitely step 1.

from paguro.

"We have to build third-party libs from source"

I promoted the build instructions to the first page for you: https://github.com/GlenKPeterson/Paguro#build-from-source
If there's a typo, or you have clarifications or notes for another OS, please let me know and I'll make updates.

Typically I go to maven central to determine the latest release version, then go look for a corresponding tag in GitHub. In the absence of tags it's a matter of making sure I can identify the right commit by poking through the history.

I've been bumping along on the assumption that people would either use the latest version on Maven Central (Sonatype), or clone the master branch and build from that. Based on your feedback, I tagged the latest release here:
https://github.com/GlenKPeterson/Paguro/releases/tag/3.0.16
I've been pretty sporadic about tagging releases in the past, but if I know you're relying on that, I'll try to be better about it.

I typically use the latest available version of Kotlin. I've had a little trouble configuring Maven correctly, but they must be upgrading their instructions and the IntelliJ automatic-fix code because every time I do this for a new project it gets easier. I'm learning here too, but I have put a couple of hours into the current Maven configuration on the (unstable) Kotlin development branch: 2017-09-17_Kotlin. If I wasn't my own worst enemy, it probably would have worked on the first try.

I've tried to address your other Kotlin concerns by updating the announcement: https://github.com/GlenKPeterson/Paguro/blob/master/README.md#next-major-release-will-be-paguro-40-kotlin-compatibility

Findbugs

I'll have to try that. Thanks for letting me know. I'm opening issue #25 for that.

Most of my teammates don't have much or any previous FP experience and are still leery of the java 8 lambdas and stream methods, but are willing to consider them since they are built in to the language. They get more skeptical when I start advocating for bringing in FP things from outside the core language.

Yes, that is frustrating. I don't have a very good track record of convincing people, but the highlights of my best pitch are here:
https://github.com/GlenKPeterson/Paguro/wiki/Looping-vs.-Functional-Transformations

Brian Goetz and the people managing Java's direction are brilliant. No question about that. But Java is a big language and everyone has a different focus. Goetz book on Concurrency is brilliant. But he doesn't seem too impressed with functional programming and immutability. Java 8 got the big things right, but a lot of the details around functional programming are still really awkward. Perhaps this is most evident in the Java 8 Streams API. It's probably not actively hostile to immutability, but it does nothing to help you. I was pretty excited about the idea, but shocked when I saw the final implementation. Here are some thoughts:
https://github.com/GlenKPeterson/Paguro/wiki/Comparison-with-Streams-and-Lambdas-in-JDK8

from paguro.

I promoted the build instructions to the first page for you:

Thanks! Very kind of you.

I've been bumping along on the assumption that people would either use the latest version on Maven Central (Sonatype), or clone the master branch and build from that.

Totally reasonable assumptions, I imagine that you'll hit 95% of your target audience with that approach. Our build tools are way off of the beaten path, so I wouldn't expect any self-respecting GitHub oss library maintainer to be making accommodations for a setup like ours :)

Our chain doesn't use maven for dependency resolution OR for the actual build process. I have to Port to an ant-based setup. Luckily that is usually very easy for basic maven projects that follow the typical maven conventions.

Anyway, thanks a bunch for tagging, that's helpful!

And who knows, maybe I'll be able to turn this into an excuse to kick the tires of kotlin at work.

Thanks for the wiki FP links, looking forward to reading those one the bus this morning :) feel free to close this issue out!

from paguro.

If you haven't seen issue #25 yet, you should know that there's a 3.0.17 version, with a tag, ready for a git pull, with about half of your FindBugs issues fixed. Thank you very much! I'm closing this issue as you suggested.

from paguro.

I did see that, thanks! I'll update to that tag.

from paguro.