I am trying to use an AspectJ Annotation that is in a Library, that I am pulling into my project. My project uses Gradle, so I am attempting to use FreeFair AspectJ Gradle Plugin.
I need to be able to set the AspectJ -aspectpath argument, to the Library Dependency that Gradle is pulling in.
FreeFair, does not seem to have much Documentation, mainly just Sample Code.
In their sample code, I see that I can use this to set the -aspectpath to a local "project":
aspect project(":aspectj:aspect")
Does anyone know how to set the -aspectpath to an external library dependency?
I created an example Project and put it on GitHub: freefair-aspectpath-external-library.
Note: I am using io.freefair.gradle:aspectj-plugin version 2.9.5 because my project is stuck using Gradle version 4.10.3.
Update: I have created a bug for this: https://github.com/freefair/gradle-plugins/issues/46
Thanks to #larsgrefer, who provided the answer in the GitHub Issue (46).
For the io.freefair.aspectj.compile-time-weaving plugin 2.9.5 the configuration is named "aspects" instead of "aspect".
The following fixed the issue:
aspects project(":aspectj:aspect")
The full build file resembles:
buildscript {
repositories {
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
// 2.9.5 for use with Gradle 4.10.3.
classpath "io.freefair.gradle:aspectj-plugin:2.9.5"
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: "io.freefair.aspectj.compile-time-weaving"
aspectj.version = '1.9.3'
group 'xyz.swatt'
version '1.0.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
}
dependencies {
///// SWATT ///// https://mvnrepository.com/artifact/xyz.swatt/swatt
compile group: 'xyz.swatt', name: 'swatt', version: '1.12.0'
aspect "xyz.swatt:swatt:1.12.0"
}
aspect is a plain old gradle configuration.
This means you can use all the notations described here:
https://docs.gradle.org/current/userguide/dependency_types.html#dependency_types
https://docs.gradle.org/current/userguide/declaring_dependencies.html
dependencies {
aspect project(":my-aspect")
aspect "com.example.foo:bar-aspect:1.0.0"
aspect file("foo.jar")
}
Related
I have a multi-module project with the following build.gradel files
core:
repositories {
mavenCentral()
}
dependencies {
providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
}
test-module:
dependencies {
implementation project(":core")
}
app:
repositories {
mavenCentral()
}
dependencies {
implementation project(":core")
implementation project(":test")
}
springBoot{
mainClassName = "com.yenovi.dev.Main"
}
and then the root :
buildscript {
repositories {
mavenCentral()
}
}
plugins {
id "io.spring.dependency-management" version "1.0.4.RELEASE"
id 'org.springframework.boot' version '2.3.3.RELEASE'
id 'war'
}
repositories {
mavenCentral()
}
subprojects {
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'idea'
apply plugin: "io.spring.dependency-management"
apply plugin: 'org.springframework.boot'
sourceCompatibility = 11
repositories {
mavenCentral()
}
dependencies {
compile 'org.springframework.boot:spring-boot-starter-web'
testImplementation('org.springframework.boot:spring-boot-starter-test') {
exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
}
}
}
The core module is supposed to represent the spring boot application, the test module provides extra functionality by creating a Service that is used in Core via dependency injection.
The app module has a main class that calls SpringApplication.run(Core.class, args);. I that app seems useless but at the end, this module will be replaced by separate projects that will use modules from this project.
The problem is that this way the compilation of test fails with an error saying that the package from core can not be found. After some googling I've found that applying the spring boot plugin to all modules causes this issue because it disables the jar task. However without that plugin, the build fails with an error that says that the spring boot starter web dependency can not be found but I need that in all my modules so I can use stuff like the #Service annotation.
How could I solve this?
In Gradle, if you don't specify a version number to the dependencies you use, they need to be supplied by something else. In your case, that something else is the io.spring.dependency-management plugin. However, it only knows about Spring Boot if you also have the org.springframework.boot plugin applied. So once you remove that, the dependency management plugin cannot supply versions for the dependencies anymore.
There are many ways to get around this. Here are the main ones I can think of. All are in Groovy DSL. I list each as a general case, so you will have to adapt it a bit for your project. More specifically, you should remove all plugins from the root (or set them to apply false) and add them to the relevant sub-projects instead. You also likely won't need the war and idea plugins.
(I personally prefer option B by the way.)
A. Use the Spring Dependency Management plugin in isolation
Have the Spring Boot plugin in the list, but don't apply it. This makes the plugin classes available on the project classpath so you can reference it. Then you can give the Spring Boot bom to the dependency management plugin:
plugins {
id 'org.springframework.boot' version '2.4.0' apply false // <- Apply false
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
dependencyManagement {
imports {
mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
}
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
}
See more here.
B. Don't use the Spring Dependency Management plugin
One of the strength of this plugin is if you are migrating from Maven as it mirrors the dependency management rules. There are also a few other features. However, if you are not using those features and are not migrating from Maven, you don't need it. Just use normal Gradle semantics:
plugins {
id 'org.springframework.boot' version '2.4.0' apply false // <- Apply false
id 'java'
}
dependencies {
implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
implementation 'org.springframework.boot:spring-boot-starter'
}
// OR:
plugins {
id 'java'
}
dependencies {
implementation platform("org.springframework.boot:spring-boot-dependencies:2.4.0")
implementation 'org.springframework.boot:spring-boot-starter'
}
C. Use both plugins, but disable the boot jar task.
The Spring Boot plugin disables the normal jar task, but you can just re-enable it. Because the jar file name is the same in both jar and bootJar, you can't have them both at the same time. So either also disable bootJar or give it a classifier. Here I have disabled it.
plugins {
id 'org.springframework.boot' version '2.4.0' // <- Apply true
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
}
jar {
enabled = true
}
bootJar {
enabled = false
}
See more here.
I apologize for the long answer. I got carried away :)
TL;DR Two gradle plugins use different versions of the same dependency, resulting in compile errors when one of the plugins is invoked.
The Situation
I have a Java project compiled using Gradle 4.x.
The project relies on two plugins: gradle-jaxb-plugin and serenity-gradle-plugin.
Both plugins share a dependency, guice.
The Problem
I need to upgrade one of the plugins (serenety). The upgrade results in a conflict at the point in which the jaxb plugin is invoked.
...
Caused by: java.lang.NoClassDefFoundError: com/google/inject/internal/util/$Maps
at com.google.inject.assistedinject.BindingCollector.<init>(BindingCollector.java:34)
at com.google.inject.assistedinject.FactoryModuleBuilder.<init>(FactoryModuleBuilder.java:206)
at org.openrepose.gradle.plugins.jaxb.schema.guice.DocSlurperModule.configure(DocSlurperModule.groovy:43)
...
I did some sleuthing and googling, and am fairly sure that the issue is rooted in the fact that the version of the serenity plugin uses guice 4.x when it used to use guice 3.x. The jaxb plugin uses guice 3.x.
The Question
How do I separate the plugin dependencies from one another? I would like to include both plugins, but it appears that gradle will take the highest dependency set and use that everywhere.
The Code
Here are the relevant portions of my build.gradle
buildscript {
repositories {
mavenCentral()
maven { url 'https://plugins.gradle.org/m2/' }
}
dependencies {
classpath 'gradle.plugin.org.openrepose:gradle-jaxb-plugin:2.4.1'
classpath 'net.serenity-bdd:serenity-gradle-plugin:1.5.1'
}
}
...
project(':integration-tests') {
apply plugin: 'java'
apply plugin: 'net.serenity-bdd.aggregator'
...
}
...
project(':cms-business-model') {
apply plugin: 'org.openrepose.gradle.plugins.jaxb'
apply plugin: 'java'
...
}
Note: You can replicate the issue by adding the serenity 1.5.1 plugin to the classpath dependencies block of the jaxb plugin examples
TL;DR: When Gradle plugins share a dependency but use different versions of that dependency only the highest version is actually used. You have to explicitly exclude the higher-dependency version.
The conflict here came because the jaxb plugin depends on guice:3.0 AND guice-assistedinject:3.0.
When serenity uses guice:4.0 there was a version mismatch between guice:4.0 and guice-assistedinject:3.0
The solution is to exclude the guice dependency from serenity, therefore falling back on guice:3.0
Updated Code
buildscript {
repositories {
mavenCentral()
maven { url 'https://plugins.gradle.org/m2/' }
}
dependencies {
classpath 'gradle.plugin.org.openrepose:gradle-jaxb-plugin:2.4.1'
classpath ('net.serenity-bdd:serenity-gradle-plugin:1.5.1') {
exclude group: 'com.google.inject', module:'guice'
}
}
}
...
Alternative Solution
Another possibility may have been to require guice-assistedinject:4.0, but the above worked so I didn't continue to explore.
When trying to build my java project using Gradle I get the following issue:
plugin with id 'sonar' not found
at the following line in my build.gradle:
apply plugin: 'sonar'
This was previously working with Gradle version 1.7 and Java 7, however I have now updated to these newer versions:
gradle : 3.4.1
Java: 1.8
What could be causing this and how could I solve it?
The sonar plugin was renamed to 'org.sonarqube'.
To use this plugin you need to add a dependency:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.2.1"
}
}
And then you can apply the plugin:
apply plugin: "org.sonarqube"
Also see the plugin page.
I'm using Dagger 2 with Gradle and have everything setup and code generation is working properly.
My build.gradle:
task wrapper(type: Wrapper) {
gradleVersion = '2.11'
}
subprojects {
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
... omitted as irrelevant to question ...
compile 'com.google.dagger:dagger:2.0.2'
compile 'com.google.dagger:dagger-compiler:2.0.2'
compile 'javax.inject:javax.inject:1'
}
}
My problem is that I am unable to resolve the classes and use them in my source, any solutions I've found are targeted towards Android which I am not using. How would I be able to resolve these generated classes as dependencies?
I had a similar issue some time ago. In your case I would say that you need the apt plugin. Check this question where I explained how I resolved it
I fixed this issue by enabled annotation processing in my IDE as well as adding Dr. Pelocho's answer.
Apply this answer: https://stackoverflow.com/a/33445767/1787084 to your build.gradle
Add apply plugin: 'eclipse' in your build.gradle
Enable annotation processing to the apt directory created by the ltgt gradle apt plugin in Eclipse by navigating to project properties -> Java compiler -> Annotation processing -> Enable project specific settings -> Enable annotation processing
Change generated source directory to build/generated/source/apt/main to match the ltgt default directory
Click "OK" or "Apply"
This added the Dagger generated classes to my build path and classpath
Is there a gradle plugin to package Java Webstart (JWS) applications, similar to what Maven webstart plugin does? I need to automate at least the following tasks:
jnlp descriptor generation based on an existing template, automatic adding project dependencies;
jar signing based on the files described on jnlp file or project dependencies;
As of Aug 2016, the answer is "no".
There is a plugin under development per #Jake's answer. But there is no turn key solution. You'll have to do the work yourself to create a webstart app in Gradle... either with your own custom solution or by contributing to the plugin mentioned until it works for you.
Here's the plugin direct link: https://github.com/tschulte/gradle-jnlp-plugin
Found the following link outside of Stack Overflow and looks like it does some of what you are looking for but not all. Hopefully this gets you closer to what you need...
This is an old post, but answering anyway.
I could configure gradle-jnlp-plugin.
Steps:
-Create an empty folder.
-Create src folder with Java code. I used the sample AccessibleScrollDemo.
-Copy keystore.ks from examples or create your own using genkey task in plug-in.
-Create build.gradle with following configuration.
The plug-in has examples of various options for jnlp task.
-Run plug-in task using gradle (v2.4 or more).
gradle createWebstartDir
-This will create the jnlp file under build directory, and also jars in build/lib.
build.gradle:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'de.gliderpilot.gradle.jnlp:gradle-jnlp-plugin:+'
}
}
plugins {
id 'java'
id 'eclipse'
id 'idea'
}
apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'maven'
apply plugin: 'groovy'
apply plugin: 'de.gliderpilot.jnlp'
group = 'misc'
sourceCompatibility = 1.6
targetCompatibility = 1.6
repositories {
mavenCentral()
}
mainClassName = 'misc.AccessibleScrollDemo'
sourceSets {
main.java.srcDir "src"
}
dependencies {
runtime('log4j:log4j:1.2.17') {
exclude group: 'ant', module: 'ant-nodeps'
exclude group: 'ant', module: 'ant-junit'
exclude group: 'ant-contrib', module: 'ant-contrib'
}
runtime 'org.slf4j:slf4j-log4j12:1.7.21'
testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
}
jnlp {
useVersions = false
usePack200 = false
withXml {
information {
title project.name
vendor project.group ?: project.name
}
security {
'all-permissions'()
}
}
signJarParams = [keystore: 'keystore.ks', alias: 'myalias', storepass: 'mystorepass']
}
compileGroovy.enabled = false
afterEvaluate {
// prevent ClassCastException
project.version = project.version.toString()
}
}
I think the Gradle JNLP Plugin currently registered in the Gradle Plugins directory may be the project for which you're looking.
Tobias Schulte's Gradle JNLP Plugin ( tschulte/gradle-jnlp-plugin on GitHub ) was striving for this about a year ago, but the new plugin is both registered in the Gradle Plugin site and looks to be under much more active development.