Help

Inactive Bloggers

What do you get from a 10+ year old open source framework, thousands of users within a wide range of roles, and complexity? A JIRA instance with over 3,000 unresolved tickets ;). Is that number indicative of low software quality? Definitely not. But therein lies the problem. A vast majority of the tickets are no longer issues, no longer relevant, or duplicates. Due to the quantity, it became nearly impossible to weed through them all.

So, recently, I've given some effort towards attempting to clean things up. This has been a combination of manual reviews of tickets, scripts identifying possible duplicates [1], and various forms of JIRA queries that attempt to show stale issues. So far, I've reduced the number of un-assigned, un-resolved tickets by almost 1k. To date, only a few of those have turned up being issues that were still legitimate in ORM 4+.

In addition, I've enacted a few policies that have helped (and will continue to help) tremendously, both for contributors and the community as a whole. Most notably, any new BUG ticket that does not have a provided test case is immediately moved into an Awaiting Test Case state. If nothing is received within around 3 months, we've begun to automatically reject them. Although most contributors generally appreciate reproducers that are either standalone or extend one of ORM's pre-existing unit tests (preferably), at least providing enough detail (entities, mappings, code snippets, etc.) is the bare minimum.

Along the same lines, we've been discussing a possible tactic on the mailing list [2]. We'd like to push all ORM 3 tickets to the Awaiting Test Case state and request a reproducer on ORM 4 or 5. This would affect only BUGs with: 1.) affectsVersions set to ORM 3 only (not ORM 4/5) 2.) unassigned and 3.) not updated in the last 90 days. Those would then fall under our policy of automatically rejecting if the ticket does not receive a test case within 3 months or so. Please see the mailing list for the discussion, as well as the query that would be used. If there are any opinions against giving that a shot, please say so.

It's also worth re-iterating that JIRA should not be used instead of the user forums [3] or Q&A sites like StackOverflow. Please create tickets only for concise issues w/ reproducing test cases (or, of course, new features and possible improvements).

If you're interested in more info about the steps I took during the actual cleanup, a somewhat detailed write-up is here: http://www.3riverdev.com/blog/man-vs-jira-the-3000-issue-tracker-fight

If you have any questions or ideas, please contact me! brmeyer on Freenode IRC is your best bet, as well as comments on this post. Thanks!

[1] https://github.com/3RiverDevelopment/bug-tracker-duplicate-utils
[2] http://lists.jboss.org/pipermail/hibernate-dev/2014-March/011238.html
[3] https://forum.hibernate.org/viewforum.php?f=1

Last week we met up with Jason Greene and Brian Stansberry from the WildFly team.

In this you get to hear about the WildFly rename, its recent release that includes new web subsystem called Undertow, new JavaEE 7 features and a core distribution.

Show notes and episode

Have fun!

17. Mar 2014, 22:45 CET, by Brett Meyer

Hibernate ORM 4.2.11.Final was just released! Please see the full changelog for more information: https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=16153.

As previously mentioned, 4.3.x is the new stable version and we have shifted focus towards ORM 5.

One commit of note is HHH-8440, which added a new SQLServer2012Dialect that fully supports sequences. The rest were minor bug fixes and docs improvements, mostly from community pull requests (thanks!).

JBoss Nexus: https://repository.jboss.org/nexus/content/groups/public/org/hibernate
Maven Central: http://repo1.maven.org/maven2/org/hibernate/hibernate-core (should update in a couple of days)
SourceForge: https://sourceforge.net/projects/hibernate/files/hibernate4
Downloads: 4.2.11.Final ZIP, 4.2.11.Final TGZ

The release 5.0.0.Alpha2 is now available on our shiny new website: as the alpha1 release also did, it integrates with Apache Lucene 4.6.1, but now we do it better ;-)

<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-search-orm</artifactId>
 <version>5.0.0.Alpha2</version>
</dependency>

More Like This queries

