On 2 March 2015 at 15:49, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> On 2 March 2015 at 15:05, Steve Ebersole <steve(a)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 <gunnar(a)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 ?
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>:
> >>
> >> > 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
> >
> >