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 <paranoia...@gmail.com> 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 <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
