Currently the code is being cross-built and published for 2.13.0-M3, but 2.13.0 has been released. Could that be updated?

Thanks in advance! :-)

Upgrade reactor-core to 3.1.8.RELEASE

It drills down to the usage of https://github.com/ADTRAN/gradle-scala-multiversion-plugin that seems to have this bug.

This library used to be uploaded to both Sonatype OSS and Bintray.
To upload to Bintray this project is using bintray gradle plugin, however after gradle 5.x, it seems the sign task is duplicated hence it keeps failing.

The code should be like

onErrorRecover { case t => blablabla(t)}

Flux and Mono has been replaced by SFlux and SMono respectively.

I think cats-effects is a bad and unnecessary dependency for this library. It should be removed.

For resource management one could use Flux.using() or scala.util.using().

The SFlux class does not have an apply method that takes a JFlux. This means that, with the removal of the deprecated Flux, there is no longer a way to convert a JFlux to an SFlux.

See reactor/reactor#690 for context.

This includes both PR checks and push checks on maintenance branches.
We'll also need to remove travis.yml file if travis was used, and do the following repo config changes:

• remove travis app integration
• remove .travis.yml
• remove CircleCI integration (.circleci/)
• change the "required checks" to include the new ci jobs

Flex.expand is supposed to emit "shallow" first

Hi! We (Couchbase) have been working on getting our SDKs passing the Black Duck OSS security assessment, and hit a stumbling block with your project.

Black Duck has flagged the com.google.code.findbugs:3.0.2 dependency as a 'High Risk'. It appears to be basing this mainly on it appearing to be unmaintained (it seems to have superseded by SpotBugs).

Now, I'm confused why it's picked up findbugs at all, since I can see you're declaring it with Gradle's implementation scope. I haven't got to the bottom of that, but I can tell you that Black Duck relies on "mvn dependency:tree" to analyze dependencies for Maven projects, and running this on our project does indeed show findbugs (in runtime Maven scope):

> couchbase-jvm-clients/scala-client$ mvn dependency:tree
...
[INFO] +- io.projectreactor:reactor-scala-extensions_2.12:jar:0.5.0:compile
[INFO] |  \- com.google.code.findbugs:jsr305:jar:3.0.2:runtime
...

and that it also appears in
https://repo1.maven.org/maven2/io/projectreactor/reactor-scala-extensions_2.13/0.5.0/reactor-scala-extensions_2.13-0.5.0.pom

This is for project https://github.com/couchbase/couchbase-jvm-clients, btw.

I'm opening this ticket so you're aware of this, and perhaps so we can explore solutions? It seems like perhaps findbugs could be upgraded to spotbugs, but really, I think the issue is that findbugs should not be appearing in the pom.xml at all?

Currently SFlux and SMono use the Java idiomatic way to express operators like scan, fold, reduce etc.
See this example for scan:

SFlux.just("item1", "item2")
  .scan**[String]**("prefix", (acc, value) => acc + value)

The Scala idiomatic equivalent would use a second parameter list:

Seq("item1", "item2")
  .scan("prefix")((acc, value) => acc + value)

Doing it this way one would gain closure notation like so:

Seq("item1", "item2")
  .scan("prefix"){(acc, value) =>
    println(s"$acc, $value")  
    acc + value}

This would especially be quite helpful when using multi-line closures.

For the scan operator (true for others too) I need to declare the generic type scan[String] in order to compile. This should also not be necessary.

The operator semantic also slightly diverges. Scala collections don't have reduce with initial value. Its called fold there.

All SFlux operators should be converted semantically and syntactically equal to them known from Scala collections.

For example RxScala did it that way.

Flux returned by Flux.name can't get the name retrieved by Scannable.name

Motivation

2 Motivations:

