[hibernate-dev] On Hibernate Search and non Public API use of Core and other SNAPSHOT concerns

[Hardy Ferentschik]

Hi,

I agree with most of what Emmanuel said - isolation from Core API and no  
third
party SNAPSHOTS.

When it comes to Core though I think it is useful to depend on a SNAPSHOT.  
It is
the fastest way to detect integration problems. If a Core SNAPSHOT  
disappears you
can easily deploy a new SNAPSHOT.
If a major change in Core occurs requiring a bigger integration effort,  
you would
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,  
but rather
the problem with building Core on Mac using JDK 6 (HHH-5277 - really a  
maven bug).
Doing though will screw up you local repository and you will get all sort  
of strange
behavior. I also lost several hours on this one :(

--Hardy

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  
> by  
> http://in.relation.to/Bloggers/SimultaneousHibernate355And360Beta3Releases#comment16656
> 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  
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-580
> ( 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
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-581
>
> * 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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev