Hi, I am not a OSGi expert, but I guess we can think about this a little more. As you say org.hibernate.validator and org.hibernate.validator.constraints should definitely be public. Regarding the classes in org.hibernate.validator.engine I would suggest to create a new package. ResourceBundleMessageInterpolator and ResourceBundleLocator needs to be exported. Not sure about yet if there is something else.
I am still processing my email backlog and will have a closer look later. --Hardy Create a Jira issue and we can take it on board for Validator 4.1 On Sun, 18 Apr 2010 20:57:18 +0200, Gunnar Morling <gunnar.morl...@googlemail.com> wrote: > Hi guys, > > currently I'm experimenting a bit with integrating Bean Validation in > general and Hibernate Validator in particular with OSGi. In that context > I > wondered, whether there is some sort of "public" API of Hibernate > Validator. > The generated HV OSGi manifest (see HV-267) currently exports all > packages, > but I think there should be a more fine-grained distinction, which > packages/classes should be publicly available. > > For instance "org.hibernate.validator" and > "org.hibernate.validator.constraints" would be part of such a public API > (while "org.hibernate.validator.constraints.impl" wouldn't). Things are > getting more complicated when looking at > "org.hibernate.validator.engine". > Most of the classes there should be considered private to HV, but at > least > ResourceBundleMessageInterpolator (together with the new stuff related to > ResourceBundleLocator in > "org.hibernate.validator.engine.resourceloading") > is of interest for users/integrators. > > Using OSGi, one can control exported types on a class level, but > presumably > it makes things easier, if certain complete packages make up the public > API. > Also besides the OSGi scenario I think it's useful to explicitly describe > the public API. That way users would know, which HV classes they are > "allowed" to use (and therefore can rely on their stability) and which > ones > not. We OTOH would know which classes we can modify without the need to > maintain backward compatibility. > > WDYT? If we come to the conclusion that for instance > ResourceBundleMessageInterpolator should be moved to another package, I > think it might be a good idea to do that for 4.1, as right now the > number of > concerned classes still seems very limited. > > Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