1. SBT is the native scala build for any scala project. It is more natural to build using SBT. It is also easier to do cross-compile build
2. Scaladoc 2.13 broke gradle scala plugin and with scaladoc, a library is unable to be published into maven central repository. (#27)(gradle/gradle#9855)

Desired solution

Considered alternatives

1. Wait for either Gradle or Lightbend to fix the broken scaladoc.

Additional context

val iterators: Iterable[SFlux[String]] = for (i <- 0 to 4000) yield SFlux.interval(5 seconds).map(_.toString)
val publishers: SFlux[SFlux[String]] = SFlux.just(iterators).flatMapIterable(identity)
SFlux.mergeSequentialPublisher(publishers)

It will produce compilation error

cmd25.sc:1: type mismatch; found : reactor.core.scala.publisher.SFlux[reactor.core.scala.publisher.SFlux[String]] required: org.reactivestreams.Publisher[org.reactivestreams.Publisher[?]] Note: reactor.core.scala.publisher.SFlux[String] <: org.reactivestreams.Publisher[?], but Java-defined trait Publisher is invariant in type T. You may wish to investigate a wildcard type such as _ <: org.reactivestreams.Publisher[?]. (SLS 3.2.10) Error occurred in an application involving default arguments. val res25 = SFlux.mergeSequentialPublisher(publishers) ^ Compilation Failed

This is more a confusion I have: I am using Webflux and I need to convert from reactor.core.publisher.Flux/Mono and the reactor.core.scala.publisher.Flux/Mono counterpart.
I couldn't find an "scala.publisher.Flux.asJava" or "reactor.core.scala.publisher.Flux.asScala" straight converter, similar to those found in JavaConverters or OptionConverters so I'd like to know if there is a way to perform such conversion using the current API.

In order to get SFlux's element types right for proper inheritance the element type should be declared covariant as it's usually done for container- or collection types in scala. See e.g. immutable.List:

sealed abstract class List[+A]

Currently SFlux's element type is declared invariant:

trait SFlux[T]

Which lets the following code fail for SFlux but not for List:

  trait Component

  trait Container{
    def component: Component

    def components: List[Component]

    def componentsFlux: SFlux[Component]
  }

  trait ComponentExt extends Component

  trait ContainerExt extends Container{
    def component: ComponentExt

    def components: List[ComponentExt]

    def componentsFlux: SFlux[ComponentExt]
  }

It would be nice to have some inconsistencies amongst fold, reduce and scan ops to be removed.

In Scala collections there are mainly three flavours of these operations, e.g.

• reduce
• reduceLeft
• reduceRight

Which makes - in my opinion - no sence for streams. There is only one direction from start to end. No need to bother with left or right.

Another category would be operations with initial value or not. In Scala reduce is without initial value. Fold and scan have an initial value. Fold and scan with initial value change the result type according to the initial values type.

The *With operations like scanWith and foldWith declare the initial value as computation by using the by-name argument passing.

I make a proposal via PR.

The idea is that application should be able to return Publisher[T] and still perform some filtering like

def someFunction(): Publisher[T] with Filter[T]

so that the caller can call like

someFunction.filter(T => Boolean)

Flux.just .map(_ => Flux.just(1,2,3)) .flatten

should be the same as
Flux.just(1, 2, 3).flatMap(_ => Flux.just(1, 2, 3))

Scala 2.11 usage is getting lower. Statistic from Maven central for May 2020 only shows +/- 5% download for 2.11 while it's getting more difficult to maintain cross build across 2.11, 2.12 and 2.13.
So this issue is to drop support for 2.11 starting v0.8.0

I see some inconsistency between between reactor.core.publisher.ParallelFlux and reactor.core.scala.publisher.ParallelFlux. Scala ParallelFlux is empty.
Do you have plans to add some methods to this class ?
Thanks

Unfortunately I could only find a 0.2.5-SNAPSHOT published in sonatype.org for Scala 2.12 but no stable version in Maven central.
Is there any reason for not publishing a Scala 2.12 based lib?

Thanks!
florin

Scala 2.13 is coming and ideally this project should support it. However the current build will fail when compiled with scala 2.11.12 and library that support 2.13.0-M3 because of compile error below

Static methods in interface require -target:jvm-1.8

See https://stackoverflow.com/questions/49213620/static-methods-in-interface-require-targetjvm-1-8

When SFlux is released, it missed Flux.merge operator.
It was available in scala.Flux
#30 (comment)

And Flux.mergeOrdered too

Reactor 3.2.0 (Californium) was released nearly 9 months ago. The 3.2.x series is more stable with a variety of improvements and bug fixes.

The outdated dependency conflicts with another library my project uses, so upgrading would be very appreciated. However, I'm not a Reactor power user, so my knowledge is pretty limited and I'm not sure how painful this upgrade would be.

Is there a reason for the delay? Let me know if there's anything I can do to help you upgrade to 3.2 :-)

Expected Behavior

test pass

Actual Behavior

test failed. See the following comment below

Steps to Reproduce

./gradlew clean build_2.12.10

Possible Solution

update mokito 3.2.0

Your Environment

• Reactor version(s) used: commit 9c2b022
• gradle version: 6.0.1 (see in file gradle/wrapper/gradle-wrapper.properties in the tree of commit 9c2b022)
• Other relevant libraries versions (eg. netty, ...): none
• JVM version (java -version):
  openjdk version "13.0.1" 2019-10-15
  OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.1+9)
  OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.1+9, mixed mode, sharing)
• OS and version (eg uname -a):
  19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64

The continuous integration uses Travis CI. However after upgrading to gradle 5.x, the CI keeps hanging. It doesn't happen when built locally.

A few options:

1. figuring out what happen with Travis CI process
2. migrate to other CI