#15376 closed task (fixed)
CometD split out from DojoX
| Reported by: | dylan | Owned by: | dylan |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.8 |
| Component: | DojoX Cometd | Version: | 1.7.2 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
CometD 2.5 beta 1 will be released on Monday. As part of that effort, they have refactored their client to be AMD-based and work well with 1.7.
As such, we should remove the code that is in DojoX, and setup an svn:externals to their 2.5 GitHub? tree.
They will also be submitting their package to cpm/Dojo Foundation Package Manager.
I consider this to be blocking the 1.8 release, as dojox/cometd has been unnecessarily crufty for quite some time.
Change History (7)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Actually, digging deeper, they support both that for people using dojo.require, or package map configuration for AMD users.
So it looks like we need to test and then setup the svn:externals.
comment:3 Changed 10 years ago by
CometD has an updated module we could use, but they're struggling to understand how to make an unbuilt module available for the Dojo build system to use.
comment:4 Changed 10 years ago by
If you are going to remove dojox/cometd and add an svn:external (or even if you aren't adding the svn:external), please do it before we cut the beta, i.e. before Wednesday (June 13, 2012).
comment:6 Changed 10 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This is pretty much done, just need to keep working with the CometD team to get their GitHub? repo setup optimally for Dojo users.
http://bugs.cometd.org/browse/COMETD-336
Though they are using dojo.registerModulePath... that doesn't seem at all right for Dojo 1.7+. We need to do a review and offer some assistance.