Is there a way to use the transitive dependency of some maven module instead using the default maven lib version?
For example:
My project has a dependency on qulice-maven-plugin, which depends on qulice-checkstyle, which depends on checkstyle libs. I want to to run checkstyle in my project, but using the same version and configuration which is loaded from these transitive dependencies.
If I run mvn checkstyle:checkstyle, which is the command for running checkstyle, it loads a default checkstyle version and uses its default configuration. I don't want to copy all my configurations from these dependencies, I just want to maven to be smart enough to execute checkstyle using the dependencies defined above.
Is there a way of doing this?
If I run mvn checkstyle:checkstyle it loads a default checkstyle version
If yours is loading version 6.18 then see https://stackoverflow.com/a/27359107/1016482 on how to override it to use a newer version.
run mvn checkstyle:checkstyle, which is the command for running checkstyle
If you want to fail the build when there is a checkstyle violation in your project, then this is not the command. As shown at https://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html , this will just generate a file report and not fail the build if there are checkstyle violations in your project.
For this purpose they recommend checkstyle:check and https://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html#Checking_for_Violations_as_Part_of_the_Build shows an example on how to configure the it for your custom parameters.
I don't want to copy all my configurations from these dependencies
You should be able to use the embedded configuration just like sun and google configurations which are embedded in checkstyle. Just add it as a dependency and specify the config location, like /my/path/my_config.xml from the root of the dependency like you would loading a resource.
Related
I have teamcity currently configured to use the maven mojo, to publish the gradle jar as a nexus snapshot with just the gav.
I observe that if i use the maven plugin and do a gradle install in the IDE, i am able to see the generated pom.
1) Can i use this pom to publish the jar in nexus repo in teamcity ? I know that i can do it for a pure maven build by using it's pom.
2) Is there a way to not use this pom, and istead configure teamcity build steps to publish from gradle build directly ?
Gradle can of course take care of the publication. It will leverage the build information to produce a POM file that represents best what is declared in your project.
It will then be trivial to invoke that Gradle task from the Teamcity build.
Have a look at the publishing documentation for details on how to set it up.
What is the exact dependency I need to develop a Gradle Plugin in Java? Ideally I would like to get it from a well-known repository such as Maven Central or similar.
I have a Maven project with a core functionality and I just added two extra plugins, one for Ant, one for Maven. They are already tested and working; easy! Now, I wanted to add a third module for a Gradle plugin to make this functionality also available from any Gradle project.
However, I can't find the exact dependencies I need to develop a Gradle plugin.
The Gradle docs (such as https://docs.gradle.org/current/userguide/java_gradle_plugin.html) are not very well written to say the least. They mention:
the gradleAPI() dependency
or the java-gradle-plugin dependency
But they are quite unclear... no group, no version (really?).
If anyone can enlighten me to where I can get these dependencies from, I would be very thankful.
Gradle's public and internal APIs, aka gradleApi(), are bundled with the Gradle distribution and not independently published and therefore not easily consumable by Maven builds. There's the pending epic #1156 (Ensure plugin cross-version compatibility by allowing a user to depend on gradlePublicApi()) that might help here.
Since Gradle plugins are best to be built with Gradle, a pragmatic solution is to invoke the Gradle build from Maven and attach the produced artifact to the Maven build. Andres Almiray (aalmiray) once described this in the blog post Running Gradle Inside Maven (Web Archive Link). He describes the following high level steps:
Create a new Maven module (e.g. gradle-plugin) and add attach it to the parent POM
In the POM of gradle-plugin add a dependency to your core module. Use the maven-dependency-plugin to store dependencies to the Maven build folder, e.g. target/dependencies.
Create the build.gradle, add a Maven repository that points to target/dependencies (step 2) and let it depend on the core module as well as gradleApi(). Implement the Gradle plugin.
Use the exec-maven-plugin to invoke the Gradle build.
Use the maven-resources-plugin to copy the Gradle built plugin jars to the standard Maven build folder.
Use the build-helper-maven-plugin to attach the copied jars to the Maven build.
Sample project to be found here (gradle-in-maven).
https://docs.gradle.org/current/userguide/custom_plugins.html#sec:custom_plugins_standalone_project
In here it is mentioned that it is gradleApi() and I know that this works (from experience). The localGroovy() on that page is only needed if your plugin code uses groovy (does not apply if you only use groovy in the build.gradle of your plugin).
java-gradle-plugin is a library that makes it a bit simpler to make plugins, it is not required though. I personally prefer using gradleApi only.
EDIT:
It appears I've misunderstood the question. Here are the steps to get gradleApi jar:
Create a Gradle project with your desired Gradle version.
Add implementation gradleApi() dependency.
Import/run the project once.
Go to your .gradle folder (located in home folder in Linux-based operating systems).
Open caches folder
Open the version folder you want, e.g. 6.0.1
Open generated-gradle-jars folder.
Copy the jar to wherever you want and use it.
For me the 6.0.1 jar is at ~/.gradle/caches/6.0.1/generated-gradle-jars/gradle-api-6.0.1.jar
Please note that I have not tested this, I know the jar is there but I haven't tried using it.
I have a standard spring-boot project with org.springframework.boot:spring-boot-gradle-plugin. i know i can override dependency version with e.g.
ext['slf4j.version'] = '1.7.5'
but how can i get the version currently imported by spring-boot plugin so i can use it later in the script? for example:
currentSlf4jVersion = xxx('slf4j.version')
The dependency management plugin that Spring Boot's plugin applies for you provides programmatic access to the properties in imported boms.
You can get the value of the slf4j.version property like this:
dependencyManagement.importedProperties['slf4j.version']
You can find your gradle project dependencies using command
gradle dependencies
For All:
gradle listAllDependencies
For sub-project:
gradle :<subproject>:dependencies
This will output dependencies
I have created a plugin for IntelliJ Idea. In the plugin I have defined an annotation I want to use in my projects, but it doesn't seem to be accessible.
How should I specify in the plugin.xml file the packages I want to expose?
When you install a plugin, it will be on a certain place - e.g. C:\Users\xxx\.IdeaIC14\config\plugins\...
Now that you know where your jar file is, you can add it as a dependency to your project. If you use Maven, you can add something like this to your pom:
<dependency>
<groupId>yourplugin</groupId>
<artifactId>yourplugin</artifactId>
<version>1</version>
<systemPath>C:\Users\xxx\.IdeaIC14\config\plugins\yourplugin.jar</systemPath>
<scope>system</scope>
</dependency>
Or you can install the jar into your local repository and then use it as normal maven dependency.
If not, then add the dependency directly in the project settings as it was any other jar.
plugin.xml has nothing to do with any of this, this is all about jars and classpath. What you could do in your plugin is some user friendly inspections and actions, which would add the dependency for you.
By default, plugins can automatically read and access public members of any other plugin installed on the same IDE (ie. your plugin can read public variables, call public functions - everything goes on the same classpath). If you depend on another plugin, you must first add it as an explicit dependency within the plugin configuration file, so that the end user's IDE will know to download and install your plugin's required plugin dependencies if they are missing.
During development, you should now be using Gradle. In your project's build.gradle (or build.gradle.kts) file, the intellij.plugins property of the gradle-intellij-plugin will let you specify the the id and version of the plugin dependency. The values for these attributes can be found on the Plugin Repository, cf. Plugin XML ID). Subsequently, the gradle-intellij-plugin will add the desired IntelliJ Platform Plugin to your project as an External Library, thereby allowing you to get code completion, static analysis and test your plugin alongside its dependencies inside the plugin sandbox (via ./gradlew runIde).
Plugins should avoid using other plugins' internal classes for stability reasons. If you wish to enable other plugins to use your plugin programmatically (ie. suppose you want to provide an API), then the IntelliJ Platform has the concept of so-called, Extension Points. These will allow you to define a concrete interface, or contract for other plugins to access the functionality of your plugin, without needing to know much about its source code. Using extension points has the added benefit of decoupling those plugins from any internal plugin refactoring.
Is there a proper way of doing this maybe through a command line? Or do I really have to modify the POM file itself? Let's say I want to install the maven war plugin into an existing project. I tried googling but I can only find the usage and not the installation to an existing project.
As documented here,
Maven is - at its heart - a plugin execution framework; all work is
done by plugins.
You must mean invoking or using a plugin than installing a plugin. You can invoke pretty much any maven plugin without updating the pom, so long as you are ok with the default configurations.
For instance, to generate a javadoc on a maven project, you could just type
mvn javadoc:javadoc
Now, coming to maven war plugin. This creates a war artifact of your project. It makes no sense to invoke it on a project, unless the project is a war project. If it is so, the packaging of the project should be war.
<packaging>war</packaging>
In this case, maven war plugin gets automatically invoked on it.
If you want to customize/configure a plugin or based on the type of plugin, you declare it in your pom (in <plugins> section and do the configurations).
You add the plugin to the POM.
Maven configuration is done via the POM; it's kind of the point--the POM defines the project.