[hibernate-dev] javax.money

Tue Dec 22 17:09:59 EST 2015

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
>