So I know we like to have API compatibility discussions these days, so
let's start a new one.
FWIW, this discussions doesn't come out of the blue, it's based on
discussions we had for one of Marko's PRs.
In HV, you can set the parameter name provider at the VF level and you can
also override it on a per Validator basis using
To be honest, I'm a bit skeptical about the usefulness of overriding this
setting at the Validator level: it really seems to be a global setting,
especially because it has an influence on what could be considered a
metadata and metadata are considered static in HV.
At the moment, the parameter name is resolved at runtime each time it's
required due to this feature.
I would like to deprecate the feature for now and possibly remove it in a
future version (I thought about maybe keeping the method for a while but
logging a warning stating it's not doing anything anymore?).
We expect some runtime performance enhancement (this is not the reason of
this post) but it seems we could also get rid of storing the Executable in
the metadata and reduce our memory footprint for executables, which would
I am able to build the documentation using Andrea's suggestion and now I'm
struggling with gradle.
I released the staging repository on nexus last night to make a deadline.
I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
probably a mistake.
Today I went back to build the distributions. The problem is that after
setting the version back to 5.1.13.Final in build.gradle, gradle
automatically recompiles and rebuilds the jars.
That is (obviously) a problem because they won't be the same as what was
uploaded to nexus.
I've been trying some things out on a copy of the directory so I still have
the original jars intact.
I've tried --no-rebuild, but it doesn't seem to work.
Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I
really don't want to do that.
It's been bugging me for a while and I took some time this morning to do
some changes to the post list pages of the blog.
We currently display the whole articles whereas I thought it would be
better to only display a summary of them and get people to the full article
with a button.
I pushed the changes on http://staging.in.relation.to/ .
It's based on the Asciidoctor preamble (most of the time) so it takes the
paragraphs that are before the first title. It's not perfect but it works
pretty well for most of the posts. We should probably try to write our
posts so that the summary looks good.
I opened an issue in the JPA spec here yesterday:
because @PreUpdate and @PrePersist events are not fired when I save a
collection on the owner. Since then, a discussion with Oliver Gierke from
the SpringDATA team started and I wanted to know your opinion on this.
Basically the question is: if you have Product with a Collection<String>
attribute and you update the collection, shall @PreUpdate event be fired.
As Oliver mentioned the JPA spec says:
The PreUpdate and PostUpdate callbacks occur before and after the database
update operations to entity data respectively.
so to me it is obvious that when an attribute of the Product is changed
then this means that @PreUpdate event for the Product must be fired.
What do you think? Should I open a bug in Hibernate?
Public PGP Key at:
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
I'm in the process of releasing 5.1.13, and I'm not able to build Hibernate
Integrations Guide. I was able to build it for 5.1.12 without any problem.
The task that fails is assembleDocumentation and is the error is below. 
There have not been any changes to that guide for 5.1.13, so I'm not sure
why this would be failing.
I even tried executing the same task using 5.1.12 source, and it fails with
the same error.
I need to tag the release tonight. I'll have to get this resolved somehow
tomorrow so I can build the distributions for the release.
Does anyone know how to fix this?
rendering Book(integrationsGuide) en-US/html
Extending script classloader with the jdocbookXsl dependencies
redirecting console output to file
Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
Error reported by XML parser: The markup declarations contained or
pointed to by the document type declaration must be well-formed.
Resetting console output