wrong `--parser` version leads to a strange error message

[yegor256]

trafficstars

If I run eoc parse --parser=9.9.9, I get a weird error:

$ eoc parse --parser=9.9.9
[ERROR] No plugin found for prefix 'eo' in the current project and in the plugin groups [org.sonatype.plugins, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/yb/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [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/NoPluginFoundForPrefixException
The command "/opt/homebrew/lib/node_modules/eolang/mvnw/mvnw eo:register -Deo.version=9.9.9 -Deo.hash=130afdd1456a0cbafd52aee8d7bc612e1faac547 --quiet -Deo.sourcesDir=/Volumes/sec/code/tmp/eo -Deo.targetDir=/Volumes/sec/code/tmp/eo/.eoc -Deo.outputDir=/Volumes/sec/code/tmp/eo/.eoc/classes -Deo.generatedDir=/Volumes/sec/code/tmp/eo/.eoc/generated-sources -Deo.placed=/Volumes/sec/code/tmp/eo/.eoc/eo-placed.csv -Deo.placedFormat=csv --batch-mode --color=never --update-snapshots --fail-fast --strict-checksums" exited with #1 code

Let's try to report it a bit better.

[antonbashmakov]

it does not seem to be a javascript error, more like maven stuff. Seems like the plugin cant be found. Here is possible explanation.

[yegor256]

@antonbashmakov we should report a proper message to the user, something like: "There is no 9.9.9 version of the parser in Maven Central"

[antonbashmakov]

@yegor256 what we could do is to fetch versions from maven central and compare provided parser arg against the list of versions. We already do it in case of --latest. But there is a couple of thing that bugs me :

1. What if request to central has failed? Now it just throws.

2. What if I want to install new plugin version locally and run it? In this case there is discrepancy between versions list in the repo and locally. Should we bother?

[yegor256]

@antonbashmakov maybe we can run mvn eo:help --parser=9.9.9 --quiet before every command. If it fails -- we know that the version of --parser is wrong and can tell the user about this.

[antonbashmakov]

@yegor256 do not really like such approach, what if it is some thing else but version failing?

I suggest to implement the full check then:

1. check if there is version locally in MAVEN_HOME directory. If it is there - continue running the command.

2. if not - fetch versions list from the maven repo and check agains it.

If there is no such version in either of repos we can show a meaningful message.

[yegor256]

@antonbashmakov we will have to re-implement the entire logic of Maven dependency management, which is pretty complex. What else may fail in case of mvn eo:help? It's a pretty innocent operation, it only runs the plugin. If it works, we can configure, if not -- we stop and say that "for some reason we can't run parser 9.9.9"

[antonbashmakov]

@yegor256 it's probably a solution, but feels patchy, its like to validate a numeric format string using Integer constructor.

Implementing a check is not that much of work, we just use existing mechanism to fetch version from two different sources and do a simple check.

But there is another way, we could read from command output and react on phrases like No plugin found for prefix. If the operation is no success we could suggest that the problem is the version.

[yegor256]

@antonbashmakov what about proxies? What about custom location of Maven home?

Checking the presence of No plugin found for prefix in the log may lead to another problem: what if future versions of Maven will change the message? Also, this message is not the indicator of a wrong version, it's mostly a side effect of it. Some other problems may emit similar message, but we will believe that it's a problem with a version.

[antonbashmakov]

I tried to implement the help command and do not see point of doing so to be frank.

We run a command which we cant control exactly the same way we cant control any other command. It could fail by any other reason but the parser version, exactly the same way any other command will. And we will still guess the reason, so what is the point then?

I would put it like that, if we wont consider at least to try to check the version against repositories there is no point of doing it at all. It will be just an extra effort for a blind guess. We could rather add a warning in case of any error asking if the parser version is ok.

[yegor256]

@antonbashmakov what about proxies? What about custom location of Maven home? you will implement this functionality in the "checker"?

[antonbashmakov]

@yegor256 I can definitely try. The question if it is worth it.

BTW I cant see proxies to be taken care of when --latest flag is used either. Shall we take care of this part as well?

One more thing, I think we only need to warn the user about version mismatch not stop script from running.

[yegor256]

@antonbashmakov indeed, the implementation of --latest is not perfect. Would be better to use some Maven plugin for it instead, maybe this one: https://www.mojohaus.org/versions/versions-maven-plugin (created a bug for this: #257)

As for this feature, I still believe that we should avoid complex solutions and simply use eo:help, as suggested here

[antonbashmakov]

@yegor256 what exactly you want to archive calling eo:help?

[antonbashmakov]

@yegor256 my point is that you cant be sure if eo:help failed because of a wrong version. So we basically in the same situation as with any other command. Why bother to call yet another command then?

We could use version-maven-plugin for the check maybe (if it is possible)? Then we could utilise the maven version check mechanism and print out a warning if desired version is not in the list.

[yegor256]

@antonbashmakov eo:help will either succeed (we have the right version), or fail (we most probably have wrong version). Indeed, this approach has its disadvantages, but in my opinion they are smaller than in other approaches.

[antonbashmakov]

@yegor256 eo:help could have other reasons to fail. It will be about the same as just to print out a warning about the version in case of any error just in case.

Anyhow, this issue is far from critical, I see no real value in discussing it further, Ill add a preflight and assume that if it is failed it failed because of the version mismatch.

[antonbashmakov]

@yegor256 am I able to push a MR?

[yegor256]

@antonbashmakov please, use forks