[hibernate-dev] javax.money
Petar Tahchiev
paranoiabla at gmail.com
Mon Jan 4 02:04:14 EST 2016
Any updates on this? What has been decided? Can we see some hibernate
support for this JSR?
2015-12-26 19:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
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
More information about the hibernate-dev
mailing list