James Xu created STORM-169:
------------------------------
Summary: Storm depends on outdated versions of hiccup and ring
Key: STORM-169
URL: https://issues.apache.org/jira/browse/STORM-169
Project: Apache Storm (Incubating)
Issue Type: Wish
Reporter: James Xu
Priority: Minor
https://github.com/nathanmarz/storm/issues/707
Storm core depends on a very old versions of
hiccup 0.3.6 => 1.0.4
ring-* 0.3.11 => 1.2.0
Especially the hiccup version conflicts with modern libraries like liberator
(see also weavejester/hiccup#86
IllegalStateException escape-html already refers to: #'hiccup.core/escape-html
in namespace: hiccup.page
----------
revans2: I agree that storm depends on old versions of libraries that I would
love to see updated, but simply updating the versions can cause a lot of pain
too. Having worked through this on Hadoop the only real solution is to get to
true dependency isolation. There are just too many libraries that are not
backwards and forwards compatible in very subtle ways, even for minor releases.
If you upgrade one dependency to fix a specific incompatibility it will break
someone else with a new incompatibility.
I am not saying that we should not do this. People should be willing to pay off
tech debt and upgrade, but until we can isolate a user's dependencies from
storm's dependencies we need to consider major dependency upgrades as
incompatible changes.
----------
jocrau: Yes, updating versions can cause a lot of pain. But deferring every
update to the time when the user's dependency is isolated might also cause a
lot of pain and slow down the adoption of Storm in some domains (like RESTful
services). I would love to see a more differentiated approach. Hiccup for
example is only used in the Storm UI; a place where I expect little impact.
----------
revans2: I totally agree. I just wanted to be sure that the storm version
number was bumped when we did this, so that we are indicating to downstream
users that something incompatible may have happened and they need to retest.
Now that storm is a multi-module project splitting out the UI and logviewer to
be their own jars with separate dependencies really seems like a good start for
isolation. More then that gets a little bit harry but is still doable.
If you think about it the worker only needs to pull in a few clojure APIs,
disruptor, curator, and jzmq or netty depending on how it is configured.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
