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.
Related
What are the difference between this three Kotlin plugin and what they actually do?
plugins {
id 'kotlin-android'
id 'org.jetbrains.kotlin.android'
id "org.jetbrains.kotlin.jvm" version "1.6.20"
}
The third one seems to be the recommended way specially when using Kotlin Coroutines
These plugins provide integration with different other Gradle plugins. They both setup compiling Kotlin for the JVM, but aim to interoperate with different other tools.
org.jetbrains.kotlin.android or kotlin-android
This plugin offers integration of Kotlin with the Android Gradle plugin, which should also be applied to the project. The Kotlin compilations are set up to be included in the builds of Android variants (e.g. debug, release, testDebug etc.)
The IDs kotlin-android and org.jetbrains.kotlin.android designate the same Gradle plugin. The only difference is that the "full" ID org.jetbrains.kotlin.android can be used for resolving the plugin from the Gradle Plugin Portal, while the shorter ID kotlin-android can only be used for applying the plugin if you already have it on the build classpath (i.e. it's added elsewhere).
org.jetbrains.kotlin.jvm (also has a shorter alias kotlin)
This is the plugin for building Kotlin projects that target JVM without Android support.
The plugin offers integration with the Gradle java plugin (as well as java-library or application). The project that applies this plugin can also use Java sources. The Kotlin compilations are wired with the java plugin's source sets (main and test by default)
Normally you should only apply one of these plugins, depending on whether you target Android or "standard" JVM. If you need to target both platforms, you should use the Kotlin Multiplatform plugin by ID org.jetbrains.kotlin.multiplatform, which adds the DSL to setup the targets in the project. Those might include jvm() and android(), as well as other targets: JS, WASM, Kotlin/Native.
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'm working on a multi-project (multi-module) Maven project that uses a non-standard DSL compiler. It uses a Maven plugin that runs during Maven's compile phase, for just one project in the set.
I tried importing my code as a "Maven" project in IntelliJ IDEA, but IntelliJ doesn't seem to recognize that I have a custom compiler for my project; the compile fails.
What I want is to tell IntelliJ, "You can use your normal Java compiler to Make most projects, but for this one project, you should invoke Maven and let it do its thing."
Is that possible?
I am developing an Eclipse plugin and I use maven to coordinate my source structure. In order to compile the plugin I use the tycho extension for maven. However, I was wondering how to execute unitests.
I want to use the surefire plugin for testing as I additionally use a sonar server for source code quality management. Unitests are applyed if I use eclipse-test-plugin as package target. However, I want to make use of the default surefire plugin for applying unitests.
Now I figured out that the src/test/java that contains my unittest packages is read and compiled correctly but written into the wrong output folder. I need to have the tests in target/test-classes. However they are compiled to target/classes.
As I am new to Eclipse plugin development and maven I could not find out how to write the tests to the correct output folder. I've already tried adding and and changing the build.properties of the eclipse-plugin project. It works also fine for other projects that aren't plugin projects and do not make use of tycho.
Any help appreciated.
Regards,
Florian
Unlike standard maven projects, the convention for eclipse plugins/OSGi bundles is to have tests reside in separate projects. This is because there is no such thing as a maven dependency scope "test" in OSGi.
Thus keeping your tests inside the same project as your code under test would force you to mix up test code/dependencies an productive code/dependencies.
As you mentioned, Tycho provides a separate maven packaging type "eclipse-test-plugin" which you should use for dedicated test plugins/fragments. See https://docs.sonatype.org/display/TYCHO/PackagingTypes
There is no support in Tycho for plain unit tests residing in the same project.
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.