Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependensies in version 0.5.1 are broken #108

Closed
Ambior opened this issue Feb 5, 2015 · 10 comments
Closed

Dependensies in version 0.5.1 are broken #108

Ambior opened this issue Feb 5, 2015 · 10 comments

Comments

@Ambior
Copy link

Ambior commented Feb 5, 2015

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
Copy link

ghost commented Feb 5, 2015

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
Copy link
Member

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 Ambior changed the title Depencys in version 0.5.1 are broken Dependensies in version 0.5.1 are broken Feb 6, 2015
@Ambior
Copy link
Author

Ambior commented Feb 6, 2015

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
Copy link
Member

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

@TomasMikula
Copy link
Member

You can now update to version 0.6.

@gschrader
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants