build failure with disabled `failOnError`

[IngeniariusSoftware]

code:

+package sandbox

[] > stress
  TRUE > a
  TRUE > a
  a > @

result compilation.log:

[yegor256]

@IngeniariusSoftware indeed a bug, thanks for reporting

[yegor256]

@Graur everywhere in our XSL files let's check <xsl:message> places. They are the potential sources of such problems. We should replace them with proper XSL checks, which add errors to <errors/> instead of crashing.

[Graur]

@MikhailLipanin Please, help us here

[MikhailLipanin]

The task is to add one more level of severity in XSL <errors>. Now we have 2 levels: error and warning. It is needed to Stop SHEET of XSL-s that applies to XMIR, when some Error is found, and print an error. @yegor256 , which name it should have and what errors/warnings it should handle? Or maybe we can make everywhere error severity to stop applying list of XSL-s, like it done here:

[yegor256]

@MikhailLipanin I would use critical name. If it's found, we stop the pipeline. If not, we continue (even if error-s are present).

[MikhailLipanin]

this one done, @yegor256 I think it can be closed

[yegor256]

@rultor release, tag is 0.28.11

[rultor]

@rultor release, tag is 0.28.11

@yegor256 OK, I will release it now. Please check the progress here

[rultor]

@rultor release, tag is 0.28.11

@yegor256 Done! FYI, the full log is here (took me 14min)

[yegor256]

@IngeniariusSoftware try version 0.28.11 please

[IngeniariusSoftware]

@yegor256, I tried, but got the same build failure result. Does it really have to be a critical error that stops the pipeline?

[INFO] ---------------------< org.eolang:c2eo-transpiler >---------------------
[INFO] Building c2eo-transpiler 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ c2eo-transpiler ---
[INFO] Deleting D:\Projects\EO\sandox\target
[INFO]
[INFO] --- eo-maven-plugin:0.28.11:register (default) @ c2eo-transpiler ---
[INFO] Registered 1 EO sources from .\:\Projects\EO\sandox\eo to .\:\Projects\EO\sandox\target\eo\foreign.csv, included [**.eo], excluded []
[INFO]
[INFO] --- eo-maven-plugin:0.28.11:assemble (default) @ c2eo-transpiler ---
[INFO] 0 attributes loaded from 35 stream(s) in 94ms, 47 saved, 409 ignored: []
[INFO] Parsed 1 .eo sources to XMIRs
[INFO] Adding optimization task for D:\Projects\EO\sandox\target\01-parse\c2eo\test.xmir
[INFO] Running 1 optimizations in parallel
[WARNING] XSL transformation 'not-empty-atoms' took too long 391ms (over 100ms)
[WARNING] XSL transformation 'not-empty-atoms' took too long 469ms (over 100ms)
[ERROR] net.sf.saxon.style.XSLText@7b93446b: Critical error identified: The name "a" is already in use;
[ERROR] #fatalError(): Processing terminated by xsl:message at line 32 in file:///; SystemID: file:///; Line#: 32; Column#: 17
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.937 s
[INFO] Finished at: 2022-11-10T20:20:36+03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eolang:eo-maven-plugin:0.28.11:assemble (default) on project c2eo-transpiler: Execution default of goal org.eolang:eo-maven-plugin:0.28.11:assemble failed: Failed to transform by net.sf.saxon.jaxp.TransformerImpl: [Processing terminated by xsl:message at line 32 in file:///; SystemID: file:///; Line#: 32; Column#: 17] (Processing terminated by xsl:message at line 32 in file:///; SystemID: file:///; Line#: 32; Column#: 17): java.lang.IllegalArgumentException: Failed to transform by net.sf.saxon.jaxp.TransformerImpl: [Processing terminated by xsl:message at line 32 in file:///; SystemID: file:///; Line#: 32; Column#: 17] (Processing terminated by xsl:message at line 32 in file:///; SystemID: file:///; Line#: 32; Column#: 17) -> [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/PluginExecutionException

[MikhailLipanin]

@IngeniariusSoftware Can you please explain more clear, what exactly is the problem? It is failing, since there are some XSL-checks in eo-maven-plugin.

And can you say, what result is expected instead of the current one?

[MikhailLipanin]

Now, critical error stops pipeline in eo-maven-plugin. "Stops Pipeline" means terminating execution of ParsingTrain.java --- List of XSL transformations.

It will not stop the outer build, but just throw an exception if there is a critical-error

[IngeniariusSoftware]

@MikhailLipanin The idea of the failOnError option is that even if some file contains an incorrect eo code, we simply print a warning with a message about the reason for skipping the file and continue compiling the remaining files. If we get a really critical error, then it seems logical to stop the pipeline and complete the compilation with the status build failure. If there are no critical errors, the build should end with the status build success. The question was, should the above error really have a critical level?

[MikhailLipanin]

I think, if we do this one, so all the time during the build, we will wait until it will be BUILD SUCCESS, and only after that we will allow to see an error in output XMIR. This is difference in approaches of build

• Now build fails if there is some errors and we can see them immediately
• You suggest each time do the full build even if there are errors, and only after the build itself, we can see them

@IngeniariusSoftware , but before this PR, new severity was added warnings, that doing exactly what you suggest (in their error-cases)

@yegor256 Should we do 2-nd approach in list above or stay like it is now (1st), WDYT?

[MikhailLipanin]

@IngeniariusSoftware or do you mean: if we have any type of errors (error, warning, critical) and failOnError flag is false, we should do the full build ?

(2 approaches that I wrote above are when failOnError = true)

[IngeniariusSoftware]

@IngeniariusSoftware or do you mean: if we have any type of errors (error, warning, critical) and failOnError flag is false, we should do the full build ?

(2 approaches that I wrote above are when failOnError = true)

Yes, that's exactly what I meant. Perhaps except for critical errors.

[mximp]

@IngeniariusSoftware @MikhailLipanin We cannot complete the build with such kind of error: duplicate names wouldn't allow to compile Java code correctly. So in this case the behaviour is correct: we fail the build no matter what failOnError is. We can allow to skip particular type of errors only. For others we must fail the build.

[IngeniariusSoftware]

@mximp It's about skipping the building of such files, does the duplication of names in this file somehow should affect the building of other files?

[mximp]

@IngeniariusSoftware The broken file may be accessed by other objects. This may lead to chained failure (during compilation). So in order to correctly skip the file you would have to identify all related files and related to related and so on, and skip them all as well, which likely would lead to overall failure.

[IngeniariusSoftware]

@mximp Yes, that's right in the worst case. Usually our files are not so strongly connected and an error in one does not affect the work of the others in any way. The purpose of failOnError=false is precisely this. Otherwise, based on your position, it loses all meaning.

[mximp]

@IngeniariusSoftware ok. Makes sense. Now we have to identify which errors are of critical severity and update it. Currently only one updated.

[MikhailLipanin]

@IngeniariusSoftware @mximp Now, how it works: If failOnError=false and there is a critical-error build will not fail, just Train in OptimizeMojo will be terminated. if failOnError=true and there is a critical-error, build will fail via IllegalArgumentException, (same as if there is a default error)

Is this a right approach?

[mximp]

@MikhailLipanin the build should always fail when critical-error is encountered, regardless of failOnError or failOnWarning. These two flags should affect only behaviour on error and warning correspondingly.

[MikhailLipanin]

I've done this before this PR... May be on critical we will just stop Pipeline execution in OptimizeMojo? @yegor256 @mximp @IngeniariusSoftware WDYT?

[0pdd]

@IngeniariusSoftware the puzzle #1475 is still not solved.

[0pdd]

@IngeniariusSoftware the only puzzle #1475 is solved here.