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
