The joy when tools do not have machine parseable output.

I'm looking at you SBT. My favorite pile of poo.

Remove the logging level from each line, then trim the line, then stab around inside the line with regexes, fishing for a possible match which hopefully is right...

Then stripping scala information like the object type, cause yeah...
A line can be for example "[info] Vector(File(...),File(...))" where info is the log level, Vector the wrapping sequence type, File(...) the wrapping element type and the string inside File(...) what yours truly needs.

As this is lot of shitty shabby string stabby stabby, we need to add a fuckton of boiler plate validation cause who knows what we just murdered.

To make it even more fucked up, a multi project project can produce different output for the same key.


Yeah. So we need to fix that too.

By the way, one can set log output to unbuffered in SBT.

Then the output is in random order :-)

Isn't that fun? Come on, you wanna poke that pile of shit, too.

The SBT plugin way is by the way no alternative, as I need a full Java environment for execution.

Which brings me to the last point:

For fucks sake, writing CLI applications in Java is so much bloody boilerplate code.

There's ugly and then there's the "please kill me" kind of level.

50 lines just to write a basic validation of argc / argv with commons cli.

That's 6 lines in python. Not kidding. :(

I currently hate everything.

Moments where the job sucks: When you have to hotwire two electric cables with high currency by giving both cables the blowjob of your life.

  • 3
    I didn’t understand half of it but I enjoyed the read!

    Btw, _everything_ in Java is a lot of boilerplate code. Not just CLI stuff.
  • 0
    regex fun. it's time for the big rewrite it seems. refactor all systems and sunsistems to match and be simple for parsing data and the problem is gone ;)
  • 2
    Short explanation: SBT is the build tool for Scala and Java files.

    I needed to get the class path and the sources out of SBT to use it for static analysis.

    There are two not so fun things about SBT:
    - everything is scala, even the build definition itself
    - you can only extend SBT by writing plugins, which is cumbersome... For the reason that SBT itself is ... Torture. Plus you have to rollout the plugin in *every* project when you go down that route...

    What I did instead was misusing the very fucked up SBT task output.

    Thus, start SBT with commands, get the output, parse the output.

    The output is a mixture of Scala code representation (think Pythons repr or PHP var_export) or plain strings representing a value.

    Thus the analogy of given two electric power lines the blowjob of their live... It's really just praying to get the right shit extracted and not loosing information.

    I really have no way of validating that poopoo, except writing tests with dummy output captured by SBT and checking if it matches.

Add Comment