I might have spoken too soon. This is what I see now on 0.4.1-release:
...
[INFO] metron-contrib ..................................... SUCCESS [
0.006 s]
[INFO] metron-docker ...................................... SUCCESS [
3.088 s]
[INFO] metron-interface ................................... SUCCESS [
0.057 s]
[INFO] metron-config ...................................... FAILURE
[06:54 min]
[INFO] metron-alerts ...................................... SUCCESS
[03:44 min]
[INFO] metron-rest-client ................................. SUCCESS [
0.411 s]
[INFO] metron-rest ........................................ SUCCESS [
26.628 s]
[INFO] site-book .......................................... SUCCESS [
1.136 s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 06:56 min (Wall Clock)
[INFO] Finished at: 2017-10-02T16:33:39+00:00
[INFO] Final Memory: 240M/3203M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
com.github.eirslett:frontend-maven-plugin:1.3:npm (ng build) on project
metron-config: Failed to run task: 'npm run build' failed. (error code
1) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :metron-config
On 2017-10-02 08:16, Laurens Vets 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