Is it possible to bypass Ivy (or whatever else Gradle uses internally for dependency resolution) and still keep the same dependency DSL? I'm trying to develop a plugin for resolving native dependencies that would use the system's package manager to install dependencies, but Gradle's RepositoryHandler only allows Ivy, Maven, or flat dir repositories.
If you want to completely bypass Gradle's dependency resolution system, then you'll also have to create your own DSL. To do so, you would use Gradle concepts such as "extension objects" and "domain object containers".
Related
If I have one Gradle plugin that wants to read and modify the properties of another gradle plugin, I would need the source of the other plugin as a dependency, right? This way I could do project.pluginManager.getPlugin(PluginClass.class) and manipulate it's properties. Is it possible to include a gradle plugin as a dependency?
My specific use case is, I wish to make a plugin to detect if kotlin multiplatform plugin is applied and then generate some source files and add them as sources for the various compilations depending on the targets defined.
I'd like to know what will Intellij IDEA do with my Maven project when I click "build the project"?
How will Intellij build the project with Maven?
Intellij IDEA will not automatically do a make install when you do a Build Project. In order to do that, proceed as follows:
Under Maven Projects tab (usually on the right hand side), select the goals you want Intellij to run after a Build -> Make Project and then right click and select the trigger (for instance in the above snapshot, the trigger was chosen as 'Execute After Make'. You can choose whatever you wish).
After doing this a Build -> Make Project will run a mvn clean install as well.
IntelliJ's build system refers to the Maven ecosystem for some hints, but at the end of the day it is a separate build system.
In IntellIJ, you have a Project, with many Modules. These are both IntelliJ concepts.
An IntelliJ Module has a responsibility to understand what are its dependencies and libraries. This can be done purely with IntelliJ semantic, or IntelliJ can allow some other build system to declare the dependencies and libraries. That is to say: the IntelliJ Module can be based on a Maven pom.xml or Gradle's build.gradle.
When you click "Make" on an IntelliJ Java Module: IntelliJ will check which libraries your Module asks for, and also resolve the dependencies of your Module to work out which libraries its dependent Modules ask for.
Once the libraries are known: IntelliJ will invoke Javac or the Eclipse Compiler (whichever you've configured as your Java compiler) with all those libraries on the classpath. And it will output a jar, not a Maven artefact.
IntelliJ Make will not run a mvn compile or similar (unless you configure it to explicitly, as per #Ashutosh Jindal's answer.
Why would IntelliJ use its own, separate build system, when you've provided an authoritative definition for how you'd like to build your project? I can imagine various reasons:
Maven generally just outputs an artefact (sources and binary jars, and a pom.xml), whereas IntelliJ needs additional semantic and indexes to provide all its IDE intelligence. It makes sense to perform the indexing process alongside the compile, since: if you do the compile incrementally, you can understand incrementally which indexes are dirtied also.
The IDE benefits from being involved in the compilation process. For example: IntelliJ can do "continue on error" builds using the Eclipse compiler. Additionally, the Eclipse compiler can be used to compile only those files which have changed (IDEs watch you as you code, so they know very well which files are dirtied). I have heard that Maven does incremental compile, but I don't know how its performance compares.
In order to support a variety of build systems (Ant, Maven, Gradle): the easiest engineering choice for IntelliJ is to rely on the minimum possible amount of domain-specific semantic, and use that to inform one IntelliJ-specific build system. This allows them to re-use a large amount of code, and have few domain-specific differences.
I have been looking into Gradle and looks pretty interesting. I think being able to write your scripts in any other language than XML is pretty cool, and it is not clear to me whether polyglot Maven POM files are still a feasible option.
I am working on a project that uses Maven 2.2.1 as build tool. This project:
is multi-module
uses (also our own) plugins
relies on an Artifactory proxy repository
Are there any experiences out there on migrations from Maven to Gradle? Gotchas, pain points, corner cases? Any sort of experience is very welcome.
The migration from Maven to Gradle isn't as easy as from Ant to Maven (at the least at the moment). You can easily reuse Ant scripts and make them first class citizens in your Gradle build. There's a task on the Gradle roadmap for deep import of Maven builds as well.
So far I migrated two enterprise Maven builds to Gradle. Both of them were multi-module projects using standard Maven plugins. I basically rewrote the builds the Gradle way which requires at least some knowledge about Gradle. Based on my experience you can easily get the same build running in Gradle as well. Gradle doesn't really box you in here and is fairly flexible. Along the way you might find yourself having to write a custom plugin that doesn't exist yet depending on what Maven plugins you are using. However, there's already a wide breath of plugins out there. So far I haven't run into a real roadblock yet. Even though the Gradle documentation is pretty good you might find yourself reading a lot of Gradle forum posts to find the solution to one of your problems. Some of the standard Maven features are not supported out-of-the-box e.g. a provided scope or WAR inplace. However, there're easy ways around it. I haven't used Artifactory repositories. The ones I dealt with were Nexus repositories. As far as I know the Gradle guys have good support for Artifactory though. Edit: JFrog provides a Artifactory Gradle plugin.
A good way to start is to use the migration tool Maven2Gradle which let's you generate a Gradle script from your Maven build. Personally, I didn't use it yet. I developed the Gradle build side-by-side with the Maven build which didn't cause any trouble. Maven put its
output under target, Gradle under build. Make sure you prepare your team for the change. Let them try out the Gradle build and get familiar with the tool.
Once you are fully migrated you'll be very happy about the maintainability and extensibility of your build. It's very easy to add custom build logic and you're going to be grateful that you left XML-land. In terms of performance you are not going to make a step back as well. The incremental build feature does its job very well.
You may also want to read through this write-up of my experience porting a maven project to gradle.
In the directory where you have pom.xml just run the below command:
gradle init --type pom
This should convert your maven pom.xml to build.gradle
You can always change the buildDir to be 'target' under gradle if you want the build output to go under 'target' instead of 'build' like maven:
buildDir = 'target'
maven2Gradle seems to have been replaced with being able to run gradle init from the command line (though it's a rather experimental feature). It seems to work ok for doing some basic Gradle setup from a Maven project.
Is there a way to use the ivy cache grails dependency DSL creates within an IDE like eclipse or netbeans? Or must I manually add all dependencies to the IDE lib folder?
I've looked into plugins like ivybeans and ivyde, but they seem to require ivy.xml and ivysettings.xml files, which grails does not produce.
The Grails tooling provided by the SpringSource Tool Suite plugin for Eclipse has the functionality you desire. It reads BuildConfig.groovy and modifies the project classpath accordingly.
I just attached the following to the Jira bug.
In snooping around the STS distribution, I found the following code in
C:\springsource\sts-2.3.2.RELEASE\configuration\org.eclipse.osgi\bundles\898\1.cp\src\com\springsource\sts\grails\core\model\GrailsBuildConfig.java
// make sure that we use the Ivy dependency resolution strategy for Grails 1.2
// TODO CD make version number detection more flexible
if (settings.getGrailsVersion().startsWith("1.2")) {
jarFiles.addAll(settings.getTestDependencies());
jarFiles.addAll(settings.getProvidedDependencies());
Based on this find, I tried downgrading my project from Grails 1.3.2 to Grails 1.2 and ran "refresh dependencies". Sure enough, the dependencies were correctly loaded from Ivy.
Looks like someone needs to do the TODO. I can take a stab at it once I figure out how to check out the source code...
IntelliJ syncs dependencies between Grails (form application.properties and BuildConfig.groovy) and the IDE very nicely.
I am developing a Grails application along with a Grails plugin used by that application. In Intellij, I have defined two modules: one for the application, and one for the plugin. In my application's BuildConfig.groovy, I have defined the plugin dependency as a maven dependency, because when it is built/deployed to the production server, it should only refer to the latest 'released' version of the plugin. I override this dependency in my ~/.grails/settings.groovy file with my inline plugin location, so that I don't have to worry about accidentally committing my local development settings to the repository.
This works great when I use the built in grails commands to build/run/test, etc, but it has one fatal flaw: every time I do a clean, and periodically even when I don't, Intellij will read the application's BuildConfig.groovy file and remove the plugin module as a dependency for the grails app! This is extremely frustrating, as I have to then manually go to File -> Project Structure, select the application module, select the dependencies tab, and manually add the plugin's module dependency to it. Every. Single. Time.
Is there some way I can make Intellij leave my grails app's module dependencies alone, and trust that I know what I'm doing when I assign them? This is getting ridiculous!
I'm afraid that's a bug in IDEA. I've created a bug request for this issue: http://youtrack.jetbrains.net/issue/IDEA-56472. There you can find the way to temporarily fix this issue.