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 <st...@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 <gun...@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 <st...@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 <gun...@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 <st...@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.v...@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 < > > sa...@hibernate.org> > > >> >> wrote: > > >> >> > > >> >> > On 22 December 2015 at 17:34, Gunnar Morling < > gun...@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 <st...@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 > > >> >> > >> <paranoia...@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@lists.jboss.org > > >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >> > >>> > > >> >> > >> _______________________________________________ > > >> >> > >> hibernate-dev mailing list > > >> >> > >> hibernate-dev@lists.jboss.org > > >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >> > > _______________________________________________ > > >> >> > > hibernate-dev mailing list > > >> >> > > hibernate-dev@lists.jboss.org > > >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >> > _______________________________________________ > > >> >> > hibernate-dev mailing list > > >> >> > hibernate-dev@lists.jboss.org > > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >> > > > >> >> _______________________________________________ > > >> >> hibernate-dev mailing list > > >> >> hibernate-dev@lists.jboss.org > > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> >> > > >> > _______________________________________________ > > >> > hibernate-dev mailing list > > >> > hibernate-dev@lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
