wsdl2java using Axis 1.4 in Gradle - gradle

I searched for plugins and tutorials but neither of them worked in the given context:
I'd like to generate server-side Java classes from a list of given WSDL files. They have to be generated with Axis 1.4 and Java 1.7.
My half-working code is the following:
configurations {
axisGenAntTask
}
task genWsdlClasses() {
doLast {
def wsdlDir = file(axisInputDir)
def wsdlFiles = new FileNameByRegexFinder().getFileNames("${wsdlDir}", /.*\.wsdl/)
wsdlFiles.each { String wsdlFile ->
ant.echo(message: "Generating Classes for use with WSDL")
ant.taskdef(
name: "genClassesFromWSDL",
classname: "org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask",
classpath: configurations.axisGenAntTask.asPath
)
ant.genClassesFromWSDL(
url: wsdlFile,
output: file(cxfOutputDir)
)
}
}
}
tasks.withType(JavaCompile) {
dependsOn genWsdlClasses
}
dependencies {
axisGenAntTask "org.apache.axis:axis-ant:1.4",
"org.apache.axis:axis:1.4",
"org.apache.axis:axis-jaxrpc:1.4",
"axis:axis-wsdl4j:1.5.1",
"commons-codec:commons-codec:1.3",
"commons-logging:commons-logging:1.1.1",
"commons-discovery:commons-discovery:0.2"
}
However, a generated CustomException class doesn't extend Exception, thus it is not throwable and Java code compilation isn't working (see similar question here: Exception classes generated using Axis2 wsdl2java don't extend Exception).
Somehow I would just have to tell ant.taskdef not to "unpack" the classes, as I read in the referenced SO-question, but the mentioned arguments are from Axis 2, not from the needed Axis 1.4 though.

Related

gradle: how to create 2 jars with different java versions using Springboot bootJar task and java toolchain

springboot gradle plugin version: org.springframework.boot:spring-boot-gradle-plugin:2.7.2
I have defined different versions of Java for compilation and test as mentioned here but thats just for compile and test.
tasks.withType(JavaCompile).configureEach {
javaCompiler = javaToolchains.compilerFor {
languageVersion = JavaLanguageVersion.of(8)
}
}
task('testsOn14', type: Test) {
javaLauncher = javaToolchains.launcherFor {
languageVersion = JavaLanguageVersion.of(14)
}
}
Ref: https://docs.gradle.org/current/samples/sample_jvm_multi_project_with_toolchains.html
The jar task is defined simply as jar.dependsOn(bootJar)
I want this task to create 2 jars: myproject-j8.jar and myproject-j14.jar meaning one build with Java-8 and other with Java-14. No idea how to do that. Thanks for taking a look.

Configuring tasks via Gradle plugin using Kotlin DSL

I'm trying to convert some task configuration in my Gradle plugin from Groovy to Kotlin. All of the examples I've found are about normal build scripts, and that approach doesn't seem to directly translate to plugin usage. My attempt below:
class JavaConventionsPlugin : Plugin<Project> {
// ...
fun configureBasicJavaOptions(project: Project) {
project.tasks.withType<JavaCompile> {
options.encoding = "cp1252"
options.warning = false
}
}
}
produces these errors:
Type mismatch: inferred type is () -> Unit but Class<TypeVariable(S)!>! was expected
Unresolved reference: options
Variable expected
What the right way to do this?
I'm not sure if this is the way, but it seems to work:
private fun configureBasicJavaOptions(project: Project) {
project.tasks.withType(JavaCompile::class.java) { t ->
t.options.encoding = "cp1252"
t.options.isWarnings = false
}
}

Using Avro to java plugin in gradle kotlin dsl

I've a java project that is built using gradle kotlin dsl.
Now I want to use gradle-avro-plugin like this https://github.com/davidmc24/gradle-avro-plugin#alternate-usage
In kotlin dsl I have written the same logic as below -
plugins {
java
id( "com.github.davidmc24.gradle.plugin.avro") version "1.0.0"
}
dependencies {
implementation ("org.apache.avro", "avro", "1.10.1")
}
val generateAvro = tasks.register<com.github.davidmc24.gradle.plugin.avro.GenerateAvroJavaTask>("generateAvro") {
source("src/avro")
this.setOutputDir(file("dest/avro"))
}
configure<org.gradle.api.tasks.compile.JavaCompile> {
this.source = fileTree(generateAvro)
}
The above code is returning below error when I run grade compileJava-
> * What went wrong:
Extension of type 'JavaCompile' does not exist. Currently registered extension types: [ExtraPropertiesExtension, DefaultArtifactPublicationSet, SourceSetContainer, ReportingExtension, JavaPluginExtension, JavaInstallationRegistry, JavaToolchainService, DistributionContainer, JavaApplication, DefaultAvroExtension]
How can I fix this error?
I had similar issues, what worked for me was:
plugins {
id("com.github.davidmc24.gradle.plugin.avro") version "1.2.0"
}
dependencies {
implementation("org.apache.avro:avro:1.10.1")
}
tasks.withType<com.github.davidmc24.gradle.plugin.avro.GenerateAvroJavaTask> {
setOutputDir(file("src/dest/dir/"))
}
The important thing is I did not registered a new task, just specified a new destination directory for each task with the type GenerateAvroJavaTask

Gradle Kotlin DSL equivalent for Groovy DSL 'run'?

I am trying to build a simple JavaFX 11 program with Kotlin and Java 11, using Gradle, following the instructions here. However, this page uses Gradle's Groovy DSL, and I am trying to use the Kotlin DSL. Surprisingly, my Google searches have not turned up a document that maps each Groovy construct to its equivalent Kotlin construct or explains in general how to convert Groovy DSL code to equivalent Kotlin DSL code. (This seems like a big oversight in the Gradle documentation!).
In particular, this document contains the following Groovy code:
compileJava {
doFirst {
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.controls'
]
}
}
run {
doFirst {
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.controls'
]
}
}
As far as I can tell, the Kotlin equivalent to the first part appears to be:
tasks.withType<JavaCompile> {
options.compilerArgs.addAll(arrayOf(
"--module-path", classpath.asPath,
"--add-modules", "javafx.controls"
))
}
However, I have not been able to figure out what the Kotlin DSL equivalent to the second part is. Note that 'run' is a standard function extension in Kotlin's standard library, so it does not appear that the Kotlin version of this code can use the name 'run' for the same purpose in the Kotlin DSL.
(Note: I considered trying to use a plugin for the JavaFX support (as described by this page, for instance), but the plugin seems quite complicated to use, and I already am having enough problems with the number of complications in this project that I am hesitant to introduce a very-lightly-documented open-source plugin into the mix. I really am trying to produce the simplest possible "Hello, World" program in JavaFX/Gradle at the moment, and this has so far seemed surprisingly difficult.).
Any help would be appreciated.
Using the configuration avoidance APIs, the equivalent to the second block is:
tasks.named<JavaExec>("run") {
doFirst {
jvmArgs = listOf("--module-path", classpath.asPath,"--add-modules", "javafx.controls")
}
}
The key is that run has the JavaExec type, which like any task's type can be discovered by creating a task to print the class of the task that you then run:
tasks.register("getName") {
doFirst {
print("Class name: ${tasks["run"].javaClass}")
}
}
Note that as your JavaFX application grows, you will need to specify additional modules like this:
tasks.named<JavaExec>("run") {
doFirst {
jvmArgs = listOf("--module-path", classpath.asPath,
"--add-modules", "javafx.base,javafx.controls,javafx.graphics")
}
}
Surprisingly, my Google searches have not turned up a document that maps each Groovy construct to its equivalent Kotlin construct or explains in general how to convert Groovy DSL code to equivalent Kotlin DSL code.
Please have a look at https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/ and esp. the Configuring tasks section. According to that, I'd say the Kotlin DSL equivalent is
tasks.named<JavaExec>("run").doFirst {
jvmArgs = listOf('--module-path', classpath.asPath, '--add-modules', 'javafx.controls')
}
With Gradle 5.0 and kotlin-dsl 1.0, tasks that are registered or created by plugins can be statically accessed through the tasks container (TaskContainer. There is this example provided in the release notes:
plugins {
java
}
tasks {
named<Test>("test") {
testLogging.showStacktraces = true
}
}
you can now write:
plugins {
java
}
tasks {
test {
testLogging.showStacktraces = true
}
}
For your example, you are most likely using the application plugin, which registers the run task so you can configure it in a similar matter. One issue to be aware of is that run clashes with the Kotlin stdlib run method so you need to apply some workaround to make sure it gets invoked (see gradle/kotlin-dsl/issues/1175)
tasks {
compileJava {
doFirst {
jvmArgs = listOf("--module-path", classpath.asPath,
"--add-modules", "javafx.base,javafx.controls,javafx.graphics")
}
}
(run) {
doFirst {
jvmArgs = listOf(
"--module-path", classpath.asPath,
"--add-modules", "javafx.controls"
)
}
}
}
The other answers show how you can use the name, type, or combination to query the container for specific tasks.

Gradle: ear deploymentDescriptor - Exclude module from application.xml

I have the following in my gradle build file. My problem is that log4j.properties is being added as an ejb module in application.xml, despite my attempt to remove it from the xml per the thread here:
http://forums.gradle.org/gradle/topics/ear_plugin_inserts_unneeded_ejb_modules_in_the_application_xml_ear_descriptor
apply plugin: 'ear'
ear {
deploymentDescriptor {
applicationName = 'ourapp'
displayName = 'ourapp'
initializeInOrder = true
//This doesn't work:
withXml { xml ->
xml.asNode().module.removeAll { it.ejb.text.equals('log4j.properties') }
}
}
//Add log4j.properties to ear root
from('../../lib/log4j.properties', 'log4jProperties')
}
dependencies
{
deploy 'javax:javax.jnlp:1.2'
deploy 'com.oracle:ojdbc6:1.6.0'
earlib 'org.apache:apache-log4j:1.2.16'
}
How can I get the gradle to exclude log4j.properties from application.xml?
EDIT
This is causing a failure to start up in my application server (JBoss 6.0.0) because it doesn't know what to do with log4j.properties. I can work around it by manually creating my application.xml file, but that makes for another thing that has to be maintained. Any assistance would be welcome!
This code works for me. You need to protect the 'remove' method with an 'if' block because the closure is called multiple times. I found that the first time its called, log4jNode is set to 'null'.
withXml {
def log4jNode = asNode().module.find { it.ejb.text() == 'log4j.properties' }
if (log4jNode) {
asNode().remove( log4jNode )
}
}

Resources