[
https://issues.apache.org/jira/browse/STORM-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Kellogg updated STORM-169:
-------------------------------
Component/s: storm-core
> Storm depends on outdated versions of hiccup and ring
> -----------------------------------------------------
>
> Key: STORM-169
> URL: https://issues.apache.org/jira/browse/STORM-169
> Project: Apache Storm
> Issue Type: Dependency upgrade
> Components: storm-core
> 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.3.4#6332)
