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
