Or we could improve on those methods, if not actually adding some easy

Or we could improve on those methods, if not actually adding some easy

Hmm, I had used to set the set the Specification-* entries too, but it looks like those are no longer there :(

On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; 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"?

> > 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 <sanne(a)hibernate.org&gt;: > > > 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-sessionimp... > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 2 March 2015 at 15:05, Steve Ebersole <steve(a)hibernate.org&gt; 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 <gunnar(a)hibernate.org&gt; 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 ?

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 <sanne(a)hibernate.org&gt;: >> >> > 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-sessionimp... >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

On 2 March 2015 at 15:49, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >> On 2 March 2015 at 15:05, Steve Ebersole <steve(a)hibernate.org&gt; 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 <gunnar(a)hibernate.org&gt; >> > 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 ? > > > The "Implementation-Version" value can be obtained through a standard API: > > Session.class.getPackage().getImplementationVersion(); > > So it basically renders that custom method superfluous. Cool trick, I had no idea :) So why do we have those methods? Just to log it? > > No huge difference apart from that. Only pointing out that there is no need > for another "easy to consume resource in the orm jars". > >> 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. > > > +1 for keeping it simple. > >> >> >> 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 <sanne(a)hibernate.org&gt;: >> >> >> >> > 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-sessionimp... >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev(a)lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I think we should point out that this method is only available (iiuc) when running with "from a jar". Which means it won't work, for example, in our test suites. I assume we'd just get blanks or nulls there. On Tue, Mar 3, 2015 at 9:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I just personally never knew about this method :) > > On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > >> On 2 March 2015 at 15:49, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> > >> > >> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >> >> >> On 2 March 2015 at 15:05, Steve Ebersole <steve(a)hibernate.org&gt; 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 < >> gunnar(a)hibernate.org&gt; >> >> > 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 ? >> > >> > >> > The "Implementation-Version" value can be obtained through a standard >> API: >> > >> > Session.class.getPackage().getImplementationVersion(); >> > >> > So it basically renders that custom method superfluous. >> >> Cool trick, I had no idea :) >> So why do we have those methods? Just to log it? >> >> > >> > No huge difference apart from that. Only pointing out that there is no >> need >> > for another "easy to consume resource in the orm jars". >> > >> >> 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. >> > >> > >> > +1 for keeping it simple. >> > >> >> >> >> >> >> 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 <sanne(a)hibernate.org&gt;: >> >> >> >> >> >> > 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-sessionimp... >> >> >> > _______________________________________________ >> >> >> > hibernate-dev mailing list >> >> >> > hibernate-dev(a)lists.jboss.org >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> >> >> _______________________________________________ >> >> >> hibernate-dev mailing list >> >> >> hibernate-dev(a)lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > >> >> > >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >