Well, that's a prescient and didn't seem to get any love. On Mon, Oct 2, 2017 at 11:53 AM, Otto Fowler <ottobackwa...@gmail.com> wrote:
> http://mail-archives.apache.org/mod_mbox/metron-dev/ > 201708.mbox/%3cCAGh_R=xvLB3tg_j3FhupyMz4iUsiXmNbagHKZ= > gtfdc8u4b...@mail.gmail.com%3e > > > On October 2, 2017 at 11:50:48, Otto Fowler (ottobackwa...@gmail.com) > wrote: > > 1. My failing builds are working again, both my branch off of master and > my pr checkouts, all that was required was a mvn clean package > 2. There was some discussion on yarn recently in a pr, though I can’t > remember which one > > > On October 2, 2017 at 11:45:48, Casey Stella (ceste...@gmail.com) wrote: > > Yeah, seems like it might be worth while to seriously investigate > migrating to yarn if that gets us a consistent build. > > On Mon, Oct 2, 2017 at 11:37 AM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > >> [WARNING] npm WARN deprecated bower@1.8.2: ...psst! Your project can >> stop working at any moment because its dependencies can change. Prevent >> this by migrating to Yarn: https://bower.io/blog/2017/how >> -to-migrate-away-from-bower/ >> >> >> On October 2, 2017 at 11:29:50, Casey Stella (ceste...@gmail.com) wrote: >> >> Ok, I can verify that 0.4.1 did build for me (took forever with vagrant >> running too). It's probably due to a dependency that was added after the >> release (whew!). Hmm, now that I've build master again, the problem seems >> to have gone away and the build is working again. >> >> On Mon, Oct 2, 2017 at 11:04 AM, zeo...@gmail.com <zeo...@gmail.com> >> wrote: >> >> > Hmm, 0.4.1 built fine for me. >> > >> > Jon >> > >> > On Mon, Oct 2, 2017 at 10:44 AM Casey Stella <ceste...@gmail.com> >> wrote: >> > >> > > Ok, the build is broken in metron-config due to some transitive >> changes >> > > that happened in npm-land: >> > > >> > > [INFO] >> > > >> > > /Users/cstella/Documents/workspace/metron/fork/incubator- >> metron/metron- >> > interface/metron-config/node_modules/toposort/index.js:32 >> > > [INFO] throw new Error('Cyclic dependency: '+JSON.stringify(node)) >> > > [INFO] ^ >> > > [INFO] Error: Cyclic dependency: "[object Object]" >> > > [INFO] at visit >> > > >> > > (/Users/cstella/Documents/workspace/metron/fork/incubator- >> metron/metron- >> > interface/metron-config/node_modules/toposort/index.js:32:13) >> > > [INFO] at visit >> > > >> > > (/Users/cstella/Documents/workspace/metron/fork/incubator- >> metron/metron- >> > interface/metron-config/node_modules/toposort/index.js:48:9) >> > > >> > > Evidently one of our transitive dependencies has changed and we have >> > ended >> > > up with a cyclic dependency. I'm not sure where or why yet, but I >> > believe >> > > this breaks both master and our 0.4.1 release (I haven't confirmed >> this >> > > yet, but I strongly suspect). >> > > >> > > While the good work of tracking down this specific error is done, I'd >> > like >> > > to bring up a broader discussion point: our practice of not fixing >> > versions >> > > for our node dependencies. This is, in effect, causing a few problems: >> > > >> > > - We do not have a consistent, repeatable build. >> > > - We set ourselves up for possible license violation without knowing >> > > about it (a transitive dependency changes its license) >> > > >> > > As we stand, we have a release which doesn't not build after we have >> > > released it and tested it. It seems to me that we should at a minimum >> > as a >> > > stopgap: >> > > >> > > - fix the versions of our dependencies so that they are in a working >> > > state >> > > - consider a point release to get a working build. >> > > >> > > I guess my questions to those of us with more javascript and UI >> > experience >> > > is as follows: >> > > >> > > - Does fixing the version of our dependencies actually fix the problem >> > > transitively? >> > > - IF not, then how do we get a version of a build which is consistent >> > > and repeatable and does not expose us to downstream licensing issues? >> > > >> > > Thanks, >> > > >> > > Casey >> > > >> > -- >> > >> > Jon >> > >> >> >
