8:37 p.m.
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
5:03 p.m.
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
6:34 p.m.
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.
Why do you consider it as not proper?
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
6:56 p.m.
The improperness of optional dependencies is already well documented
elsewhere, so I won't get into that.
I just think the "cleanest" solution, given the situation, is a separate
module/artifact (hibernate-money) defining the types and contributor. I
personally don't think this use-case "fits the mold" of a provided
dependency (on hibernate-core).
Of course then I ask myself about the practical aspect of using the
optional dependency approach versus a dedicated module for just a handful
of classes.
On Tue, Dec 22, 2015 at 11:34 AM 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.
Why do you consider it as not proper?
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
7:01 p.m.
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
7:26 p.m.
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
8:31 p.m.
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
9:02 p.m.
That's true. The dependency graph alone doesn't tell the full story so the
user needs to read the docs to understand the magic binding. In fact, it
was not that bad because the default mechanism was using the JDK proxies,
so the cglib/javassist was just as a performance optimization.
I see your point, as that's what I used in FlexyPool too:
https://github.com/vladmihalcea/flexy-pool
Each connection pool or even JDK 7 specific API are moved to separate
packages, but the end-user still needs to read the docs to know which of
those dependencies to include.
I'm not aware of the dangers of optional dependencies. If you recall such
an article/discussion, could you add it to this discussion.
Thanks,
Vlad
On Tue, Dec 22, 2015 at 9:31 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
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
>
9: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
11:09 p.m.
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...
On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar(a)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(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
9:23 a.m.
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(a)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...
On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar(a)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(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
6:13 p.m.
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(a)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(a)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...
>
> On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar(a)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(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
8:04 a.m.
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(a)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(a)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(a)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...
> >
> > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar(a)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(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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)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
4:29 p.m.
For sure we will support it in some fashion. The discussion is simply
about the how
On Mon, Jan 4, 2016 at 1:04 AM Petar Tahchiev <paranoiabla(a)gmail.com> wrote:
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(a)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(a)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(a)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...
> > >
> > > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling
<gunnar(a)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(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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)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
3034
days inactive
3048
days old
13 comments
5 participants
participants (5)
-
Gunnar Morling -
Petar Tahchiev -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea