Fix reflection warning

[valerauko]

Fixes #2695

• added type hint to the invokeStaticMethod call
• added *print-meta* true a'la Type-hint leiningen.run/run-form and print metadata in eval file #2306

Tests are passing.

[glts]

No, I don’t see how this is different from #2306. I just tried it and it breaks in the same way.

The last time this was attempted – and released – it caused a lot of damage (sorry). The next attempt needs to have more extensive testing. See #2328 and the mentioned issues there.

[valerauko]

It's not different. I thought it was unintentionally removed at some point. I expected there to be tests for any known regressions like that...

If you have a repro I could add to the lein test suite please advise. Currently I can only repro by running lein eastwood.

[valerauko]

I added a hacky fix using metadata to tag the form in question. Stuff without the magical meta tag won't have metadata printed (this is current behavior). I added a test case for this as well.

The last test failure seems to be a maven connection refused error... I can't rerun the tests on Circle to check if time resolves it

[glts]

I don’t remember what the problem was, aren’t all projects with plugins affected? Anyway, I cannot look into this further.

[frenchy64]

Perhaps we can always use *print-meta* true to generate forms, but first prepare the form by removing all non-:tag metadata (and coerce all tags to symbols or strings) via a postwalk. That might help avoid the problem of generating unreadable forms.

[frenchy64]

After some investigation, my idea isn't going to work because you can't remove metadata from vars and other such objects with mutable metadata.

I'll experiment with hybrid of these approaches (use a flag like in this PR to signal a very strict use of print-meta).

[frenchy64]

I'm not sure this is going to have the desired effect because most calls to shell-command wrap their arguments with extra forms. For example, see impl of eval-in-project and leiningen.trampoline's use of shell-command.

EDIT: Ah, now I understand that you've probably considered this case, that's why the filter is there right?

[frenchy64]

I have the feeling this approach is still too dangerous because there might be var literals in a project's :global-vars or :injections, and they contain unreadable Namespace objects in their metadata (assuming my understanding is correct that most calls to shell-command will come via eval-in-project).