Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong --parser version leads to a strange error message #253

Open
yegor256 opened this issue Mar 6, 2024 · 18 comments
Open

wrong --parser version leads to a strange error message #253

yegor256 opened this issue Mar 6, 2024 · 18 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@yegor256
Copy link
Member

yegor256 commented Mar 6, 2024

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.

@yegor256 yegor256 changed the title wrong --parser version doesn't lead to runtime exception wrong --parser version leads to a strange error message Mar 6, 2024
@yegor256 yegor256 added bug Something isn't working help wanted Extra attention is needed labels Mar 6, 2024
@antonbashmakov
Copy link

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
Copy link
Member Author

@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
Copy link

@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
Copy link
Member Author

@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
Copy link

@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
Copy link
Member Author

yegor256 commented Mar 12, 2024

@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
Copy link

@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
Copy link
Member Author

@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
Copy link

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
Copy link
Member Author

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

@antonbashmakov
Copy link

@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
Copy link
Member Author

@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
Copy link

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

@antonbashmakov
Copy link

@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
Copy link
Member Author

@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
Copy link

@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
Copy link

@yegor256 am I able to push a MR?

@yegor256
Copy link
Member Author

yegor256 commented Apr 4, 2024

@antonbashmakov please, use forks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants