Trouble with blog for ORM 5.0.9
by Gail Badner
Hibernate ORM 5.0.9.Final is released. Everything is done except the
announcements.
I did `rake preview` and saw that my blog displayed correctly locally, so I
cherry-picked the commit with my blog to production and pushed the commit.
It's been over an hour and I still don't see it on http://in.relation.to/.
I tried `rake clean preview` on the production branch and now I see:
***************************************************************************
Starting preview server at http://localhost:4242 (Press Ctrl-C to shutdown)
***************************************************************************
[2016-03-14 22:23:50] INFO WEBrick 1.3.1
[2016-03-14 22:23:50] INFO ruby 2.2.1 (2015-02-26) [x86_64-linux]
rake aborted!
ERROR: Running Awestruct failed.
/home/gbadner/git/in.relation.to-again/Rakefile:104:in `run_awestruct'
/home/gbadner/git/in.relation.to-again/Rakefile:64:in `block in <top
(required)>'
/home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in `eval'
/home/gbadner/.rvm/gems/ruby-2.2.1/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => preview
(See full trace by running task with --trace)
Anyone have any idea what is wrong?
Thanks,
Gail
8 years, 1 month
Preparations for releasing Hibernate ORM 5.0.9.final
by Gail Badner
I am preparing to do the release.
I forgot to send an email about not pushing fixes after Sunday to allow us
to complete our testing before releasing 5.0.9.Final today. Unfortunately,
fixes for HHH-10592 and HHH-10608 were pushed after tests were successfully
completed.
I see that a CI test is failing:
http://ci.hibernate.org/job/hibernate-orm-5.0-h2/lastCompletedBuild/testR...
.
I need to move forward with the 5.0.9 release and do not have time to
investigate what is going wrong with the CI test and to re-run the
necessary tests, so I will revert the fixes for HHH-10592 and HHH-10608 to
get back to the state at which we know the tests are successful. After
releasing, I will change the version to 5.0.10-SNAPSHOT, and re-apply the
commits so they will be fixed in 5.0.10.
I still need to update the migration guide (HHH-10542). After doing so, I
will start the release. Please do not push any other commits until after
5.0.9.Final is released.
Any issues that are scheduled for 5.0.9 that are not resolved will be moved
to 5.0.10.
Thanks,
Gail
8 years, 1 month
Everyone: Need volunteers for mentoring GSOC
by Sanne Grinovero
Hi all,
earlier today in our IRC meeting [1] we discussed ideas for Google
Summer of Code;
mostly related Hibernate Search but not only:
Quoting the previous summary by Gunnar:
1 - Java Batch API job for HSEARCH mass indexing
2 - Solr backend
3 - HSEARCH support for JHipster
4 - HSEARCH support for Spring Data
5 - Async API for ORM/OGM/HSEARCH
[It's not a closed list, you can also propose additional ideas.]
is anyone on this mailing list interested enough on these subjects to
volunteer mentoring?
I mentored two students last year and we had nice results, but I won't
be able to mentor this summer.
It would need to be someone who's regularly contributing already, and
ideally someone familiar with the technology we're integrating with:
most of the above proposals are about integrating with some other
standard or framework.
For example I wouldn't mentor on JHipster as all I know about it is
what I've seen in a couple of presentations... but if the student is
not too junior he can also be tasked with reaching out to "the other"
community to get guidance.
But for that I'd want us to be able to make some introductions at
least, to have some kind of "co-mentor" volunteered by the other
community/project.
Thanks,
Sanne
1 - http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/...
8 years, 1 month
Returned mail: Data format error
by The Post Office
The original message was received at Fri, 11 Mar 2016 14:06:24 +0800
from lists.jboss.org [101.45.215.108]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
8 years, 1 month
The PAR archive test case validity - PackagedEntityManagerTest
by Vlad Mihalcea
Hi,
I have two tests in the PackagedEntityManagerTest unit test that fail on my
machine, but work just fine for everybody else.
It could be an OS thing or not, but during the check, I found hat we are
testing against an use case that is not found in the JPA spec.
The testExternalJar() creates an externaljar.jar and an explicitpar.par.
I found an old reference on the PAR archive (
http://radio-weblogs.com/0135826/2005/07/07.html) but the JPA 2.1 doesn't
mention anything about it.
The explicitpar.par contains the persistence.xml which contains a jar-file
attribute that references the externaljar.jar with an absolute path:
<jar-file>D:\Vlad\Work\GitHub\hibernate-orm\hibernate-entitymanager\target/packages/externaljar.jar</jar-file>
The JPA spec says that: "Such JAR files are specified relative to the
directory or jar file that contains the root of the persistence unit", and
gives several examples
for when using an EAR with or without a WAR.
While debugging, I found that the JarFileBasedArchiveDescriptor scans the
"explicitpar.par" and looks for:
if ( getEntryBasePrefix() != null && ! entryName.startsWith(
getEntryBasePrefix() ) ) {
continue;
}
where the getEntryBasePrefix() is
"D:/Vlad/Work/GitHub/hibernate-orm/hibernate-entitymanager/target/packages/externaljar.jar"
The way that JarFileBasedArchiveDescriptor is implemented matches the JPA
description.
Nevertheless, the scan cannot locate the jar, and the entities that are
contained in the "externaljar.jar" don't get loaded, and the test fails.
I can ignore this on my machine and just consider it a white noise, but I
wonder why we still check for PAR when we might want to have a test with an
EAR instead and relative paths.
Vlad
8 years, 1 month
Hibernate Search connecting to multiple Elasticsearch clusters
by Sanne Grinovero
Today our experiments are assuming we're connecting to a single
Elasticsearch cluster: one hostname to configure, etc..
I think this is an acceptable limitation for version 5.6 (our first
stable milestone to support this integration) but I'm wondering if we
should document it as a temporary limitation or as an intentional
design.
I think that eventually we should allow having different entities
(indexes) to be stored on different ES clusters; this shouldn't be too
hard to manage as the codebase is already structured around this
capability of having different types in different "indexes"; so while
a single Elasticsearch cluster can manage multiple indexes (that's a
bit of a novel concept) I see no reason to not allow different indexes
to be mapped on different clusters.
= Am I missing some strong reason to not allow this?
= While this will (likely) not be supported in 5.6, should the public
API and configuration properties allow for this to be configured
per-index already? (Changing it later would be a breaking change)
See also:
- https://hibernate.atlassian.net/browse/HSEARCH-2164
Thanks,
Sanne
8 years, 1 month
