sourceSets broke compile when upgrade from 4.1 to 4.8

Help/Discuss
1

I have 2 issues on upgrading(not sure if I should file a bug or if apis have changed and I need to workaround/modify my build.gradle file).

I have this sourceSet ‘which breaks the compile’ in 4.8 BUT was fine in 4.1. Why does modifying resources break the compile?

sourceSets {
    main {
        resources {
            srcDirs += ["src/main/java"]
            excludes = ["logback.xml"]
        }
    }
}

Now, if I comment that out, well, this line stops working which is critical to get html files that co-reside with their controllers over to the output directories

    sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir
    compileJava.doLast {
       tasks.processResources.execute()
       logger.warn("processed resources="+sourceSets.main.output.resourcesDir)
    }

Is there a workaround?

An easy test to see this is

  1. checkout GitHub - deanhiller/webpieces: A project containing all the web pieces (WITH apis) to create a web server (and an actual web server) and
  2. run ./runAllTesting.sh (which runs gradle) and you will see 100% of things pass.
  3. THEN, modify webpieces/gradle/wrapper/gradle-wrapper.properties to point to 4.8.1 and
  4. again run ./runAllTesting.sh and now the project fails due to the issue in webpieces/webserver/build.gradle (the code above)

I just tested this process myself and 4.8 fails me :(. I am hoping for a workaround or new method of moving files from src/main/java/**/. while excluding *.java files over to the output/classes directories.

thanks,
Dean

2

Calling task.execute() is not allowed. Please remove that line. Also, you shouldn’t move resources to the same directory as classes, that’ll break caching. What kind of tool requires them to be in the same folder? Java can look up resources across multiple folders on the classpath.

3

a webserver we use requires html files and *.java files co-located. The html files go off the controllers package to line up…so this REALLY sucks

src/main/java/com/somecompany/myproject/usercontrollers/MyController.java

src/main/html/com/somecompany/myproject/usercontrolelrs/mypage.html

navigating between the controller and html has become the ultimate pain if they are divided. Therefore, and I think ‘rightly so’ as I don’t have to keep flipping between folders, the html file is along side the *.java file as in

src/main/java/com/somecompany/myproject/usercontrollers/MyController.java
src/main/java/com/somecompany/myproject/usercontrolelrs/mypage.html

way way easier on time spent navigating.

4

Is there another option to fix this? to move resources to same directory as classes?

thanks,
Dean

5

You can put them in the same source folder, sure. But there is no reason to

a) call task.execute
b) put the results in the same output folder

//bad
sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir
compileJava.doLast {
   //bad
   tasks.processResources.execute()

Simply fix those two by removing the code and you should be fine.

6

uh, hibernate broke doing that :(. I forgot to paste you the original comment on why that was done(someone from gradle told me to do that to fix hibernate).

Unless I modified it wrong. Here is my file changes on my upgradeGradleTo4-8 branch

Notice the comment is

    //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

soooo, somehow, the persistence.xml file is required to end up in the classes directory.

7

oh and this is a JPA issue not just hibernate.

8

Well, that’ll disable caching, but should still compile. Please remove that task.execute call.

Also I encourage you to open a JPA bug, because relying on folder structure is a terrible idea.

1 Like
9

yes, it compiles now, ohhhhh, ok, so I still need the line

sourceSets.main.output.resourcesDir = sourceSets.main.output.classesDir

All works now, thanks!!! Actually, the reason they do this makes a bit of sense. They don’t want to scan 100 jars for entities (or 100 folders) so they scan ONLY the jar containing persistence.xml and ONLY the folder containing persistence.xml so that file had to live in the folder and in production, in the jar file.

That said, I have been thinking of moving to https://vladmihalcea.com/how-to-bootstrap-hibernate-without-the-persistence-xml-file/

if I can figure out how to scan all entities in a ‘certain’ package and subpackages to limit the scanning of jars. The real issue is 1000’s of projects are on JPA or hibernate so it’s not likely to change I would think and I am not sure how well supported the interface in that link is since it is not that standard.

later,

Dean