It this project active anymore?

[wumpz]

I read in other issues, that a version V3 is on the way. Where is the sourcecode?

I saw that this pom.xml is already at 3.0-SNAPSHOT. So forget this question.

When is V3 released? Is there any work to be done? Java 8?

[jrtom]

Yes, it's active, it's just proceeding very slowly because (a) my day job + my family are eating my life and (b) there are some things I'm trying to resolve with common.graph (the Guava library that 3.0 uses in place of the previous graph types/implementations, which I am also responsible for) that will have downstream effects on JUNG.

If you're interested in contributing/moving this process along, there's a task list for this release here: https://github.com/jrtom/jung/projects/1; I can point you at parts that won't be affected by the common.graph changes.

[wumpz]

After forking and cloning I am unable to make a clean build. The spotless maven plugin produces some format violations. How can I fix this, should I fix this?

Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:1.14.0:check (default) on project jung-api: The following files had format violations:
    src\main\java\edu\uci\ics\jung\graph\BaseTree.java
        @@ -1,40 +1,40 @@
        -package edu.uci.ics.jung.graph;\n
        -\n
        -import java.util.Optional;\n
        -\n
        -/**\n
        - * Interface defining tree operations common to all tree types.\n
        - *\n
        - * @author Joshua O'Madadhain\n
        - * @param <N> the node type\n
        - */\n
        -interface BaseTree<N> {\n
        -  /**\n
        -   * Returns the root of this tree (the single node in this tree with no predecessor), or {@code\n
        -   * Optional#empty()} if the tree is empty.\n
        -   */\n
        -  public Optional<N> root();\n
        -\n
        -  /**\n
        -   * Returns the predecessor of {@code node} in this tree, or {@code Optional#empty()} if {@code\n
        -   * node} is this tree's root.\n
        -   *\n
        -   * @throws IllegalArgumentException if {@code node} is not an element of this tree.\n
        -   */\n
        -  public Optional<N> predecessor(N node);\n
        -\n
        -  /**\n
        -   * Returns the number of edges that one must traverse from the {@code root} of this tree in order\n
        -   * to reach {@code node}.\n
        -   *\n
        -   * @param node the node whose depth is being requested\n
        -   * @throws IllegalArgumentException if {@code node} is not an element of this tree.\n
        -   */\n
        -  public int depth(N node);\n
        -\n
        -  /**\n
        -   * Returns the maximum depth of all nodes in this tree. If the tree is empty, returns {@code\n
        -   * Optional#empty()}.\n
        -   */\n
        -  public Optional<Integer> height();\n
        -}\n
        +package edu.uci.ics.jung.graph;\r\n
        +\r\n
        +import java.util.Optional;\r\n
        +\r\n
        +/**\r\n
        + * Interface defining tree operations common to all tree types.\r\n
        + *\r\n
        + * @author Joshua O'Madadhain\r\n
    ... (32 more lines that didn't fit)
Violations also present in 25 other files.

[wumpz]

After commenting out this spotless thingy, I was able to build Jung locally.

If I am going to contribute, at first I need a clean clone.

Maybe you could somehow sort your projects issues by complexity, to provide some new contributors starter issues.

[wumpz]

The problem is the linefeed check . I use git at my system using autocrlf = input. My git system did not check against .gitattributes. Maybe one could soften the constraints.

[jrtom]

@wumpz When you get formatting errors, running mvn fmt:format (as indicated here: https://github.com/jrtom/jung/blob/master/CONTRIBUTING.md) should fix it; that's what it's for.

The intent is to minimize diffs prior to submitting a pull request, so that the changes will be clean and easy to understand.

Please LMK if that doesn't solve the problem.

(@jbduncan in case you have anything to add here)

[wumpz]

@jrtom That is absolutely understandable. I use a similar technique, not spotless but checkstyle. However there is no plugin fmt in your pom, at least maven does not find it. After applying spotless:apply nearly every source file was changed due to the linefeed changes I already found.

In some days I think a new jgit version arrives to consider your .gitattributes. May be then those problems go away.

[wumpz]

@jrtom I was successful by doing this clone command from my fork.

git clone -c core.autocrlf=true https://github.com/wumpz/jung.git

Now the corrected autocrlf setting is written into the local .git directory and processed fine.

[jbduncan]

Hi @wumpz, sorry to see that Spotless was proving troublesome for you (and sorry for the delayed response @jrtom!)

I've contributed to Spotless in the past, and I was the one who introduced it to this project, but it's not clear to me how this problem can be solved other than how you did it in your last comment @wumpz. So I'll see if I can post an issue on the Spotless issue tracker within the next few days so that the current maintainers are aware of it. :)

[wumpz]

@jbduncan a solution would be to force the linefeed to e.g. Unix style, wouldn't it?

Maybe the git workaround above could be written into Jungs contribution doc.

[jbduncan]

@wumpz I don't know that much about how Git works, so yep changing all line endings to Unix LF may be a good workaround for now. But I'll still submit an issue on the Spotless GitHub tracker so that the relevant maintainer(s) know to upgrade Spotless's version of JGit at some point, in the hope that that fixes things.

[jbduncan]

Oh wait, I've just found this issue that suggests the way to fix this is to use a certain setting to enable GIT_ATTRIBUTES recognition, but I understand that this setting is now the default, so it's likely that were just using an out-of-date version of the Spotless Maven plugin.

Thus I'll open a new issue here so that we don't forget to upgrade our version of Spotless at some point.