[
https://issues.apache.org/jira/browse/WAVE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157502#comment-13157502
]
Yuri Zelikov commented on WAVE-306:
-----------------------------------
EditToolbar uses HistorySupport to find out the current waveId. Can it be that
the waveid can be found in some other way, without using HistorySupport?
> Bad dependency from org.waveprotocol.wave to org.waveprotocol.box
> -----------------------------------------------------------------
>
> Key: WAVE-306
> URL: https://issues.apache.org/jira/browse/WAVE-306
> Project: Wave
> Issue Type: Bug
> Components: Web Client
> Reporter: Christian Ohler
> Assignee: Yuri Zelikov
>
> Hi Yuri,
> your change http://svn.apache.org/viewvc?view=revision&revision=1187363
> introduced a reverse dependency that breaks walkaround. I believe
> org.waveprotocol.wave is not supposed to depend on org.waveprotocol.box - the
> dependency is supposed to go the other way only.
> Specifically, http://codereview.waveprotocol.org/616002/diff/2003/1033 made
> EditToolbar depend on HistorySupport. This breaks walkaround because it
> makes it impossible to pull in undercurrent without also pulling in a GWT
> entry point that tries to initialize socket.io. Since walkaround doesn't use
> socket.io, this initialization fails. (I studied this a while ago but didn't
> get around to reporting a bug back then, I hope my recollection is not too
> far off.)
> Walkaround's get-third-party-deps script works around this by specifically
> downloading revision 1187362 of Apache Wave, but that's not a good long-term
> solution.
> Maybe HistorySupport.waveRefFromHistoryToken should be moved to
> GwtWaverefEncoder? Or do you see a better way?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
