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