Ehcache upgrade
by Alex Snaps
Hey,
I've forked core on github and pushed changes to upgrade hibernate-ehcache module to the latest ehcache & Hibernate SPI (which was still using the deprecated CacheProvider).
I've pushed changes for the 3.5 & 3.6 branches. Currently working on master...
Should I create a JIRA for that ? I also wondered about any release plan for these versions ?
Thanks,
Alex
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
13 years
Integrator locator
by Steve Ebersole
HHH-5562 is done, which introduces a locator/discovery means for integrating
with Hibernate. Specifically it introduces the (alternate name suggestions
welcome, i am indifferent to this one) org.hibernate.impl.Integrator
interface.
It does discovery based on a classpath lookup for a well-defined filename (can
discover multiple) which names an implementor of this interface. The process
occurs in the midst of Sessionfactory building to account for the main use
cases I know of including Envers, Search, Validation and BV. Currently I
additionally define those 4 as "built in" integrators, meaning there is no
need for them to define auto-discovery files unless we want them to be
integrated in that manner (I know for example that Search is interested in
this via HSEARCH-595). Anyway, we should probably decide pretty early which
integrations we want done which way.
Actually I take one part back. Envers is actually handed by discovery due to
the fact that it is in a separate project (jar). The others were done this
way because they already had the reflection code in place to do this. So for
it, we need to decide if we want to go the opposite way.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years
HSEARCH-679 status
by Tom Waterhouse
I see that HSEARCH-679 is scheduled to be released in Hibernate Search
3.4.0. I haven't seen any progress on the issue though. If it will help
moving the issue along I can definitely test proposed solutions, we can
reproduce the issue consistently. Unfortunately we've reproduced the issue
during product demonstrations to potential customers, hence the urgency on
our end to see the issue resolved.
Cheers,
Tom
13 years
Moving Hibernate Search test packages
by Sanne Grinovero
Hi,
it's sometimes useful from the test packages to be able to get
package-level visibility to classes in the main code.
All Hibernate Search tests are organized in a
"org.hibernate.search.test.X" package;
I'd like to move them to "org.hibernate.search.X.Y", i.e. give test
implementors the freedom to choose any package name.
It's of course possible to obtain the same with many clever tricks,
but it would make tests easier to write and cleaner to maintain.
Main code API is not affected, as obviously our test conventions don't
prevent people to do as they wish with their own package names...
to the opposite, we might be able to close down more APIs which
nowadays need "public" for testing purposes;
I'm not sure if there is such a case, just making the point that in theory it
A) won't make things worse
B) could make things better
I could either make a single commit moving them all out, or we can
just start making some tests out of the test package on a "as needed"
base.
WDYT?
Cheers,
Sanne
13 years
Fwd: [issues.gradle.org] Commented: (GRADLE-1174) The IdeaPlugin defines all of $buildDir as excluded
by Steve Ebersole
So it looks like this might be workaround-able...
---------- Forwarded message ----------
From: "Szczepan Faber (JIRA)" <issues(a)gradle.org>
Date: Apr 4, 2011 10:46 AM
Subject: [issues.gradle.org] Commented: (GRADLE-1174) The IdeaPlugin defines
all of $buildDir as excluded
To: <steve(a)hibernate.org>
[
http://issues.gradle.org/browse/GRADLE-1174?page=com.atlassian.jira.plugi...]
Szczepan Faber commented on GRADLE-1174:
----------------------------------------
I think following workarounds should help:
ideaModule {
//manipulate the default excludeDirs:
excludeDirs -= "someFolderIDontWantToExclude"
//or prepare your own list of excludeDirs:
excludeDirs = [project.file('.gradle'), "$project.buildDir/excludeMe"] as
Set
}
> The IdeaPlugin defines all of $buildDir as excluded
> ---------------------------------------------------
>
> Key: GRADLE-1174
> URL: http://issues.gradle.org/browse/GRADLE-1174
> Project: Gradle
> Issue Type: Bug
> Components: Idea
> Reporter: Steve Ebersole
> Fix For: 1.0-milestone-2
>
>
> The {{IdeaPlugin}} defines all of {{$buildDir}} as excluded which messes
up attempts to use, for example, generated sources such as from Antlr which
writes to {{$buildDir/generated-src/antlr/}}.
> Therefore declarations such as
> {code}
> ideaModule {
> sourceDirs.add( file( '$buildDir/generated-src/antlr/main' ) )
> }
> {code}
> have no effect
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
Lucene 3.1 : we're ready as well, but should have have it in 3.4?
by Sanne Grinovero
Hello,
I'm sure you all have heard all the noise about the Lucene 3.1
release, it has indeed some interesting changes [1]; it's almost
drop-in compatible with Lucene 3.0.x but providing some interesting
performance improvements and a huge amount of bugfixes.
Some of these fixes are memory leaks, index corruption, failing to
properly update index contents, returning stale IndexReaders.. a long
list of improvements that we would like to provide to our users as
well.
In practice, I already did all the work:
https://github.com/Sanne/hibernate-search/commits/HSEARCH-705
Just one concern: we're currently in CR1 phase.
Shall we get this in, or postpone for 3.5 ?
Some details:
If someone was to try to use current Hibernate Search with Lucene 3.1:
* Faceting won't work
* RAMDirectory won't work
There are many more changes in the tests, but this is of no interest to users.
In the opposite case, if we upgrade and people wished to stay on
Lucene <3.1, it won't work:
we need to use some of the new APIs, especially TotalHitCountCollector
to count for matches is now a requirement when queryResultSize() is
used, but this class didn't exist in Lucene 3.0.x.
The Infinispan Lucene Directory works fine with all versions of Lucene
2.9.x, 3.0.x, 3.1.0, so this dependency is not going to block this.
Opinions? if there's time for it, I'd propose a CR2 to get this update
in, would be nice to have HSEARCH-679 as well as Tom contributed a
test for it.
Sanne
[1] - http://lucene.apache.org/#31+March+2011+-+Lucene+Core+3.1+and+Solr+3.1+Av...
13 years
callback induced actions
by Steve Ebersole
Currently, if a callback (jpa-style, Lifecycle, Listener) called during during
a flush results in an action (as in ActionQueue) being added, that action is
ignored until the next flush cycle.
I thought we discussed (in st louis) adding a feature to allow those actions
to be caught up in the original flush cycle. But I cannot remember the
outcome of that discussion as to whether that was something we wanted to look
at for 4.0.
The solution is essentially a recursive flush. There is obviously a danger
there and we would certainly want to depth-limit this.
What do y'all think about getting this into 4.0?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years
building core from master
by Sanne Grinovero
Hello,
I really wanted to merge my super-trivial patch using the new JUnit4
capabilities, but I'm having some issues in building core.
1)IntelliJ
(after solving the OOM issues with the annotation processor)
It doesn't find the ANTLR generated files, hence I can't run my test
as it has a compile failure.
2)Eclipse
the configuration files generated by gradle are totally wrong, but I
could fix them by hand.
Now Eclipse refuses to compile the project as there's a circular dependency:
the testsuite from hibernate-core depends on the hibernate-testing
module, which in turn depends on hibernate-core.
This doesn't look right, I guess we should merge this module back into
hibernate-core?
Reopening in IntelliJ to figure out why it seemed to almost work there:
In fact, it's showing a warning about circular dependencies, but
somehow it can work around it.
3) Command line
./gradlew clean build
Gets me 100 compile errors, related to the usage of @Override in the
generated code, I guess Gradle could also somehow could workaround the
dependency circularity but didn't set the compiler to Java6
compatibility:
TestLogger_$logger.java:515: method does not override or implement a
method from a supertype
@Override
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
100 errors
FAILURE: Build failed with an exception.
Suggestions? Is it working fine for everyone else?
Cheers,
Sanne
13 years
