[enhancement] Confusing to have jakarta/javax `@Valid`, avaje-http `@Valid`, avaje-validator `@Valid`

[mechite]

They do different things, but I can consider this to potentially confuse people.

I feel like maybe the one in validator should change?
I also feel something else.

---

Could we possibly make an @Valid.Records for the module-info whereby all
record classes automagically get a ValidationAdapter, even if it is never used?

Really, there are a lot of ways I am thinking about how to make this less obtuse.

---

What's the point of the validator, if no validation constraints are used in a given @Valid record?

Maybe instead, any given class with any @Constraint-annotated annotations declared,
could somehow have adapters generated?

I don't know how it would work from the processor context.
Maybe there you would just apply a module-wide @Valid or a new, clearer @ValidatorModule
annotation that can walk the module-info exports just as avaje/avaje-record-builder#88

[rbygrave]

Could we possibly make ...

A note to make sure we state as clearly as possible what the problem / issue being faced is ... and we do that before we look a solutions.

[mechite]

Right. I apologize if I have been cryptic

We have here, a record using avaje-validator's Valid:

import io.avaje.validation.constraints.Valid; // or jakarta.validation.Valid, etc
import io.avaje.validation.constraints.NotBlank;

@Valid
record User(@NotBlank String name, int age) {}

We have here, a controller that uses avaje-http's Valid:

import io.avaje.http.api.Valid;

@Controller @Valid
final class UserController {...}

These, put together in tandem, work together to give us bean validation.
It can be a big pain-point that they are named the same thing.

In fact, I just realized looking at my own application, I have >20 DTO new/untested records
which import io.avaje.http.api.Valid incorrectly.

---

My proposed solution, the best one in my opinion, of what I said above:
Introduce @ValidatorModule for the module-info, and walks the exports like avaje/avaje-record-builder#88.
Perhaps also make it apply to package-info, for targeting an annotated package.

Now, all usages, of any annotations, which are annotated with @io.avaje.validation.constraints.Constriant etc...
All of those classes using constraints will have validation adapters generated for them.

---

This leaves us with the adjusted first example:

import io.avaje.validation.constraints.NotBlank;

record User(@NotBlank String name, int age) {}

...where User is automatically detected as "needing" a validation adapter.

[SentryMan]

It can be a big pain-point that they are named the same thing.

I mean avaje validator/http works with all of them so even though you mix it doesn't actually affect anything. I suppose what's the pain point?

[mechite]

It's confusing to people

[SentryMan]

well you got me there

[SentryMan]

well, we could add a compile warning if http valid is being used on a pojo when the others are in the classpath, would that help?

[mechite]

It definitely can but being able to do something like @ValidatorModule would be really nice, just falls under the same boat as module-wide record builders for me

The warning is already enough really

[mechite]

@SentryMan I accidentally tapped the close button

[SentryMan]

@ValidatorModule

might be better to move that request to the validator repo