LockingAndVersioningRepository's delete method clash with CrudRepository'delete method

[lmtoo]

I use kotlin defined an interface as follow:

@RepositoryRestResource(path = "documents", collectionResourceRel = "documents") interface DocumentRepository : JpaRepository<Document, String>, LockingAndVersioningRepository<Document, String>

but the compiler compilation fails :
Inherited platform declarations clash: The following declarations have the same JVM signature (delete(Ljava/lang/Object;)V) fun <S : Document!> delete(p0: S!): Unit defined in com.lubansoft.archives.document.DocumentRepository fun delete(p0: Document): Unit defined in com.lubansoft.archives.document.DocumentRepository

[paulcwarren]

I am not a Kotlin guy and haven't had an opportunity to try it yet. Although, I note it increasing popularity and buzz (at SpringOne this year). But all this means that I might need a bit of help with this one. Is it possible that you can provide a sample application that exhibits the problem?

[schocco]

both, CrudRepository and LockingAndVersioningRepository define a delete() method.
The accepted type is <S extends T> in the versioningRepo but just T in the CrudRepo - this might cause the clash.

@lmtoo As a workaround you can override the delete method in your interface like this:

interface DocumentRepository : CrudRepository<Document, UUID>, LockingAndVersioningRepository<Document, UUID> {

    override fun delete(document: Document) {
    }

}

[paulcwarren]

Thanks for the info @schocco that is helpful. I can certainly take a look at changing that return type for you both.

[paulcwarren]

Hi @lmtoo @schocco - this commit changes the signature of the delete method on the LockingAndVersioningRepository to match that of the CrudRepository. Its available from snapshot repository (1.0.0.M10-SNAPSHOT):

		<repository>
			<id>snapshots</id>
			<name>nexus</name>
			<url>https://oss.sonatype.org/content/repositories/snapshots</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>

Would one of you mind verifying if this fixes the issue, or not.

Many thanks.

[paulcwarren]

I think we have resolved this so I am going to close it. Please feel free to re-open if you find otherwise.

[schocco]

Would one of you mind verifying if this fixes the issue, or not.

Many thanks.

I just tested with 1.0.0.M10 and can confirm that the issue is solved.

[paulcwarren]

Thanks @schocco. The confirmation is very much appreciated.