Sounds great.

Regards,

Michael

On Tue, May 16, 2017 at 8:33 AM, Gunnar Morling <gunnar@hibernate.org> wrote:

I've been discussing the issue of the module name a bit with Emmanuel
and we concluded that a non-binding recommendation in an appendix to
the BV 2.0 spec should be alright. I've filed PR
https://github.com/beanvalidation/beanvalidation-spec/pull/174 for it,
saying:

    "While not specified by this specification, Bean Validation
providers are encouraged to use the module name `java.validation`
in case they provide the Bean Validation API as a module for the Java
Platform Module System (as defined by JSR 376).
A mandatory module name - which may be `java.validation` or another
one - will be defined in a future revision of this specification."

This leaves the door open for choosing another value - and making it
mandatory - down the road, while letting 2.0 providers converge on one
non-officially sanctioned name for the time being (which is needed for
the migration between providers).

--Gunnar

2017-05-09 18:50 GMT+02:00 Michael Nascimento <misterm@gmail.com>:
> In the JPA mailing list, Bill Shannon and Linda were saying specs shouldn't
> mention anything about modules at this point. Some suggested this could be
> done at the next MR. It's better to align with them then.
>
> Regards,
> Michael
>
> On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar@hibernate.org>
> wrote:
>>
>> So "java.validation" should work (as a recommendation for now).
>>
>> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
>> anything in the spec (JAX-RS reference API just has a module-info.java
>> with a name they chose). We could do the same, and just have that
>> "recommendation" by putting this name into the reference
>> validation-api JAR, hoping that alternative API providers (Geronimo)
>> would do the same.
>>
>> Personally I don't think there's much to loose by putting a
>> recommendation into a spec appendix. If needed, the name can change
>> when making it a mandatory thing in a future revision.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>>
>> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel@hibernate.org>:
>> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
>> >
>> > On 3 May 2017, at 20:26, Michael Nascimento <misterm@gmail.com> wrote:
>> >
>> > I know it's late to reply to this, but seems fine. I'd consult the Java
>> > EE
>> > EG just to make sure they don't want to use a javax.ee prefix (which
>> > seems
>> > odd, though). Using the predominant/"root" package for the module is
>> > what
>> > I'd recommend too.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar@hibernate.org>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Java 9 is still in the works, so it's too early to put anything final
>> >> into the BV spec, but should we add a recommended module name for API
>> >> modules?
>> >>
>> >> My thinking is to have a short appendix stating:
>> >>
>> >>     "Implementors that wish to provide the Bean Validation API in form
>> >> of a Java 9 module,
>> >>      should use the module name "javax.validation". A mandatory module
>> >> name will be
>> >>      defined in a future revision of this specification".
>> >>
>> >> A commonly agreed on module name is required by Jigsaw to ensure
>> >> different API modules (e.g. the reference one and the one provided by
>> >> Apache) are interchangeable.
>> >>
>> >> I expect further changes to the spec to support Java 9 down the road
>> >> (e.g. to resolve message bundles in client modules and to provide a
>> >> way for passing in a Lookup granting private access (see [1]), but
>> >> it's nothing we can bake into the spec yet.
>> >>
>> >> Thoughts?
>> >>
>> >> --Gunnar
>> >>
>> >> [1]
>> >>
>> >> http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev