In gradle script I can do sourceSets.main.runtimeClasspath to get the runtime classpath. But in kts script it complains
Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
public val NamedDomainObjectContainer<Configuration>.runtimeClasspath: NamedDomainObjectProvider<Configuration> defined in org.gradle.kotlin.dsl
How can I do it in kts script?
It turns out that I need sourceSets["main"].runtimeClasspath . Not sure if it is the most idiomatic way
Related
I am getting the following error for the following war block in the build.gradle file:
war {
from file("${buildDir}/pad.checkpoint")
archiveBaseName = 'x'
archiveFileName 'x.war'
manifest {
attributes("Implementation-Title": "X",
"Implementation-Version": "${checkpoint_version}") //CHANGED: using checkpoint version, 4/29/2019
}
}
* What went wrong:
A problem occurred evaluating project ':x'.
> No signature of method: build_bwabkxkz50kzi9n1i5g4tpde.war() is applicable for argument types: (build_bwabkxkz50kzi9n1i5g4tpde$_run_closure7) values: [build_bwabkxkz50kzi9n1i5g4tpde$_run_closure7#459c6649]
Possible solutions: wait(), wait(long), tap(groovy.lang.Closure), run(), run(), any()
It was working before with the deprecated variables baseName and archiveName. I think it is happening because the war closure hasn't been set for receiving the new upgraded variables.
Spring boot version being used: springBootVers = '2.2.6.RELEASE'
Yeah, errors when using the Groovy DSL can sometimes be swallowed in these generic MissingMethodException" problems. It means that something inside the closure couldn't be resolved. I find that the easiest way to figure out what is wrong is to comment out code until the closure can be resolved.
In your case, it is the line archiveFileName 'x.war'. In groovy, parenthesis are (sometimes) optional, so this is equivalent to archiveFileName('x.war').
However, as you can see from the War API documentation, archiveBaseName is a property and not a method. So to fix it, change it to an assignment instead: archiveFileName = 'x.war'.
You will most likely not need both archiveBaseName and archiveFileName at the same time though.
I'm trying to use a Java library in my Kotlin project.
Creating variables in my project of types defined in the library works fine, e.g. val foo: Foo = fooProvider.get(), but introducing code that actually uses these types, e.g. foo.toString(), causes a compilation error:
Error:Kotlin: Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
class com.example.Foo, unresolved supertypes: ajcMightHaveAspect
From what I have found so far my example Foo type implements ajcMightHaveAspect which is some type of AspectJ interface.
aspectjrt is on my classpath but I cannot find ajcMightHaveAspect defined anywhere.
Is this a Kotlin compiler bug? Am I doing something wrong?
Problem was fixed in AspectJ.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=493554 for more details .
Hope it will help.
My groovy file contains:
#Grapes([
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7'),
#Grab('org.apache.httpcomponents:httpmime:4.5.1')
])
.......code
I am trying to compile groovy and java code. But I am getting below error:
java.lang.RuntimeException: Transform groovy.grape.GrabAnnotationTransformation#69bda33a cannot be run
This works for me, note that I did change HttpBuilder to v.0.7.1:
#Grapes([
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1'),
#Grab(group='org.apache.httpcomponents', module='httpmime', version='4.5.1')
])
Likely way too late for you to care, but I saw the same error just now.
I suspect the problem is that the #Grab annotation can't take effect because Maven is controlling the dependencies, or perhaps because Maven is trying to compile both Groovy and Java code, and the class loader created by the #Grab annotation can't influence the Java code.
Upshot is, I suspect you (and I) need to move the dependency out of the Groovy class in question, and put it into the pom.xml file Maven is using.
i am very new to gradle, i was trying to build a java file which is dependent on other jar file. It is building properly but when i try to execute it, it is giving "NoClassDefinitionFoundError".
my build.gradle file is:
apply plugin : 'java'
jar {
manifest {
attributes 'Main-Class': 'Hey'
}
}
dependencies
{
compile files('lib/BuildBasicJavaProject.jar') ------line A
}
if i remove the above line A then it is not even building the project.
if i keep that line A then it is building properly and producing the jar file, but when i execute it using ,
java -jar jarfilename.jar
then it is giving me a NoClassDefinitionFoundError.
Where do i need to specify the dependents path while running the jar file??
May be its a basic doubt but i wasted 2 days already in it, i tried giving
1) absolute path of the dependency file
2) adding the following line,
runtime files('lib/BuildBasicJavaProject.jar')
But did not succeed.
Thanks in advance
First welcome to Gradle world.
Your Gradle scripts seems to be correct. When you have a dependency, one jar depends on another like in your case at compile time you define compile time dependency like you did. So if you need this jar to run it you need runtime dependency, in your case. But Gradle automatically put all your compile time dependencies to be runtime dependencies. So you do not need to specify them explicitly.
So why then your code does not working?
The classpath (-cp) option is ignored if using the -jar option. So you can not specify dependent jar using -cp when type jar.So you have to write If you are on Windows
java -cp myJar.jar;.\lib\BuildBasicJavaProject.jar Hey
or use (:) and slashes(/) for Linux.
Where Hey is the full-quallified name of your main class, which have to be defind in the Manifest.
So if your class Hey is in the package:com.alabala.dev and it's name is Hey it's full qualified name is com.alabala.dev.Hey. So you have to tell Gradle
mainClassName = "com.alabala.dev.Hey"
So now Gradle put it in the manifest and when you are trying to load this jar in the JVM, she will know that to start it, she have to execute com.alabala.dev.Hey.
What is cp and why you have to specify it? Said with simple word cp is classpath - directories and archives in which JVM searches when want to load something. So here there is nothing linekd with Gradle it is Java.
You'll want to specify dependency jar(s) as a part of classpath, when you are executing your jar.
Something along these these lines:
java -cp myJar.jar:./lib/BuildBasicJavaProject.jar my.package.MyMainClass
Bare in mind that classpath delimiters are different on different platforms (: is for *nix based systems).
I have a simple use case of building an OSGi bundle using Gradle build tool. The build is successful if there are java files present in the build path, but it fails otherwise.
I am using 'osgi' plugin inside the gradle script and trying to build without any java files. The build always fails with following error:
Could not copy MANIFEST.MF to
I am sure there must be some way to do it in Gradle but not able to fine. Any idea what can be done to resolve this depending on your experience.
I ran into this today as well, and #Peter's fix didn't work for me (I hadn't applied the java plugin in the first place...). However, after hours of Googling I did find this thread, which helped me find the problem.
Basically, it seems that the error occurs (as Peter stated) when no class files are found in the jar - my guess is because the plugin then cannot scan the classes for package names on which to base all the Import and Export information.
My solution was to add the following to the manifest specification:
classesDir = theSourceSet.output.classesDir
classpath = theSourceSet.runtimeClasspath
In my actual build code, I loop over all source sets to create jar tasks for them, so then it looks like this:
sourceSets.each { ss ->
assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) {
from ss.output
into 'classes'
manifest = osgiManifest {
classesDir = ss.output.classesDir
classpath = ss.runtimeClasspath
// Other properties, like name and symbolicName, also set based on
// the name of the source set
}
baseName = ss.name
}
}
Running with --stacktrace indicates that the osgi plugin doesn't deal correctly with the case where both the osgi and the java plugins are applied, but no Java code is present. Removing the java plugin should solve the problem.
I had the same issue also when java code was present.
Adding these two lines to the osgiManifest closure fixed the problem:
classesDir = sourceSets.main.output.classesDir
classpath = sourceSets.main.runtimeClasspath
-- erik