I have updated my IntelliJ and the gradle sync outputs a warning which affects my IDE autocomplete.
I have tried looking for this problem and I've tried some fixes with package versions or change from compile to implementation, but none have worked.
Here is my gradle part that seems to generate the error.
allprojects {
apply plugin: 'java'
apply plugin: 'scala'
group = 'com.adobe.platform.activation'
sourceCompatibility = 1.8
// Once we migrate to our own jenkins, this will be removed
String gitBranch = System.getenv("GIT_BRANCH")
if (gitBranch != null && gitBranch != "master") {
String version = version.toString()
int dashIndex = version.lastIndexOf('-')
String prefix = version.substring(0, dashIndex)
String suffix = version.substring(dashIndex + 1)
String newVersion = "$prefix-$gitBranch-$suffix"
.replace("/", "-")
.replace("_", "-")
setVersion(newVersion)
}
}
The warning looks like this.
Warning:<i><b>root project '....': Unable to build Scala project configuration</b>
Details: org.gradle.api.GradleException: Cannot infer Scala class path because no Scala library Jar was found. Does root project '...' declare dependency to scala-library? Searched classpath: file collection.</i>
Apparently, replacing allprojects with subprojects seems to fix the problem.
Somehow, the project wanted to set the scala library for the root of the project, which contains no code.
Related
I try to migrate my java8 spring project to java11. Now I get the following exception when I try to run it from eclipse:
Error occurred during initialization of boot layer
java.lang.module.ResolutionException: Modules java.activation and jakarta.activation export package javax.activation to module spring.boot.starter.web
Under Referenced Libraries I only found jakarta.activation-api-1.2.2.jar which exports the package javax.activation. The other module java.activation I have no clue where it comes from. From the name it should be inside JavaSE-11/JDK ? I checked the entry JRE System Library but I don't see that package there.
Now the curios thing is with Gradle 6.5 I can run the project using "gradlew bootRun" and it executes nicely. However in eclipse it fails with the errror.
So in eclipse I just tried to remove Jakarta.activation by Right-click remove from build path. Trying to import anything from javax.activation then gives me "import can't be resolved", fine so far. However running still complains with the above ResolutionException.
So to fix the issue:
Where is the other sourcecode that exports javax.activation package? And how do I find that?
How can I prevent eclipse from having those two modules at runtime?
Can I exclude the module in gradle, such that the project works after running "gradlew eclipse" like always?
Thanks for your help! I spent hours searching and didn't find anything useful so far.
The build.gradle looks as following:
plugins {
id 'org.springframework.boot' version '2.2.5.RELEASE'
id 'io.spring.dependency-management' version '1.0.8.RELEASE'
id 'java'
id 'eclipse'
}
group = 'example'
version = '0.3.0'
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
repositories {
mavenCentral()
}
configurations.all {
// fix multiple slf4j dependencies are present
exclude group: 'org.slf4j', module: 'slf4j-log4j12'
//TODO: 1st approach to fix ResolutionException
//exclude group: 'jakarta.activation', module: 'jakarta.activation-api'
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf:2.3.1.RELEASE'
implementation ('org.springframework.boot:spring-boot-starter-web:2.3.1.RELEASE') {
//TODO: 2nd approach to fix ResolutionException
exclude group: 'jakarta.activation', module: 'jakarta.activation-api'
}
implementation 'org.springframework.boot:spring-boot-starter-security:2.3.1.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-data-jpa:2.3.1.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-actuator:2.3.1.RELEASE'
implementation 'mysql:mysql-connector-java:5.1.46'
implementation 'com.querydsl:querydsl-jpa:4.1.4'
implementation 'com.querydsl:querydsl-apt:4.1.4:jpa'
implementation 'com.google.code.gson:gson:2.8.5'
implementation 'org.flywaydb:flyway-core:5.2.4'
compileOnly 'org.springframework.boot:spring-boot-devtools:2.3.1.RELEASE'
// https://mvnrepository.com/artifact/org.apache.odftoolkit/simple-odf
implementation 'org.apache.odftoolkit:simple-odf:0.8.2-incubating'
// https://mvnrepository.com/artifact/org.apache.commons/commons-text
implementation 'org.apache.commons:commons-text:1.1'
// https://mvnrepository.com/artifact/org.apache.commons/commons-lang3
implementation 'org.apache.commons:commons-lang3:3.7'
// https://mvnrepository.com/artifact/org.apache.commons/commons-csv
implementation 'org.apache.commons:commons-csv:1.5'
// https://mvnrepository.com/artifact/org.apache.commons/commons-collections4/4.3
implementation 'org.apache.commons:commons-collections4:4.3'
implementation 'javax.validation:validation-api:2.0.0.Final'
// Dependencies that are no longer in java11
// implementation 'javax.xml.bind:jaxb-api:2.3.0'
// implementation 'com.sun.xml.bind:jaxb-core:2.3.0'
// implementation 'com.sun.xml.bind:jaxb-impl:2.3.0'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.5.2'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.5.2'
testRuntimeOnly 'org.junit.vintage:junit-vintage-engine:5.5.2'
}
eclipse {
classpath {
downloadJavadoc = true
downloadSources = true
}
}
Other links I found but didn't help me so far:
https://dba-presents.com/index.php/jvm/java/159-error-java-module-xyz-reads-package-org-apache-commons-logging-from-both-commons-logging-and-jcl-over-slf4j
Modules A and B export package some.package to module C in Java 9
Two Modules exports the same package (Spring)
https://forum.byte-welt.net/t/resolutionexception-module-a-module-b-to-module-c/20843/2
Ok I found part of an answer while trying to create an example to reproduce the issue.
First I tried to clean the project to make sure nothing bad is cached in eclipse:
gradlew clean eclipse
Still the problem occured.
Now I went full ham and removed all build files, .project, .classpath and reran gradlew eclipse and while adding a new run configuration the project now starts fine.
So probably blame the cache of the run-configuration.
Maybe this or the cross-links to other posts about the same issue still helps someone.
I am trying to setup a multi-project setup with gradle and trying to generate eclipse projects with eclipse IDE plugin.
Below is my structure.
rootDir/
|---buildSrc/
|---src/
|---main/
|---gradle/
|---eclipse.gradle.kts
|---build.gradle.kts
|---app/
|---build.gradle.kts
|---models/
|---build.gradle.kts
|---services/
|---build.gradle.kts
|---build.gradle.kts
|---settings.gradle.kts
Below are the contents of specific files, e.g. settings.gradle.kts and build.gradle.kts
settings.gradle.kts
rootProject.name = "platform"
include("app", "models", "services")
rootDir/build.gradle.kts
...
val buildSrc by extra("$rootDir/buildSrc")
configure(subprojects) {
apply(from = "$buildSrc/src/main/gradle/eclipse.gradle.kts")
}
rootDir/buildSrc/src/main/gradle/eclipse.gradle.kts
plugins {
eclipse
}
eclipse {
project {
println("Running inside eclipse closure for $name")
}
}
When I run ./gradlew I am getting below error:
Expression 'eclipse' cannot be invoked as a function. The function 'invoke()' is not found
FAILURE: Build failed with an exception.
* Where:
Script 'D:\work\sources\repos\platform\buildSrc\src\main\gradle\eclipse.gradle.kts' line: 5
* What went wrong:
Script compilation errors:
Line 5: eclipse {
^ Expression 'eclipse' cannot be invoked as a function. The function 'invoke()' is not found
Line 5: eclipse {
^ Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
public val PluginDependenciesSpec.eclipse: PluginDependencySpec defined in org.gradle.kotlin.dsl
Line 6: project {
^ Type mismatch: inferred type is () -> Unit but String! was expected
3 errors
However, when I do below changes, it works without errors
rootDir/buildSrc/src/main/gradle/eclipse.gradle replace eclipse.gradle.kts file with eclipse.gradle and make changes as per groovy DSL
apply plugin: 'eclipse'
eclipse {
project {
println("Running inside eclipse closure for $name")
}
}
refer correct file in rootDir/build.gradle.kts
...
val buildSrc by extra("$rootDir/buildSrc")
configure(subprojects) {
apply(from = "$buildSrc/src/main/gradle/eclipse.gradle")
}
Is having a kotlin file in gradle directory in rootDir/buildSrc/src/main/gradle (the custom script plugin) causing this issue? If so, is there any way to write a custom script plugin - not binary plugin - in kotlin dsl?
I have tried putting kotlin script in rootDir/buildSrc/src/main/kotlin/eclipse.gradle.kts but this does not helps.
Any help would be appreciable.
Struggling to get Kotlin running on eclipse.
I've started new graddle project. Added dependencies as prescribed on kotlin's site.
Build passes without errors.
I've created 'main.kt' file under src/java/main with:
fun main(args: Array<String>) {
println("foo")
}
BUT, I have two problems:
1. anything from kotlin e.g. println highlighted as 'unresolved reference'.
2. I can't run a program - Error: Could not find or load main class MainKt (rightclick on main.kr run as 'kotlin application')
If I create 'new kotlin project' everything works.
my graddle build script:
plugins {
id "org.jetbrains.kotlin.jvm" version "1.1.2-2"
}
repositories {
jcenter()
mavenCentral()
}
dependencies {
//api 'org.apache.commons:commons-math3:3.6.1'
implementation 'com.google.guava:guava:21.0'
testImplementation 'junit:junit:4.12'
compile "org.jetbrains.kotlin:kotlin-stdlib:1.1.2-2"
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8"
compile "org.jetbrains.kotlin:kotlin-reflect"
testCompile "org.jetbrains.kotlin:kotlin-test"
testCompile "org.jetbrains.kotlin:kotlin-test-junit"
}
sourceSets {
main.java.srcDirs = ['src/main/java']
main.kotlin.srcDirs = ['src/main/java', 'src/main/kotlin']
main.resources.srcDirs = ['src/main/resources']
}
What did I do wrong?
I've zero Java knowledge if that helps, so probably I've made some trivial error.
UPDATE:
Installed a Spring plugin and generated a new web app via it including gradle.
But Kotlin behaves unpredictably there too.
At first I was not able to run it as run as Kotlin application and it errored with main could not be found, BUT sometimes it run and crashed immediately. It started to launch and crash after I've deleted and edited classes, tried creating it under other package, removing and adding Kotlin (I can't reproduce sequence to make it work again).
Fun part that gradle boot build launches everything and all works it somehow finds Kotlin's main.
Probably some issue with Kotlin plugin itself (it's load probably depends on certain events that doesn't always fire)
Add the following to your configuration:
apply plugin: 'eclipse'
eclipse {
classpath {
containers 'org.jetbrains.kotlin.core.KOTLIN_CONTAINER'
}
}
See https://gitlab.com/frnck/kotlin-gradle-eclipse for a working configuration.
I'd like to add to frnck answer that this is only part of the solution. I also had to add these lines:
eclipse.project {
buildCommand 'org.jetbrains.kotlin.ui.kotlinBuilder'
natures 'org.jetbrains.kotlin.core.kotlinNature'
natures 'org.eclipse.jdt.core.javanature'
linkedResource name: 'kotlin_bin', type: '2', locationUri: 'org.jetbrains.kotlin.core.filesystem:/aio/kotlin_bin'
}
For Eclipse 2018-12 and kotlin 1.3 the solution was a combination of other answers plus some additional settings file:
eclipse {
classpath {
//Adds the kotlin container to the classpath
containers 'org.jetbrains.kotlin.core.KOTLIN_CONTAINER'
//Fixes the right output path
defaultOutputDir = file('bin')
//Make all src folders output in the same output folder (default)
file {
whenMerged {
// use default Output for all source-folders. see also defaultOutputDir per project
entries.each { source ->
// only Source-folders in the project starting with '/' are project-references
if (source.kind == 'src' && !source.path.startsWith('/')) {
source.output = null
}
}
}
}
}
project{
buildCommand 'org.jetbrains.kotlin.ui.kotlinBuilder'
//Fixes the natures
natures 'org.jetbrains.kotlin.core.kotlinNature'
natures 'org.eclipse.jdt.core.javanature'
//Links the kotlin_bin folder (generated class files)
linkedResource name: 'kotlin_bin', type: '2', locationUri: "org.jetbrains.kotlin.core.filesystem:/${project.name}/kotlin_bin".toString()
file{
whenMerged{
def kotlinPrefs = file('.settings/org.jetbrains.kotlin.core.prefs')
def jdkHome = System.properties.'java.home'
if(!(jdkHome)){
throw new GradleException('No JDK home available for setting up Eclipse Kotlin plugin, setup env "java.home" or update this script.')
}
kotlinPrefs.write """\
codeStyle/codeStyleId=KOTLIN_OFFICIAL
codeStyle/globalsOverridden=true
compilerPlugins/jpa/active=true
compilerPlugins/no-arg/active=true
compilerPlugins/spring/active=true
eclipse.preferences.version=1
globalsOverridden=true
jdkHome=$jdkHome
""".stripIndent()
}
}
}
}
I would like to add to Felipe Nascimento's answer that the location of the .settings folder does not yet exist. It works when the line below is inserted into that answer.
def kotlinPrefs = file("../${project.name}/.settings/org.jetbrains.kotlin.core.prefs".toString())
I have found that the JAVA_HOME environment variable that is set when your run this task ;
gradle cleanEclipse eclipse
is the one that is included in the Eclipse BuildPath
I have come across Spring.io's plugin. Initially it seemed great.
I have defined the following in my root build.gradle file
allprojects {
apply plugin: 'maven'
apply plugin: 'propdeps'
apply plugin: 'propdeps-maven'
apply plugin: 'propdeps-idea'
...
configurations.provided.transitive = true
configurations.provided.visible = true
}
I have one sub-module (lets call it sub1) that has the following definition:
dependencies {
provided(group: 'org.apache.hadoop', name: 'hadoop-core', version:'1.2.0') {
exclude(module: 'slf4j-log4j12')
exclude(module: 'log4j')
}
...
}
And a second sub-module (lets call it sub2) that is dependent on the first such:
dependencies {
compile project(':sub1')
...
}
when I invoke the clean build tasks of sub2 I get the following error:
/.../.../.../blahblah.java:12: error: package org.apache.hadoop.conf
does not exist import org.apache.hadoop.conf.Configuration;
The missing import exists in the jar specified in the provided scope in the build file of sub1
I had thought that setting the following:
configurations.provided.transitive = true
configurations.provided.visible = true
would do the trick (Note: it doesn't work with any value to these props).
Is the plugin "broken" or am I using it wrong?
A provided dependency is a compile dependency that is not transitive. Hence it's no surprise that sub1's provided dependency won't end up on sub2's compile class path. To fix this, you'll need to declare the dependency both for sub1 and sub2 (e.g. by declaring it under subprojects {} in the root build script).
I have a Gradle project which leverages AOP (from Spring 3.x.x) which I have imported into Eclipse (STS). When I use the Gradle's context menu to refresh dependencies/rebuild source I then have to convert to a AspectJ project in able for me to run my tests correctly (the AspectJ Runtime library isn't on the build path to fulfill the factory-method in the bean definition). I don't have the spring-aspects.jar located anywhere and this deploys to Tomcat without issue (again no aspectJ in the libs/ folder).
<bean id="fooBarAspect" class="foo.Bar" factory-method="aspectOf" >
This process works but is painful as it makes me rebuild twice anytime I need to refresh dependencies and run integration tests.
dependencies {
ajc 'org.aspectj:aspectjtools:1.7.3'
aspects 'org.springframework:spring-aspects:3.2.4.RELEASE'
compile (
'org.aspectj:aspectjrt:1.7.3'
)
}
Thoughts?
For AspectJ:
apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'eclipse'
apply plugin: 'eclipse-wtp'
ext.aspectjVersion = '1.7.4'
configurations {
ajc
aspects
aspectCompile
ajInpath
compile {
extendsFrom aspects
}
}
compileJava {
sourceCompatibility="1.7"
targetCompatibility="1.7"
doLast{
ant.taskdef( resource:"org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties", classpath: configurations.ajc.asPath)
ant.iajc(
source:sourceCompatibility,
target:targetCompatibility,
destDir:sourceSets.main.output.classesDir.absolutePath,
maxmem: "512m",
fork: "true",
inpath: configurations.ajInpath.asPath,
aspectPath:configurations.aspects.asPath,
sourceRootCopyFilter:"**/.svn/*,**/*.java",
classpath:"${configurations.compile.asPath};${configurations.aspectCompile.asPath}"){
sourceroots{
sourceSets.main.java.srcDirs.each{
pathelement(location:it.absolutePath)
}
}
}
}
}
dependencies {
ajc "org.aspectj:aspectjtools:1.7.3"
compile "org.aspectj:aspectjrt:1.7.3"
aspects group: 'org.springframework', name: 'spring-aspects', version: springVersion
aspectCompile group: 'org.hibernate.javax.persistence', name: 'hibernate-jpa-2.0-api', version: '1.0.0.Final'
aspectCompile group: 'org.springframework', name: 'spring-tx', version: springVersion
aspectCompile group: 'org.springframework', name: 'spring-orm', version: springVersion
}
For Eclipse we have to do bit a manual code:
eclipseClasspath {
withXml { xmlProvider ->
def classpath = xmlProvider.asNode()
def parser = new XmlParser()
classpath.classpathentry.findAll{ entry ->
entry.#kind == 'var' && configurations.runtime.find {entry.#path.endsWith(it.name) && !entry.#path.contains('servlet-api')
}.each { entry ->
def attrs = entry.attributes ?: parser.createNode(entry, 'attributes', [:])
parser.createNode(attrs, 'attribute', [name: 'org.eclipse.jst.component.dependency', value: '../'])
}
}
}
The problem is imo, that the project in eclipse must be marked as aspectj project in order to use the ajc compiler instead of the "normal" compiler. How did you declare the aspectj compilation in your build.gradle file? just adding the aspectj-rt to the compile classpath is definitely not enough.
You can manipulate the eclipse project configuration on xml level using gradle. I did this a long time ago using the withXml hook. have a look at the build.gradle file at
https://github.com/breskeby/gradleplugins/blob/0.9-upgrade/aspectjPlugin/aspectJ.gradle#L29
The way the aspectj eclipse plugin works might be outdated and you probably update it to fit your needs, but you should get the idea.