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 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 :
>
>> Correct.
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 :
> 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
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
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 :
> You mean in addition to Maven's own documentation? Quote[1]:
>
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 nee
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 Jav
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 po
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 wou
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
wrote:
> On 22 December
On 22 December 2015 at 17:34, Gunnar Morling 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 i
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
> 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
valid
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 depend
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=0x19658550C3
14 matches
Mail list logo
