[hibernate-dev] javax.money

Wed Dec 23 03:23:14 EST 2015

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