reverted the merge commits to plugman & js.
On Fri, Apr 25, 2014 at 9:43 AM, Michal Mocny <[email protected]> wrote: > Also Anis, would it please be possible to squash most of these commits into > a few units of standalone work? Probably best way to do that is create a > new local branch from your old branch point, apply the diffs from > browserify branch, rebase -i them, then push that branch (this way you > don't need to push with force). > > -Michal > > > On Fri, Apr 25, 2014 at 9:30 AM, Michal Mocny <[email protected]> wrote: > >> >> >> >> On Fri, Apr 25, 2014 at 12:53 AM, Michal Mocny <[email protected]>wrote: >> >>> TLDR; Ran a bunch of experiments tonight. I think this is too early to >>> merge into master. We pointed out several issues in previous threads and >>> seems they were ignored. >>> >>> Few quick comments from trying this: >>> - cordova-js is a new dependency of plugman, and needs to be npm linked >>> to local dev version >>> - Seems we run browserify after each plugin add (possibly due to an >>> auto-prepare?) so creating projects like mobilespec or any mobile chrome >>> app is now *much* slower (measured in minutes) >>> - Each cordova prepare now takes 6.5s on a very small project :'( >>> >> (reverted changes locally, old prepare takes <0.5s on same project, which >> is still slow!) >> >> >>> Things that are currently found broken: >>> - prepare step fails for my cordova testing application after >>> installing org.apache.cordova.contacts, and >>> - prepare step fails for *all* cca apps because of same error as above, >>> but for chrome.runtime plugin :( >>> - These issues seem due to js-modules not being browserify-ed properly. >>> It may be that both are bad modules (?), but it used to work fine! >>> >>> I did get a few apps running fine, so at least we got that going for us ;) >>> >>> Still to do: >>> - track impact tp startup time >>> - see if there aren't any plugins with subtle bugs due to auto-runs >>> behaviour >>> >>> -Michal >>> >>> >>> On Thu, Apr 24, 2014 at 9:34 PM, Andrew Grieve <[email protected]>wrote: >>> >>>> Cool! Does no impact mean that browserify is still not used by >>>> default, or does it mean that it's backward compatible? >>>> >>>> Failing specs sounds like impact... >>>> >>>> And it does look like medic is failing due to browserify-type things: >>>> http://108.170.217.131:8010/waterfall >>>> >>>> Unless you feel like powering through this tonight, I'll probably >>>> revert in the morning so that our continuous build can stay green. >>>> >>>> On Thu, Apr 24, 2014 at 6:06 PM, Brian LeRoux <[email protected]> wrote: >>>> > \o/ >>>> > >>>> > >>>> > On Thu, Apr 24, 2014 at 2:30 PM, Anis KADRI <[email protected]> wrote: >>>> > >>>> >> I just merged both browserify branches into master. There should be no >>>> >> impact. >>>> >> Right now most specs pass expect for File, FileTransfer, Media and >>>> Contacts >>>> >> due to some issues with merges/clobbers and I am looking into those. >>>> >> >>>> >> Also, I got rid of the project cache condition in plugman that was >>>> >> preventing iOS frameworks from being added (CB-6441) >>>> >> >>>> >> Anis >>>> >> >>>> >>> >>> >>
