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

[Steve Ebersole]

First, as I said in the chat we really have no way currently to
differentiate classes we intended for user consumption and those we
dont.  We have the broad concepts of "API", "SPI" and "internal".  And 

BTW, every single class in the Hibernate codebase is referenced in the
javadoc; so that's a bit of a strawman argument.  Clearly we dont want
users directly using say TwoPhaseLoad
( http://docs.jboss.org/hibernate/core/3.6/javadocs/index.html?org/hibernate/engine/TwoPhaseLoad.html ) nor EntityInsertAction ( http://docs.jboss.org/hibernate/core/3.6/javadocs/index.html?org/hibernate/action/EntityInsertAction.html )
nor ...

We *just* added reference to SoftLimitMRUCache in Environment javadocs
(as in 3.6.0.Beta3).  So thats hardly an argument as to why this was
used in search considering that code was added waaaay before
3.6.0.Beta3 ;)

Core does regularly publish SNAPSHOTs.  Once a day in fact (provided
something has changed).

On Fri, 2010-08-20 at 10:11 +0200, Emmanuel Bernard 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

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org