3:11 a.m.
This is a follow up on IRC's discussion between Steve and Sanne spawned by
http://in.relation.to/Bloggers/SimultaneousHibernate355And360Beta3Release...
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
3:41 a.m.
2010/8/20 Emmanuel Bernard <emmanuel(a)hibernate.org>:
This is a follow up on IRC's discussion between Steve and Sanne
spawned by
http://in.relation.to/Bloggers/SimultaneousHibernate355And360Beta3Release...
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.
As the Search pom is referring to Hibernate Core version as a property
no change is needed in the current poms, you could just add a new
Hudson job which overrides the property:
mvn clean test -DhibernateVersion=3.6.0-SNAPSHOT
You could have this quick check triggered after each successful core
build to get instant feedback (option "Build other projects" in
Hudson).
Also using "Aggregate downstream test results" you could have the core
build flagged as "failed" if the Search build fails - not sure if that
would be brilliant but you could give it a try for an higher level of
automation.
Needless to say, the build of Core should be changed from "clean test"
(as I assume it is, but don't know) to "clean install", to make sure
the triggered Search build uses the updated core.
Cheers,
Sanne
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:43 a.m.
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(a)hibernate.org> wrote:
This is a follow up on IRC's discussion between Steve and Sanne
spawned
by
http://in.relation.to/Bloggers/SimultaneousHibernate355And360Beta3Release...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:05 a.m.
On 20 août 2010, at 10:43, Hardy Ferentschik wrote:
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 :(
We I had the snapshot issue and later had an unable to create the snapshot issue which
ended up in the lost time.
My points for not *committing* snapshots are:
- being able to check out HSearch and build it from back in time seems an important
feature to me especially to our team backporting fixes when needed. Since snapshots get
deleted, we can't guarantee that.
- when you commit and say go work on other stuffs, the next guy picks up the
build-that-does-not-build(tm) and sees his blood pressure go to the roof. We don't
want that. While we should detect issues early, they should not block people from
committing unrelated stuffs, which is the case in this model.
The AS team has moved to a no SNAPSHOT in commit policy for these reasons and possibly a
few more. You can of course depend on the snapshot in your local build, just don't
commit it. Also Sanne's proposal seems to be even more efficient.
7:17 a.m.
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/hibernat...
) nor EntityInsertAction (
http://docs.jboss.org/hibernate/core/3.6/javadocs/index.html?org/hibernat...
)
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/SimultaneousHibernate355And360Beta3Release...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5263
days inactive
5263
days old
4 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole