We download and install node locally. But you can test this by : > git fetch apache > git checkout -b build-test apache/master > mvn clean package -DskipTests
On October 2, 2017 at 11:17:03, Laurens Vets (laur...@daemon.be) wrote: I can confirm 0.4.1 (on CentOS 6!) builds for me as well. Are we sure it isn't due to the version of node shipped with the OS? On 2017-10-02 08:04, 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 >>