Upgrade to gradle 4 need new hibernate fix for deprecated msg

Help/Discuss
1

I am getting the following message(which is fine and I am trying to fix it)

Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 4.0
at build_34sns4859auhw206idq79d91j$_run_closure2.doCall(/Library/Workflow/webpieces/webserver/build.gradle:42)

My code at line 42 is this
sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir

The reason is the way the annotation scanner works is it ONLY scans the ONE jar or the ONE directory where the persistence.xml file is. If there is two persistence.xml files, it scans two jars or directories(or combo thereof). This makes it FASTER as it only scans that directory.

Soooo, previously, I would output the resourceDirectory to the classes directory where the entity exists so my tests and builds did not break(ie. the above one liner). This new world is confusing however. I do not see how to make sure persistence.xml ends up in the right directory.

specifically, I do know all my entities are in java so how to move all resources to
{myproject}/{output}/classes/java/main/

NOTE: turns out the above also results in double the size of the jar as well as it zips those class files twice now :(. Eclipse works just fine as it merges all *.class file and resource files into one single directory in a project so eclipse has no issues. only in the gradle build is there issues.

Ideally, I should be able to stick META-INF/persistence.xml in java/src/main where it belongs and gradle would work. is there a way to do that? (ie. persistence.xml is supposed to LIVE WITH the hibernate entities and end up in the same folder, same jar, etc. etc.)

thanks,
Dean

2

Does anyone have a solution for this yet? I am still stuck on upgrading and getting rid of that warning?

thanks,
Dean

3

oh and I should mention, it needs to keep working in intellij and eclipse as well (as sometimes I solve 1 problem like working in just gradle but then eclipse or intellij breaks because their plugin behaves differently than the actual gradle build tool)

4

oops, lastly in my first post, I missed the entire snippet in the gradle file…

//ok, this is the deal here.  JPA/hibernate made the decision to look for a persistence.xml file
//and scan for classes with @Entity in the directory OR jar with that xml file only
//maven(and I hate this) a long time ago separated src/main/java and src/main/resources but
//this screws tools in many situations like this one so this puts it back so the output is at
//least put to the same location
sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir
compileJava.doLast {
   tasks.processResources.execute()
   logger.warn("processed resources="+sourceSets.main.output.resourcesDir)
}