metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: [DISCUSS] Build broken due to transitive dependencies
Date Mon, 02 Oct 2017 15:26:10 GMT
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 (laurens@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, Zeolla@GMail.com wrote:
> Hmm, 0.4.1 built fine for me.
>
> Jon
>
> On Mon, Oct 2, 2017 at 10:44 AM Casey Stella <cestella@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
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message