[Validator] CRLF Git issue
by Emmanuel Bernard
I had a strange problem this morning.
It was based on a earlier commit of Hibernate Validator from May 2nd
6bbe986b0ce8e309e23a811db919ce760ae58589
warning: CRLF will be replaced by LF in
engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/PatternValidator.java.
The file will have its original line endings in your working directory.
I had the following warning and whatever I tried (stash, reset --hard
etc) I could not get it fixed. I could have used
git config core.autocrlf false
But it feels like hiding the problem. I ended up with a clean clone.
Do you guys have any idea of what went wrong? If I checkout the infamous
commit, the error reappears.
Emmanuel
PS: I felt like that
http://toub.es/2012/05/28/fatal-crlf-would-be-replaced-lf
In fact, I even forgot what I was supposed to check in the first place
;)
12 years
[OGM and others] API, SPI and FPI
by Emmanuel Bernard
(This discussion is around OGM but it is a very generic subject applicable to all projects.)
I made a mistake in naming the spi packages SPI because the definition of SPI is quite narrow and even more narrower in Java than elsewhere.
## Definitions
### SPI
In Java and according to Wikipedia, a SPI (Service provider interface) is related to the notion of ServiceLoader http://en.wikipedia.org/wiki/Service_Provider_Interface
We certainly do not (or very rarely) have these kinds of services in our SPI packages.
Another point of you comes from this StackOverflow article
https://stackoverflow.com/questions/2954372/difference-between-spi-and-api
- the API is the description of classes/interfaces/methods/... that you call and use to achieve a goal and
- the SPI is the description of classes/interfaces/methods/... that you extend and implement to achieve a goal
A third point of you is the NetBeans one
http://wiki.netbeans.org/DevFaqApiSpi
SPI stands for Service Provider Interface. It is a subset of all things that can be API specific to situations where a library is providing classes which are called by the application (or API library), and which typically change the things the application is able to do.
I think everyone agrees that an SPI is kind of API.
### IPI or FPI (Integrator / Framework Public Interface)
I will use FPI as it tastes better than IPI but I have no preferences over integrators vs frameworks.
Now in my mind and for some obscure reasons, SPI really meant FPI. To my credit, I have done that fairly constantly on Hibernate Search and Bean Validation. Hibernate OGM was never properly packaged initially so that’s another story.
A FPI is used by a framework integrating or extending the project exposing these FPIs.
## What does really matter?
It is useful to differentiate an API used from an API extended (SPI) because the constraints are different:
- APIs used can add new methods and should be interfaces rather than classes.
- APIs extended (SPIs) should be abstract classes so that a new contract added can be offered by the project without breaking implementors.
But from a user point of you, I’m tempted to say "so what?”. It does not change your inclination to make use of that contract.
It is useful to differentiate application developer(*) facing APIs from framework/integrator facing APIs (FPIs) to keep the API simple to use and to document. There is also a tendency to consider the application developer more sacred than the framework/integrator when it comes to breaking backward compatibility.
(*) I say application developer here but it really the primary user group of your project whereas the integrators are usually less numerous and more controllable.
To me the latter (API/FPI) is more generally useful and that is the one I wish to separate in different packages naming conventions.
The former it seems to me is very often self-obvious to the user and project maintainers. And from a usage PoV, it does not really matter. Plus there are cases where a contract is both used and extended (JDBC’s Connection contract for example).
Can and should we split according to both dimensions? I don’t think so. And if I have to chose, I’d prefer to split according to the API/ FPI dimension which is more generally useful to our customers and makes it clear what is non breakable (API), what is inconvenient to break (FPI), what is free lunch (implementation).
## References
There has been some discussions in the past as well https://issues.jboss.org/browse/TAG-47
Emmanuel
12 years
Does @ContainedIn trigger reindexing
by Marc Schipperheyn
I couldn't find a test on this and I'm wondering if with a structure with
on the one hand @IndexedEmbedded(includePaths={"id","someField"}) and on
the other hand @ContainedIn, there would be a reindexing triggered of the
embedded element if "someOtherField" was changed at the root element (but
not any of the indexedembedded paths). In other words, is @ContainedIn
"smart"?
Marc
12 years
Hibernate OGM 4.1.0.Beta3 is out, bringing improved support for Neo4j, querying and more
by Gunnar Morling
Hi,
It's my great pleasure to announce the release of Hibernate OGM 4.1.0.Beta3.
This release is focused on an improved experience when working with the
Neo4j graph datastore and several improvements in the field of querying.
Check out the announcement post for all the details [1].
--Gunnar
[1]
in.relation.to/Bloggers/HibernateOGM410Beta3IsOutBringingImprovedSupportForNeo4jQueryingAndMore
12 years
EntityPersister and Queryable
by Gail Badner
Because AbstractEntityPersister implements Queryable (but EntityPersister does not), core does something like this to get access to Queryable interface methods:
final Queryable queryable = (Queryable) sessionFactory.getEntityPersister( entityName );
Is this an acceptable way for an application to get access to an entity persister's Queryable interface or is there some explicit SPI that should be used?
Thanks,
Gail
12 years
HQL-Parser project to move to Java7?
by Sanne Grinovero
One of the modules of the HQL Parser project is now going to require
Java7 at runtime, which implies I have to compile that one with Java7
and use Java7 for testing.
Would it be ok to move the whole project to use Java7?
I don't stricly need all modules to drop Java6, but it would keep the
build simple, and I suspect we have no reason to keep this project
Java6 compatible.
Sanne
12 years
Released HQL Parser versions 1.1.0.Alpha1 and 1.1.0.Alpha2
by Sanne Grinovero
I've released both versions:
1.1.0.Alpha1 is compatible with Hibernate Search 5.0.0.Alpha1
1.1.0.Alpha2 is compatible with Hibernate Search 5.0.0.Alpha4
(I needed both as there are too many changes in Search to handle a single leap)
The target Java version is 1.6 as discussed with Steve; however if
you'll us it in combination with Hibernate Search 5 you'll need Java7
anyway (independent modules).
Cheers,
Sanne
12 years
