Dependensies in version 0.5.1 are broken

[Ambior]

Hi Tomas,

this version is depending on snapshots :-( . It seems that one of them has changed and this version isn't working anymore.

caused by: java.lang.NoSuchMethodError: org.fxmisc.flowless.VirtualFlow.createVertical(Ljavafx/collections/ObservableList;Ljava/util/function/BiFunction;)Lorg/fxmisc/flowless/VirtualFlow;
at org.fxmisc.richtext.skin.StyledTextAreaVisual.(StyledTextAreaVisual.java:140)
at org.fxmisc.richtext.StyledTextArea.lambda$createDefaultSkin$12(StyledTextArea.java:724)
at org.fxmisc.richtext.StyledTextArea$$Lambda$217/1339997891.apply(Unknown Source)
at org.fxmisc.wellbehaved.skin.Skins$1.(Skins.java:60)
at org.fxmisc.wellbehaved.skin.Skins.createSimpleSkin(Skins.java:59)
at org.fxmisc.richtext.StyledTextArea.createDefaultSkin(StyledTextArea.java:722)

Greetings,
Roel

[ghost]

Hi Roel, Tomas has been a major refactoring of flowlss. You probably want
to use the jars published instead direct integration until he publishes the
new code.
Best,
Maher
On Feb 5, 2015 12:16 AM, "Ambior" notifications@github.com wrote:

Hi Tomas,

this version is depending on snapshots :-( . It seems that one of them has
changed and this version isn't working anymore.

caused by: java.lang.NoSuchMethodError:
org.fxmisc.flowless.VirtualFlow.createVertical(Ljavafx/collections/ObservableList;Ljava/util/function/BiFunction;)Lorg/fxmisc/flowless/VirtualFlow;
at
org.fxmisc.richtext.skin.StyledTextAreaVisual.(StyledTextAreaVisual.java:140)
at
org.fxmisc.richtext.StyledTextArea.lambda$createDefaultSkin$12(StyledTextArea.java:724)
at org.fxmisc.richtext.StyledTextArea$$Lambda$217/1339997891.apply(Unknown
Source)
at org.fxmisc.wellbehaved.skin.Skins$1.(Skins.java:60)
at org.fxmisc.wellbehaved.skin.Skins.createSimpleSkin(Skins.java:59)
at
org.fxmisc.richtext.StyledTextArea.createDefaultSkin(StyledTextArea.java:722)

Greetings,
Roel

—
Reply to this email directly or view it on GitHub
#108.

[TomasMikula]

Hi Roel,

only 1.0.0-SNAPSHOT depends on other snapshots. 0.5.1 should be unaffected. Where does your 0.5.1 with dependencies on snapshots come from?

[Ambior]

Hi,

I'm using Maven,
in the pom file, some dependency versions are open end.
So is:

org.fxmisc.flowless
flowless
[0.3,)
compile

[TomasMikula]

Do you need any other snapshot releases from Sonatype snapshot repository? If not, you can just remove that repository from your maven file.

[TomasMikula]

You can now update to version 0.6.

[gschrader]

We just ran into something similar ourselves, we're on an old build (0.4.1) and since [1.3,) is used for reactfx it tires to pull in the latest version which seems to be failing on a 2.0 snapshot right now. I'm not sure why [1.3,) is used rather than a fixed version.

We worked around it by using this in our gradle file:

    configurations {
        all*.resolutionStrategy {
            force 'org.reactfx:reactfx:1.3'
        }
    }

[gschrader]

I'm now wondering if I also need to worry about the other dependencies: easybind, undofx and flowless also define their dependency using a version range. 😢

[gschrader]

Here's an interesting question on SO that deals with version ranges in gradle, the example is this very project. It seems to me version ranges are evil, any specific reason they are used here?

[TomasMikula]

Yes, dependency management causes headaches. I agree that dependency ranges without an upper bound are evil. If they are present here, they are not much more than an oversight, don't look for a good reason behind it. We should converge to something more disciplined over time.

I don't know of a good strategy for specifying dependencies. Fixed version might be too restrictive. If Foo depends on Bar 1.4 and Baz 2.5, and Bar 1.4 depends on Baz 2.2, how do you resolve Baz?

Projects don't always obey semantic versioning (and I haven't obeyed it in my projects either).

I wish for type-based dependency resolution. What I mean is that a package is going to depend on certain method signatures from another package, rather than on some opaque version number. There is ongoing research in this direction—for example, search this blog post for "Advancing semantic versioning"—but it is not going to happen anytime soon.

In the meantime, I will try to find some compromise with version ranges.

[gschrader]

It's no easy problem to solve for sure, especially on an ever evolving project. I learned something new as I wasn't aware that dependencies could be defined that way and was assuming that I was getting a reproducible build each time. Now that I know I'll just use force to specify specific versions that work together for now.

Thanks!