How to file a bug report on 2.14.1.. ./gradlew eclipse cmd

Help/Discuss Buildship
1

I tried to post this exact post here, but the software said I can’t post more than 5 links as a new user(please note that there is only two links)…

Can anyone help?

thanks,
Dean

2

I’ll just respond to the individual points on stack overflow:

  1. I’m not aware that we transfer compiler options to Eclipse. Neither with
    the eclipse task nor in Buildship.

  2. That snippet doesn’t make sense to me unfortunately. Your main resources
    are already on the test classpath, you shouldn’t add those folders to the
    test folders.

  3. cleanEclipse deletes everything that was generated by Gradle. It doesn’t
    delete the whole .settings folder because that can contain manually defined
    settings too.

Can you please open a separate question about the app plugin with an
example of what you are trying to do?

3

After seeing your other thread I can comment more on 2.:

You should put your resources in src/main/resources. Then you can remove all this code from your build script :slight_smile:

4

  1. ./gradlew eclipse definitely seemed to transfer the compiler options while the gradle plugin did not :frowning: and it sure would be nice to keep that same behavior. I feel there should be a ticket to match that previous behavior that was lost(perhaps it is not very high priority but some of us would really like it). I think it did this in my intellij gradle plugin testing to but I am less sure there as I haven’t fully tested that out.

  2. We have had a good amount of pushback on putting it in src/main/resources for various reason(some good, some not so good) but we love to make customers happy and go that extra mile here(so each can customize the way we like…something we like about gradle too). Gradle is awesome in allowing flexibility and it is more desired to keep that flexibility. The gradle plugin worked great and allowed this while the ./gradlew eclipse command seems broken in relation to the plugin. Can’t we get a bug report to fix ./gradlew eclipse to match the plugin(it actually used to work in previous releases of eclipse/gradle but broke in newer versions). Is gradle moving away from being flexible like it was in the past?

  3. cleanEclipse ‘generated’ my .settings file. I was very detailed in my testing here and I had wiped all my .settings file. I then ran ./gradlew eclipse and ./gradlew cleanEclipse. It is not symmetric basically. It’s like opening 3 file descriptors and only closing two of the 3. I realize that it may wipe other ‘user modified’ settings but it is a full clean so users would expect it to wipe ALL eclipse files. I never expected it to leave some. This caused quite a bit of confusion and debugging to figure out. Perhaps a warning telling people ‘are you sure as this will really do a clean’ or having a cleanAllEclipse in the plugin as having to keep deleting .settings files myself that ./gradlew eclipse generates is quite annoying. Either way, I think we should have some sort of small jira ticket to track here and fix(to be prioritized lower perhaps).

thanks,
Dean

5

oh, and on #2 I was talking to someone on that topic. His comment…

“It really sucks when you create a new package in src/main/java and then have to do the same in src/main/resources instead of just re-using the first one to put the html files”…

ie. it causes more work so putting the stuff in src/main/java just makes life easier.

6

The code you showed is definitely not what you want, so the bug is not in the Eclipse plugin. If you want resources in src/main/java, all you would do is this:

sourcSets.main.resources.srcDir 'src/main/java'
7

As for the clean task: If in your specific case you want to delete the whole folder, then you can configure the task to do so. No need to change the behavior for all Gradle users.

8

IntelliJ doea that automatically for you. It’s just a best practice that everyone uses because it makes configuration easier. With the snippet I showed above you’ll have to worry about the correct includes and excludes, so you don’t accidentally package the java sources in your jar. But if that’s what it takes to make your customer happy, go for it :slight_smile:

9

We had that previously actually. Our current gradle build takes src/main/resources/. AND also src/main/java//*.html but the snippet above blows away reading from src/main/resources completely so that didn’t quite work. then gradlew eclipse didn’t work with it while the gradle plugin did. (a bit of incosistency between the two).

I was just trying to help the next developer not waste an hour like I did on that issue. I think there are ways in which it could be improved making it more obvious or something is all. I don’t really mind once I know but wasted time finding out.

what??? how??? maybe I should try to encourage training back down here. When I create a package com/buffalo/test in intellij src/main/java, I don’t see it create one in src/main/resources so how do you get that to work. that would be kind of cool (though who knows if I will hear a complaint of the files are still heavily separated…not sure there but I would like to know how).

10

IntelliJ has different views. The physical project view shows you src/main/java and src/main/resources sperately. But as far as I remember there is also a package view that shows the files in one tree. When you create a new file there, it decides where to put it based on the file extension.

11

The snippet I showed definitely doesn’t prevent reading from src/main/resources. But without a reproducible example project it’ll be hard to give concrete advice. Could you create one on GitHub?