Skip to content

What to do regarding java development casks #57387

@vitorgalvao

Description

@vitorgalvao

Refs #57374 (comment). Ping @Homebrew/cask.

I feel like the multitude of Java/JVM/JDK casks is too much. Even which software to call java is a contentious subject that pops up once in a while. Those casks need non-trivial amounts of spaghetti code (i.e. non-standard-cask-code), there are a bunch of them, all have slightly different reasons for existing, and more than once we’ve had to rethink how they’re organised. We’ve tried to make sense of them yet again recently, but the person doing most of the work in that regard has since left.

Our options, as I see them:

  1. Continue adding these as they’re submitted, increasing the mess, eventually having to remove a bunch of them because nobody can make heads or tails of it anymore, or just leave them hanging and broken, as has happened in the past.
  2. Have someone (preferably a core maintainer, but not mandatory) commit to understanding all of these different softwares, why they exist, decide which should be included or not, and keep them in good shape. This person will be made a code owner to deal with all of these. To improve the lottery factor, this person should also keep a document that keeps track of all these different casks, why they exist, and why they need the extra code to be made functional (particularly useful in cases where they differ, if any).
  3. Keep the java cask and move everything else to yet another tap.
  4. Keep the java cask and delete everything else. If everyone else needs them, let them make their own tap.

My takes on these suggestions: 1 looks like a recipe for failure and burnout. Both 3 and 4 might restore order, but I’d prefer if that decision would be made by someone with the knowledge described in 2. 4 will piss off more people, and 3 won’t really ease our burden, just shift it. I’ll definitely not be the person to tackle 2. I dislike java and the stress java casks have given HBC repos in the past and that would make impartiality in my handling of it difficult. However, I would likely help that person tightening the documentation.

Naturally, any other solutions are welcome, or even opinions if you think this isn’t an issue. Right now, I feel this is a problem, even if an unconscious one. Casks with spaghetti code tend to be left longer without being fixed, java being no exception.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions