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 <emman...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
