Matthias Ngeo

Honestly, if/when I get around to adding multi-version support, it'll be by building against Paper.

I do think `@Case` is an appropriate name though since I do think it's similar in concept to that of case distinction. In my mind, we might want to test...

If I understand the example correctly, there's two distinct use-cases for `@Case`, * something similar to a `case` in Java's switch statements * labeling additional properties that can be accessed...

Hmmm, seems like `@Label` is a better candidate then, since looking at it, people may mistakenly assume that `@Snippet` spans multiple lines/elements. I don't think most of the name conflicts...

It's similar that they are matchers but I think that's where the similarity with `Hamcrest` ends. The idea is to be able to compose matchers for various elements in a...

Hmm I'll probably look into splitting it up once I have some spare time. Unfortunately it probably won't happen until at least November.

I feel like both cases can be generalised as “get elements annotated with a label”. I’m not too particularly fond of cases for parameterised tests as it isn’t obvious from...

I disagree since doing static code analysis in an annotation processor will almost always rely on the [Element](https://docs.oracle.com/javase/8/docs/api/javax/lang/model/element/Element.html)/TypeMirror API, which IMO is quite a common use-case. A `@CaseLabelSource` does sound...

I think there's a misunderstanding, I just meant that I specifically disagreed with renaming the annotation to `@Element`. I'm still on the fence regarding the others.

I think the main issue is that during the test we want access to both Java's `Element` and the `@Element` annotation. > Sometimes it would be enough to just have...