[hibernate-dev] javax.money

[Steve Ebersole]

Correct.  And things are "possible in any number of ways".  Some are just
more right than others.  The fun is the fact that the question of which
which is more right can be different depending on your perspective and that
is clearly the case here.

>From the user's perspective the best solution is actually the least
attractive from the Hibernate development side of things... specifically
the best option for the user is for Hibernate to specify a compile-only
dependency (optional, provided, etc is irrelevant) and for Hibernate to
internally isolate itself from cases where javax.money is not available on
the classpath (reflection, etc).  Ultimately I think this is the direction
to go for this particular integration.

On Wed, Dec 23, 2015 at 2:23 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> It's software, so everything is *possible*. Question is whether we
> deem it acceptable for the user having to depend on another submodule
> or not. If you think that's ok, then go for it ;)
>
>
> 2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > You mean in addition to Maven's own documentation?  Quote[1]:
> >
> > "Optional dependencies are used when it's not really possible (for
> whatever
> > reason) to split a project up into sub-modules. The idea is that some of
> the
> > dependencies are only used for certain features in the project, and will
> not
> > be needed if that feature isn't used. Ideally, such a feature would be
> split
> > into a sub-module that depended on the core functionality project...this
> new
> > subproject would have only non-optional dependencies, since you'd need
> them
> > all if you decided to use the subproject's functionality."
> >
> > Beyond Maven's own documentation, simply google...
> >
> > [1]
> >
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
> >
> > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> 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 at 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 at 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 at hibernate.org>
> >> >> wrote:
> >> >>
> >> >> > On 22 December 2015 at 17:34, Gunnar Morling <gunnar at 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 at 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 at 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 at lists.jboss.org
> >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > >>>
> >> >> > >> _______________________________________________
> >> >> > >> hibernate-dev mailing list
> >> >> > >> hibernate-dev at lists.jboss.org
> >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > > _______________________________________________
> >> >> > > hibernate-dev mailing list
> >> >> > > hibernate-dev at lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>