New features! A More Like This query is a special kind of query which takes a model document as an input, rather than a traditional string. It has been available for you to use since a long time via Lucene's MoreLikeThis Query implementation, but this implementation was rather tricky to use on our richer entity based model. Hibernate Search now provides direct support for this functionality via our Query builder DSL, and in its simplest form looks like this:

Coffee exampleCoffee = ...

QueryBuilder qb = fullTextSession.getSearchFactory()
        .buildQueryBuilder()
        .forEntity( Coffee.class )
        .get();

Query mltQuery = qb
        .moreLikeThis()
            .comparingAllFields()
            .toEntity( exampleCoffee )
            .createQuery();

List results = fullTextSession
        .createFullTextQuery( mltQuery, Coffee.class )
        .list();

What does it do? It returns a list of Coffee instances which are similar to the exampleCoffee instance. The definition of similar is as usual controlled by the analyzers and indexing options you choose. By default the list is of course ordered according to the scoring model, so the top match would be the example entity itself (this might be surprising but is often useful in practice).

A more extensive blogpost about this will follow, but if you can't wait to learn more see all details in the Building queries chapter.

Faceting improvements

One of the highest voted improvement requests on JIRA, it is now finally possible to facet on embedded collections. Hardy also started exploring possible performance improvements, and how to use the new Lucene 4 features: feedback, use cases or patches would be very welcome as we're eager to improve faceting more.

Watch the migration guide

If you're updating an application from previous versions of Hibernate Search, we highly recommend to keep an eye on the Migration Guide as the changes in the Lucene API are significant and not always self-documenting. Suggestions for the migration guide are also very welcome.

The Apache Lucene Migration Guide might also be useful, but we applied most of it already to the internal engine for you to use transparently.

The hibernate-search-analyzers module is removed

This module was created years ago when we had to fork some Lucene code to allow an easy migration path, but is now since long an empty module just depending on various commonly used analyzers. It's time for spring cleaning of dependencies, so the no longer needed module is removed: if you where using it, just remove it from your project and include a direct dependency to the analyzers you need from the Apache Lucene ecosystem.

What's next?

You can find an high level overview on our Roadmap page, or check the fine grained break down on this JIRA filter. Essentially we're aiming now at OSGi compability and at usability improvements which had to be postponed to a major release.

May I present, fresh from the roaster, steaming hot and full of flavor - Hibernate Validator 5.1.0.Final. Validator 5.0 to 5.1 was a slow roast, outspread over several releases, but as you know, slow roasting enhances the flavor ;-)

The individual release blog entries highlighted the various changes for each release. Here is just a short summary with pointers to refresh your memory.

The main goal of Hibernate Validator 5.1 was to improve performance and memory footprint after releasing the initial reference implementation for Bean Validation 1.1. We achieved both and squashed several bugs along the way. If you want to know more have a look at HV-589, HV-637, HV-838 and HV-842. In particular the CDI integration (hibernate-validator-cdi) got an overhaul. As per specification, it should be possible to use multiple Bean Validation providers within CDI, selecting between them using qualifiers. In particular something like this should be possible:

...
@HibernateValidator
@Inject
Validator validator;

@Inject
Validator defaultValidator;
...
where the default Validator instance is not Hibernate Validator, but an explicitly via validation.xml configured provider:
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
                   xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <default-provider>com.acme.ValidationProvider</default-provider>
</validation-config>
Due to a bug this was not working, but now it is :-) See HV-858 and HV-865 for more information.

We also added a couple of new features. The most important one is the introduction of the ValidatedValueUnwrapper SPI. Refer to the Beta1 blog entry for more details. There are also a few new constraints. You can now make use of @Mod10Check, @Mod11Check (which are effectively replacing the now deprecated @ModCheck constraint) and @EAN (see CR1 blog entry). A feature related to the ParameterNameProvider introduced by Bean Validation 1.1 is the ability to use ParaNamer as parameter name provider (see HV-802).

Maven artifacts are as usual on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.Final and distribution bundles are available on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If you want to know where we are heading next, check out the Hibernate Validator Roadmap.

Don't wait, upgrade!
Showing 6 to 10 of 1200 blog entries