+1 thanks Gunnar.
marco
On Tue, May 16, 2017 at 4:32 PM, Christian Kaltepoth <christian(a)kaltepoth.de
wrote:
> +1
>
> 2017-05-16 15:00 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
>
>> Sounds great.
>>
>> Regards,
>> Michael
>>
>> On Tue, May 16, 2017 at 8:33 AM, Gunnar Morling <gunnar(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>> >> >>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > beanvalidation-dev mailing list
>>> >> > beanvalidation-dev(a)lists.jboss.org
>>> >> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > beanvalidation-dev mailing list
>>> >> > beanvalidation-dev(a)lists.jboss.org
>>> >> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> _______________________________________________
>>> >> beanvalidation-dev mailing list
>>> >> beanvalidation-dev(a)lists.jboss.org
>>> >>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > beanvalidation-dev mailing list
>>> > beanvalidation-dev(a)lists.jboss.org
>>> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
>
> --
> Christian Kaltepoth
> Blog:
http://blog.kaltepoth.de/
> Twitter:
http://twitter.com/chkal
> GitHub:
https://github.com/chkal
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>