DATAJPA-497 - Fixed handling of OrderSpecifier for Querydsl based repositories.

We now only generate an additional left-join for the order expression of the targetPath is an EntityPath.

Original pull request: #69.
DATAJPA-501 - Adapted auditing configuration to latest changes in Spring Data Commons.

The configuration subsystem now sets up an AuditingHandler with a direct reference to a MappingContext. We now also wire an ObjectFactory into the AuditingEntityListener instead of the AuditingHandler directly.

This also lets us get rid off the need to mark AuditorAware instances as lazy initialized as the initialization chain is interrupted right at the AuditingEntityListener.

Related issues: DATACMNS-365.
DATAJPA-485 - Upgraded build profile to Hibernate 4.2.11.
DATAJPA-500 - Verify that sorting of Embeddables with Querydsl works.

Added test case to verify that sorting by nested embedded attributes with querydsl expressions works. Previously a ClassCastException was thrown due to changes in org.springframework.data.jpa.repository.support.Querydsl.

Original pull request: #70.
DATAJPA-502 - Fixed version ranges in template.mf.

Fixed the version ranges for Hibernate, Joda Time and Sl4fj.
DATAJPA-504 - Regression in Querydsl OrderSpecifier customization.

Removed custom querydsl left join generation for order fields.
The recent versions of Querydsl already do this properly - so there is no need for us anymore to add left-joins ourselves.
Previously we had to generate additional left-joins since Querydsl did not support ordering by an attribute that was not part of the projection.

Original pull request: #73.
DATAJPA-466 - Add support for lazy loading configuration via JPA 2.1 fetch-/loadgraph.

We now support load-graph / fetch-graph QueryHints on repository query methods, which are applied when a JPA 2.1 capable JPA implementation is used. We explicitly reject the usage of those hints in case the user is running a JPA 2.0 provider.

FetchGraphs / LoadGraphs can now be defined on the Entity via the @NamedEntityGraphs annotation.

@Entity
@QueryEntity
@NamedEntityGraphs(@NamedEntityGraph(name = "GroupInfo.members", attributeNodes = @NamedAttributeNode("members")))
public class GroupInfo {

  @ManyToMany List<GroupMember> members = new ArrayList<GroupMember>(); //default fetch mode is "lazy".
}

The entity graph "GroupInfo.members" overwrites the fetch-mode of the members collection to be "eager".

The entity graph to be used can now configured on a repository query method.

@Repository
public interface GroupRepository extends CrudRepository<GroupInfo, String> {

	@EntityGraph("GroupInfo.members")
	GroupInfo getByGroupName(String name);
}

The new method JpaQueryMethod#getEntityGraph analyses an @EntityGraph annotation and constructs a new JpaEntityGraph value object that contains the information form the annotation. The new method AbstractJpaQuery#applyEntityGraphConfiguration tries to apply the given EntityGraph configuration if the used JPA persistence provider supports the JPA 2.1 spec.

Changed the class path order such that EclipseLink is now placed before the eclipse dependency. EclipseLink references the JPA 2.1 API and allows us to provide type-safe support for the new JPA 2.1 features.

Original pull request: #74.
DATAJPA-460 - Support query creation for deleteBy / removeBy prefix.

Added implementation of deleteBy / removeBy support for JPA backed repositories. We delete entities by looking them up with the appropriate query and delete them afterwards via entityManager.remove(...). This is rather inefficient but provides the benefit of being able to use the query derivation mechanism for entity deletion as well.

Original pull request: #66.
DATAJPA-460 - Reduce implementation to core requested feature.

Removed the additional deleted flag in @Query as we currently already ship with a method to manually implement delete-queries (using @Modifying and a manually defined JPQL query).

Tiny optimization in DeleteExecution.

Original pull request: #66.
DATAJPA-505 - Projections for basic primitive arrays should use SingleEntityExecution.

We now execute a query as a SingleEntityExecution if the return-type of the particular query-method is an basic char[],Character[], byte[], Byte[].
Previously we tried to do an CollectionExecution which didn't return all elements of the actual result (e.g. the byte[]).

Although EclipseLink and Hibernate support the use of array elements in projections OpenJPA seems not to. Filed https://issues.apache.org/jira/browse/OPENJPA-2484 to track the issue. Since OpenJPA prevents the bootstrap of the whole test suite I had to comment the query method + tests out. Tested Hibernate / EclipseLink by temporarily excluding all OpenJPA tests from the test-suite.

Original pull request: #71.
DATAJPA-481 - Prepare release 1.6 M1.

Updated Spring Data Commons and Spring Data Build version in pom.xml. Update pom.xml to use milestone repository. Update reference documentation to use recent Spring Data Commons version. Update changelog to reflect recent changes / releases. Update version in notice & readme.

Original pull request: #75.
DATAJPA-481 - Release version 1.6.0.M1.
DATAJPA-481 - Prepare next development iteration.