I’m converting a maven project with has resource filtering (substitution of ${properties} in config files) also working inside eclipse. I just save a property file and the builtin maven plugin (m2e) saves the processed file in the target folder.
I’m now converting this project to gradle and used the “filter ReplaceTokens”. It works in the command like when I do “gradle assemble” and saves the processed file to the build directory.
But inside eclipse the imported gradle project just uses a “bin” directory and there the file is not processed when saved.
May this be an incorrect use of gradle/buildship by me or that feature as maven does is not supported in buildship? If it’s supported, can you point me to a small project doing this?
this is not yet supported by Buildship. We would need task execution on auto build for that. That’s high on our priority list. If you are interested in contributing that feature, I’d be happy to walk you through the design process.
Same context: moving from Maven to Gradle, and on Eclipse side from m2e to BuildShip.
I’m interested to see proper resource filtering in Buildship. I can maybe help, since this “high priority” topic doesn’t seem to have been addressed after more than a year
What is the best place to discuss this? Is there a JIRA / GitHub ticket somewhere?
The current state of affair is that the eclipse Gradle plugin can configure resource filters, but this information is not available via the EclipseProject model in the Tooling API. To implement the story one has to extend EclipseProject and consume the new information in the Buildship synchronization model.
You can follow up on this issue at eclipse/buildship#271 and on the linked stories. You can contribute to Gradle/Buildship via pull requests, we gladly guide you through the process.
I have the impressions that we put 2 different things under the “resource filtering” concept.
src/main/resources folder contains files that should be available on the classpath (to allow finding them with myClass.getResources()), but that should not be considered as source code. For example Eclipse should not try to compile .java files under src/test/resources, and also probably not validate all .js files in node_modules. The problem is that in Eclipse, there is no concept of “resource” folder. So there is a need to tell Eclipse to “filter” some files from being processed by the auto-build.
variable substitution during resource files processing. This is called “filtering” in Maven, and I think this is why this is confusing. In Gradle we are using something like:
In Eclipse, we wants to ensure that at runtime (like when running JUnit tests) the classpath contains the “resolved” resources, not the original ones.
I remember m2e spent a lot of time trying to find a working solution, that would not trigger recursive auto-builds.
When importing a Maven project into Eclipse with m2e, resource folders have all their content excluded: <classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">
It means Eclipse will not touch resources files at all. I guess the Maven Builder will take care to copy resources to the output folder, applying variable substitution if needed. I think the Gradle Builder could do the same.
Maybe there’s a solution for your use case. You can adjust the Eclipse project generation in the build script. You can define the same excluding pattern:
That’s interesting options, but if I’m correct, none is 100% correct.
Option 1 (adding ‘**’ exclusion) alone will prevent files from being copied to the output folder. And consequently, running unit tests from Eclipse will not “see” them.
Option 2 doesn’t work because libraries are not exported to downstream projects. Using the Eclipse UI, I found that adding a class folder (+export it) is likely what is the more appropriate behavior.
Still the 2 options doesn’t support variable interpolation…
This may work if the source folder itself is added to the runtime classpath. Sure, it will also expose *.java source code files to the runtime in that case, so not entirely correct but this may be acceptable to at least some projects. Still investigating due to The project was not built due to "Resource already exists on disk" errors in eclipse
We don’t use (or want to use) separate *.java code and resource folders but I tried something similar to above to set up the excludes on the main source directory. I was able to configure Gradle Eclipse plugin to set them in the .classpath files it generates:
Edit 2: Even if I generate .classpath files before importing projects (the same way Buildship would create them) they get recreated when the projects are imported … without filters.
This will be deployed to many developers so hiccups aren’t good yet. I was willing to contribute but there isn’t much time - I have to deploy some sort of sturdy development environment solution soon.
I’d need to set up an actual p2 repository with your plugin and I don’t know how to do that yet.
The deploy folder is a p2 repository. You can host it in any (probably internal) web server and it’s done.
This will be deployed to many developers so hiccups aren’t good yet. I was willing to contribute but there isn’t much time
Well, I get it and it’s a same on my side. This should be a Buildship feature, but my official schedule doesn’t allow me to work on this feature. This is why I implemented this in my free time. It may not be “Buildship-quality” (e.g. no cross-version testing and else), but it’s pretty damn close. If I get feedback on it I’ll integrate it into Buildship.
Yes, we are using Goomph. Pretty awesome, with few notes:
We can’t use it to automatically import Gradle/Buildship projects. That is the only manual step left. It can import them but not as Gradle/Buildship … only as existing projects for which the eclipse plugin generates .project and .classpath files.
Insufficient control over where the workspace is created, not even an ability to programatically determine where it is.
I do think that your efforts should be a part of Buildship, though.
I may have to come back to your plugin. I seem only to have increased my chances of good luck but haven’t eliminated the failures altogether. This is crazy.
I am trying this route now. However, it seems that this configures exclusion of directories and not files (resources ) matching a pattern from within directories that should remain. I hope I just don’t know how to use this… Can you help me?
Having failed that, I wanted to try modifying Buildship itself… Failed, need help. Command-line build failed due to:
* What went wrong:
Execution failed for task ':assembleTargetPlatform'.
> Process 'command '/Users/.../.tooling/eclipse/targetPlatforms/eclipse-sdk/eclipse/Eclipse.app/Contents/MacOS/eclipse'' finished with non-zero exit value 13
We don’t use (or want to use) separate *.java code and resource folders but I tried something similar to above to set up the excludes on the main source directory. I was able to configure Gradle Eclipse plugin to set them in the