2:55 p.m.
To me, "optional" seems like the right thing for this case.
"Provided"
(at least in the Maven world, I don't know whether Gradle has
different semantics) suggests that this stuff is really to be provided
by the runtime; I interpret this as a mandatory requirement towards
the environment (i.e. a Java EE container *has* to provide the javax.*
packages).
Optional instead indicates that this stuff may be present at runtime
or not. If it is present, some optional functionality will be
available to the user, otherwise not. For the case of Money the user
is depending on these types anyways - and thus required to expose them
on the runtime class path - if he is wishing to work with these types
in his own code (or not otherwise). No need to analyse the dependency
graph or whatsoever.
As said we use that style in Hibernate Validator for optional
constraint validators, and it works well, I can't remember of any
related issue or complaint. I suppose it'd help if you could point to
that resource describing potential issues with optional.
2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
Well the Bitronix use-case is actually a perfect illustration of why
optional/provided dependencies stink. Nothing in the dependency graph
indicates what you are expected to do here. Bitronix users would have to
look at the documentation to understand this; and dependency graph/analysis
tools would be completely at a loss. And in Bitronix the "decision" is all
internal to Bitronix. Here at least the argument is a little more
justified because we are really talking about looking to see if another set
of classes (library) are present from the application's classloader (since
the application would need to bind to Moneta, etc statically).
'optional' is flat out wrong; that is well documented elsewhere. I can be
persuaded to use 'provided' for something like this, as I already stated.
On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> That's how Bitronix Transaction Manager managed optional dependencies as
> well.
> In its case cglib and javassist were optional dependencies and at runtime
> the framework decided whether to load one provider or the other.
>
> Vlad
>
> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>
> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
> > >> yes we could use an optional/provided dependency, but
> > >> that would not be "proper".
> > >
> > > That would actually be my preference; If the javax.money types are
> > > present, enable the required Types etc. otherwise not. It's a pattern
> > > we e.g. use in Validator, too, where we provide additional constraint
> > > validator types based on what's available in the runtime environment.
> >
> > +1
> >
> > > Why do you consider it as not proper?
> >
> > Same question for me. It might not be perfectly well defined in terms
> > of Maven dependencies, still I think the practical benefit for users
> > far outweights the cons.. if that's what you're referring to.
> >
> > Sanne
> >
> > >
> > >
> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
> > >> I had planned to support this JSR when I thought it would be part of
> the
> > >> JDK. But as it is, supporting this properly would mean a whole new
> > >> module/artifact just to add these few types + the dependency (similar
> to
> > >> hibernate-java8). I am not a fan of the fact that it would require a
> > >> separate dependency; yes we could use an optional/provided dependency,
> > but
> > >> that would not be "proper".
> > >>
> > >> I am interested in what others think.
> > >>
> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
<paranoiabla(a)gmail.com>
> > wrote:
> > >>
> > >>> Hi guys,
> > >>>
> > >>> I've been playing lately with JSR 354 javax.money api (
> > >>> http://javamoney.java.net) and I was wondering if there's any
plans
> > for
> > >>> hibernate to support this.
> > >>>
> > >>> Thanks.
> > >>>
> > >>> --
> > >>> Regards, Petar!
> > >>> Karlovo, Bulgaria.
> > >>> ---
> > >>> Public PGP Key at:
> > >>>
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311
0611
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev(a)lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev