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
> 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
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
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
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
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 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
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
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
