[hibernate-dev] On Hibernate Search and non Public API use of Core and other SNAPSHOT concerns
hibernate at ferentschik.de
Fri Aug 20 04:43:38 EDT 2010
I agree with most of what Emmanuel said - isolation from Core API and no
When it comes to Core though I think it is useful to depend on a SNAPSHOT.
the fastest way to detect integration problems. If a Core SNAPSHOT
can easily deploy a new SNAPSHOT.
If a major change in Core occurs requiring a bigger integration effort,
of course lock the Core version until the issue is resolved.
The issue we had when using a 3.6 SNAPSHOT was not the SNAPSHOT per se,
the problem with building Core on Mac using JDK 6 (HHH-5277 - really a
Doing though will screw up you local repository and you will get all sort
behavior. I also lost several hours on this one :(
On Fri, 20 Aug 2010 10:11:08 +0200, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> This is a follow up on IRC's discussion between Steve and Sanne spawned
> Since I wasn't there and now you are all gone, I'm using email :)
> Here is my opinion
> * Hibernate Search should not depend on non public Hibernate Core APIs
> HSearch is aimed at working with other backends in the medium run (does
> this expression exist?). So we should isolate Hibernate Core use of
> public APIs and certainly not use non public APIs.
> Let's code move SoftLimitMRUCache, into HSearch codebase
> ( on a side note, SoftLimitMRUCache could be considered a public API as
> it is referenced in a public API JavaDoc (Environment) )
> Also the use of org.hibernate.util.StringHelper in HSearch is wrong. We
> have org.hibernate.annotations.common.util.StringHelper
> * Hibernate Search should not use third-party SNAPSHOT dependencies
> (including Core)
> Using snapshots makes the build non reproducible (snapshots go away) and
> we did lose close to a collective day of work on such issue not so long
> ago when HSearch was depending on Core 3.6.0-SNAPSHOT
> * what to do for Core 3.6 and HSearch
> We should release v 3.3 beta 1 (see a previous email on mine on
> documentation). I will spend some cycles on this.
> * How to prevent such problem in the future
> Good question.
> Follow rules above :)
> Sanne's idea of having some integration (hudson) job specifically
> altering Core version to the SNAPSHOT scheme in HSearch's pom seems to
> work if Core publishes snapshots regularly. I am not sure if this can be
> trivially set up though.
> Ideally, right before a final Core release (including micro points), we
> should test the expected HSearch version with it (for example Core 3.5.x
> with HSearch 3.2.x latest) but that's a manual step to add on a long
> list of manual steps. Not sure that's viable.
> PS: These rules are even truer (SIC) for Hibernate Validator but HV 4
> has been a better citizen
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev