When I run 'gradlew cleanEclipse eclipse' my project looses the 'Gradle DSL Support' and the 'Dependency Management'. The only way to activate is by hand (Right Click->Gradle->Enable DSL Support), for every project inside Eclipse.
There is a way to do this from the command line? I have a large number of projects and so far I haven't found any information on the official DSL documentation.
Thanks in advance,
This is exactly as expected because when you run Gradle command 'cleanEclipse' it wipes out all the eclipse metadata and then 'eclipse' task rewrites it.
However, gradle itself is not aware of the tooling support such as 'DSL enabled' and won't generate the metadata for that.
To avoid this, use 'Refresh All' from the Gradle tool menu in Eclipse itself. This will also execute 'cleanEclipse eclipse' but also reinstate previous settings like DSL support.
I realize this is not really an answer to your question "There is a way to do this from the command line?". You could try only running the 'eclipse' task and not 'cleanEclipse' which is the one that wipes out the metadata.
Also, may be good to point out that DSL support in Gradle STS tooling has been discontinued in STS 3.7.0, so the answer to this question may not be very relevant in the future.
Related
In Maven you can do mvn eclipse:eclipse to run the eclipse goal of the maven-eclipse-plugin. Is there a similar way to do this in Gradle? I'd like to run the plugin for my IDE of choice but I want my build script to remain "IDE-agnostic".
I don't want apply plugin 'eclipse' in my build.gradle file but want it to generate the Eclipse files it needs. This way users of IntelliJ won't need to swap it.
Rather than rely on the build tool to configure your IDE (who ever thought that was a good idea is beyond me), set up the IDE to understand and integrate with the build tool. Eclipse is specifically designed to share configuration in such a way that each person who checks out a project from source control gets the project configured correctly with a minimum of manual intervention. Gradle support is much newer and somewhat less mature than Ant or Maven, but it works. See the Buildship project, which allows you to point Eclipse at your existing Gradle-based project and import it as a properly configured Eclipse project, no need for hacks like mvn eclipse:eclipse (which is now deprecated/retired, by the way)
Do eclipse project->build, project-build all, project->clean commands work with gradle projects? If they do, which gradle tasks do they invoke and where is console output.
Thank you!
--- Vadim
An eclipse project build/clean does normally use the integrated eclipse java compiler instead of gradle build system. So your build output is inside /bin folder. The eclipse internal build is very fast because of the eclipse delta compiler etc.
When you build your projects in gradle normally /build/** folders are used for gradle output results.
So you got "two worlds" / two output folders. This is important to understand when you are using console parallel with eclipse. Some gradle integrations for eclipse try to change this default behaviour and are adding special Builders to call gradle for build/clean etc. but - in my opinion - this will increase build time too much when your projects are growing bigger.
Instead of buildship you could also use EGradle IDE (https://marketplace.eclipse.org/content/egradle-ide).
Its lightweight, fast and compfortable. You can very simple call tasks in this eclipse integration for gradle. More information can be found at https://github.com/de-jcup/egradle/wiki/Help
We are currently using Spring STS Gradle for Eclipse and it works great. But since there is a new plugin coming from Gradle team I wanted to try it out.
STS Gradle integration executes Gradle tasks, it's not using Gradle tooling API. This is really good design decision:
you can generate eclipse project from command line or import project using wizard in Eclipse and result is the same
you can customize Eclipse Gradle Tasks, so that every developer has the same code formatting rules, find bugs, check style, capabilities and so on ....
No comes a part where I'm a bit fuzzy.... It looks to me that Buildship uses Tooling API instead of executing Gradle tasks. Both implementation are coming from Gradle team, so why not reuse already existing tasks?
Is this close integration with eclipse so important, that we have to give up possibility for customization?
I know - this sounds more like rhetorical question. But I would really like to understand the reason for such decision. Missing customization possibilities are no-go for many potential users.
I am using Gradle 1.12 to build an Android library. The build script works fine and the artifacts are installed to both a Maven local repository and deployed (using an S3 wagon Gradle plugin) to a remote Maven repository. When these artifacts are referenced by a Gradle (1.12) build of a sample app using the Maven local repo, all works fine. When the remote repository is used, a Gradle dependency resolution error is reported [details on the error will be provided later].
To get more information about the problem in order to fix my script or file a bug report, I would like to do some debugging of Gradle 1.12 while the sample app build script runs. Eclipse would seem to have the debugger of choice but configuring Eclipse is the subject of this post.
Following advice on the Gradle forums, it is straightforward to configure Gradle startup options to suspend on startup and await a connection from a client debugger (Eclipse).
Configuring Eclipse to do this is proving difficult. At first glance, it would seem that one needs a Gradle plugin. Spring Source provides a recommended one. But this plugin appears to bury and use Gradle 1.10. Perhaps upgrading this plugin to use 1.12 is easy and an answer that details how to do this would be a great answer.
The critical pieces of the answer I am looking for will enable me to place breakpoints in Gradle classes and step through source code until I either find a bug or figure out what I might be doing incorrectly in my build script.
Alternative approaches, such as using Intellij or Android Studio would be good answers as well if accompanied by details and/or references that make it clear how to enable the Gradle debugging process.
Debugging Gradle works exactly the same as (remotely) debugging any other Java application. No Gradle plugin is needed for this. In a nutshell, you need to start a remote debugging session from an Eclipse project that has Gradle sources. One way to create such a project is to clone the Gradle GitHub repository and run gradlew eclipse.
I'd be interested to find out about any automated processes that people have for ensuring that the project classpaths for the ant and eclipse configurations are in synch. In my case, I want the classpath defined in the ant build file to be the master configuration, since its used for our production builds. As part of the build i'd like to add an ant target that will verify that the eclipse classpath is up to date, or at least indicate differences between the two classpaths.
I'm aware of ant4eclipse but its focus is in the opposite direction, ensuring that the eclipse classpath is master and that the ant build reuses the eclipse path. I like the idea behind AntAndEclipse but am wondering are their ant other tools in this space that i'm not aware of.
You solution at a previous company was to have ant invoke Eclipse to do the compiles as described here:
http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
I'm not aware of any ant tools which can do this but I've switched from ant to Maven a few years ago and never looked back. You can use the "Maven integration for Eclipse" to make Eclipse use the Maven classpath.
As of today, I'm not 100% happy with the Eclipse plugin, though. It's a bit slow and due to the different philosophy of Eclipse and Maven, some operations behave strange. For example, Eclipse doesn't differentiate between a "production" and "test" classpath, so you can get compile errors in Maven when everything looks great in Eclipse.
My solution was to use the plugin to keep the classpath in sync and compile from the commandline.
there is an ant task to do xml transformations, we used that task to create the classpath in our build file. It was a little trick to get the XSL right but once it worked it was great
Did you evaluate Apache IVY? Currently I am building a Continuous Integration environment at our place and we use IVY to handle our dependencies. There is a eclipse plugin that takes the dependency configuration of eclipse and uses it as eclipse classpath.
Currently this solution looks quite promising.
My team wrote an Eclipse plug-in to add a new type of library to the Java Build Path->Add Library option in the project settings. This custom library type allowed both Eclipse and ANT to reference the same canonical list of dependencies.
Nowadays, I'd probably look at IVY for doing the same thing if I was locked into using ANT, rather than writing my own.
You need Ant2Eclipse.