vavr-io / vavr-docs Goto Github PK

First we need to write Outline Draft. Discussed in vavr-io/vavr#280

There's something wrong with 67fb698. Look for
a818a75b55c800492902ae8d9946c30c88c3c62a here and there...

Check http://www.javaslang.io/javaslang-docs/#_lazy for example.

Vavr documentation should point out that property testing requires a different dependency than the core vavr module, namely vavr-test

see this question: https://stackoverflow.com/questions/48629111/vavr-property-testing

We need to include BitSet and PriorityQueue

Tried to update this myself but I cant push so
line 248 of usage_guide it should look something like

import static io.vavr.API.$;
import static io.vavr.API.Case;
import static io.vavr.API.Match;
import static io.vavr.Predicates.instanceOf;

A result = Try.of(this::bunchOfWork)
    .recover(x -> Match(x).of(
        Case($(instanceOf(Exception_1.class)), t -> somethingWithException(t)),
        Case($(instanceOf(Exception_2.class)), t -> somethingWithException(t)),
        Case($(instanceOf(Exception_n.class)), t -> somethingWithException(t))
    ))
    .getOrElse(other);

I added the imports since there are quite a few libaries out there with a static method instanceOf and it took a while to find the right one.

Here https://docs.vavr.io/#_lazy the documentation says:

Since version 2.0.0 you may also create a real lazy value (works only with interfaces):

To my understanding, v2.0.0 does not exist yet.

At the moment the multimaps are a hidden feature (no mention in the docs that I could find.)

Thank you very much for providing vavr by the way. 👍

see also https://stackoverflow.com/questions/48631727/stream-generator-method-in-vavr

• The docs version is synced with core Javaslang
• Unfinished releases will have an -alpha123 (early stage, will probably change) or -beta123 (partly finished, might change) suffix

Just above http://www.javaslang.io/javaslang-docs/#_gradle there is a getting started section that is not being formatted correctly.

don’t hesitate to send pull requests.
== Getting started

By encoding the original with gif or png instead of jpg. Target size is < 100kb

When trying to navigate to the documentation Firefox and Chromium both complain about wrong redirects. Firefox specifically talks about a redirect loop.

Depends on #1

Add the following property to the pom:

<maven.versions.version>2.1</maven.versions.version>

Add the following plugin to the plugins section:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>${maven.versions.version}</version>
</plugin>

@danieldietrich ask about github pages

Using github pages sounds good. How does it work? Can we trigger the build on travis-ci on a pull/commit and deploy to the github pages? Is the url then javaslang-docs.github.io? I will create a subdomain doc.javaslang.com or maybe javaslang.com/docs to refer to the github pages.

We need to discuss about github pages usage and is it suitable for javaslang documentation.

cc
@RobWin
@ruslansennov

Currently we have an issue with the version convergence of the asciidoctorj dependency and the transitive asciidoctorj dependency of the asciidoctorj-pdf plugin.

We should explicitly include the need dependencies in our pom and not rely on any transitive dependency. Especially we should directly include asciidoctorj. But we should not include any SNAPSHOT version of a 3rd party library.

We need a maven build mechanism, which fails the build if there are any conflicting transitive dependencies. This can be accomplished for example with the maven-enforcer-plugin (see also this). Here is an example:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>1.3.1</version>
  <executions>
    <execution>
      <id>enforce</id>
      <configuration>
        <rules>
          <DependencyConvergence/>
        </rules>
      </configuration>
      <goals>
        <goal>enforce</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Is there a better way to do it than with the maven-enforcer-plugin?

Note: We shouldn't shade any dependencies.

See comments in pom