It was the "release family". 4.3, or 4.2... On Mar 2, 2015 9:22 AM, "Sanne Grinovero" <sa...@hibernate.org> wrote:
> On 2 March 2015 at 15:05, Steve Ebersole <st...@hibernate.org> wrote: > > Hmm, I had used to set the set the Specification-* entries too, but it > looks > > like those are no longer there :( > > Just out of curiosity, what would these define? > But not too bad, I think I'll simply rely on parsing > org.hibernate.Version#getVersionString > > > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gun...@hibernate.org> > wrote: > >> > >> > Or we could improve on those methods, if not actually adding some easy > >> to consume resource in the orm jars. > >> > >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF > >> -> > >> key "Implementation-Version"? > > Right that could work as well. There will be many manifests on > classpath I'd guess, but we could identify the one from ORM from the > other keys, such as Bundle-Name, Implementation-Vendor-Id, etc.. > But how would that be better over using > org.hibernate.Version#getVersionString ? > > I guess one benefit of basing on resources would be that we'd be able > to check for duplicate ORM jars, but are we interested into going to > that length? It wouldn't be fool-proof either, as in a modular world > it's possible that ORM version A has visibility on Search (and > attempts to start it) but Search could be validating on resources from > ORM module B - and not be able to "see" ORM version A's resources. I > guess I'd stick with the method invocation, as obviously we can't > implement a bullet proof validation either way. > > Sanne > > >> > >> Based on that you should be able to raise a meaningful error if the ORM > >> version is "too old". It doesn't help with incompatible future ORM > >> versions, but it should improve the experience in some cases. > >> > >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: > >> > >> > All, > >> > it looks like people get easily confused by which version of ORM is > >> > compatible with - for example - Hibernate Search. > >> > > >> > The expected versions are documented plenty, in readme, project > >> > sources, documentation and we even remind about the expectations > >> > frequently in blog posts. > >> > > >> > Wondering if it would be more effective to have some marker in ORM, to > >> > validate at least for most critical known incompatibilities at > >> > runtime? > >> > > >> > I realize there is no 100% foolproof in any possible solution, but > >> > providing a nice error message to 90% of these cases could be helpful > >> > to a large population already, and doesn't seem too complex for us to > >> > do. > >> > > >> > I guess it could be simple enough to use the existing > >> > org.hibernate.Version ? > >> > Or we could improve on those methods, if not actually adding some easy > >> > to consume resource in the orm jars. > >> > > >> > WDYT? > >> > > >> > Sanne > >> > > >> > - https://hibernate.atlassian.net/browse/HSEARCH-1816 > >> > - > >> > > >> > > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 > >> > _______________________________________________ > >> > 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
