I'm trying to convert an ant build file to Gradle and I was wondering if there exists a way to specify which packages should be in the javadoc in the same way 'packagenames' works in ant?
Thanks
Jonathan
See the 'includes'/'excludes' properties, or related methods. The patterns use the same syntax as ant.
javadoc {
exclude "**/internal/**"
}
As another example, if the build process generates Java source files into a build directory, the Javadocs can be generated using:
javadoc {
source = "$buildDir/"
include( "**/*.java" )
}
This ensures that only .java files are parsed. Note that the parentheses are optional.
Related
I'm running sonar scan with following versions:
ant v3.0.5
sonar v4.5.4
sonar-ant-task v2.3
My ant project contains 100+ submodules; about half of them have external libs, and half don't
In my ant build file, following sonar properties are set:
sonar.projectKey = com.foo:bar
sonar.projectName = foobar
sonar.projectVersion = ${build.version.major}.${build.version.minor}.${build.version.subminor}
sonar.sourceEncoding=UTF-8
sonar.language = java
sonar.sources = src
sonar.java.binaries = build/classes
sonar.java.libraries = build/dependency/*.jar
Initial problem with above is that for the modules that don't have external libs, it fails since there's no jar inside /build/dependency after compilation.
According to this archive link: http://sonarqube-archive.15.x6.nabble.com/Analysis-aborts-because-of-quot-No-files-nor-directories-matching-lib-jar-quot-td5035215.html
I should be able to change the libraries property to
sonar.java.libraries = build/dependency/*
But this did not work for the combination of app versions i listed above. Using only "*" results in class not found error so i don't even think it correctly grabs the dependency jar files.
Could anyone advise if i'm using incorrect combination of the versions, or if this have regressed?
My current workaround:
Keep the "*.jar" as default project property, and add individual module's libraries property to the empty folder for those that do not have dependency jar. e.g.
module1.sonar.projectName=module1
module1.sonar.projectBaseDir=modules/module1
module1.sonar.java.libraries=build/dependency
module2.sonar.projectName=module2
module2.sonar.projectBaseDir=modules/module2
module2.sonar.java.libraries=build/dependency
... x 50 more of these
Is there more elegant solution?
thanks,
Scott
sonar.java.libraries property is handled by the SonarQube Java plugin. Please provide its version and if it is not the latest try to update.
You're on the right track. The analysis of Java multi-module projects is only easy for Maven users. :-(
I previously posted this, but I think it's best if I rephrase the issue, as I've gotten no useful response from this or any of the other places I've tried to ask about this.
I'm attempting to use a couple of existing JAXB extensions while generating classes from XJC. This processing has been working fine for a long time in a Maven build, using the "cxf-xjc-plugin". I'm attempting to convert this build to Gradle, but I'm finding that all the other strategies besides the Maven build are failing with the same error, which is something like this:
Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin not a subtype
at com.sun.tools.xjc.Options.findServices(Options.java:957)
at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
at com.sun.tools.xjc.Options.parseArgument(Options.java:688)
at com.sun.tools.xjc.Options.parseArguments(Options.java:809)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
I can demonstrate this with a single simple Gradle build script. It doesn't require any source code or schemas to compile, the error happens while setting up the classpath.
Note that although the error here references the "Element Wrapper" plugin, if I remove that jar from the classpath, I get the same error, but instead referencing the other JAXB extension, the "Fluent API" extension. As far as I know, I'm referencing recent versions of both of these extensions, and recent versions of the XJC and related jars.
My current simple test case Gradle script is this (I'm calling it "testxjc.gradle"):
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'
sourceCompatibility = 1.7
targetCompatibility = 1.7
repositories {
maven { url "http://repo1.maven.org/maven2/" }
}
configurations {
jaxb
}
dependencies {
jaxb 'com.sun.xml.bind:jaxb-xjc:2.2.7'
jaxb "com.github.jaxb-xew-plugin:jaxb-xew-plugin:1.4"
jaxb "net.java.dev.jaxb2-commons:jaxb-fluent-api:2.1.8"
}
task processXSDs() << {
URLClassLoader loader = GroovyObject.class.classLoader;
configurations.jaxb.each { File file -> println file; loader.addURL(file.toURI().toURL()) }
ant.taskdef(name: 'xjc', classname: 'com.sun.tools.xjc.XJCTask',
classpath: configurations.jaxb.asPath)
ant.xjc(destdir: 'tmp', package: "com.att.sunlight.service.domain.serviceCallResults", extension: true) {
schema(dir: "src/main/resources/schema", includes: "serviceCallResults.xsd")
arg(value: "-Xxew")
arg(value: "-summary target/xew-summary.txt")
arg(value: "-instantiate lazy")
arg(value: "-Xfluent-api")
}
}
compileJava.dependsOn processXSDs
I run this with "gradle -b testxjc.gradle build --stacktrace"
I've also been able to demonstrate the same error by bypassing the Ant task and directly using the XJCFacade class. This requires having the required jars available to reference. Here is my current test script (change semicolons to colons in the classpath if you test this on Linux):
#! /bin/bash
java -classpath "lib/commons-beanutils-1.7.0.jar;lib/commons-lang-2.2.jar;lib/commons-logging-1.1.1.jar;lib/istack-commons-runtime-2.16.jar;lib/jaxb2-basics-runtime-0.6.5.jar;lib/jaxb2-basics-tools-0.6.5.jar;lib/jaxb-api-2.2.7.jar;lib/jaxb-core-2.2.7.jar;lib/jaxb-fluent-api-2.1.8.jar;lib/jaxb-xew-plugin-1.4.jar;lib/jaxb-xjc-2.2.7.jar" com.sun.tools.xjc.XJCFacade -extension
I've tested this on both Win7 and CentOS.
Update:
I now have a clue or two.
First, when I said I tested this on both Win7 and CentOS, I was referring to the shell script. Up to that point, I hadn't run the minimal Gradle build script on CentOS. When I ran this minimal Gradle build script on CentOS, it succeeded (which means, it complained about the missing schema). Besides different OSes, I have different versions of Gradle and Java on each box. I'm in the process of swapping those versions around to see what other clues I can find.
I also got a reply to the post I made to the "jaxb-dev" mailing list, where someone said that they've seen this symptom, and they think it might happen when multiple JAXB jars are found on the classpath, and some JAXB classes are loaded by one classloader, and other JAXB classes by another.
From this input, I suppose I should try running my minimal test with verbose classloading and see how they differ, but I'm not sure I'll be able to see what I need through all the noise that will produce.
I'm trying to Gradle-ize our build by using Gradle to execute the Ant build. I'm using the java plugin so I can set source/target and I'm using ant.importBuild 'build.xml'. When I execute Gradle, I get the error above. I understand that both Ant and Gradle have these targets/tasks in common: clean, jar, javadoc, test. One option is to change the Ant target names in build.xml, but I'm hoping there's an easier way as I have a lot of projects and build files. I found this "wrapper" solution (http://issues.gradle.org/browse/GRADLE-771), but this did not work for me. How can I solve this?
Your options are:
Do not apply the plugin to the same project that imports the Ant build.
Rename the conflicting targets in the Ant build script.
You can rename all the ant targets:
ant.importBuild('build.xml') { String oldTargetName ->
return 'ant_' + oldTargetName
}
I have several very big ant build.xml files.
Someone know tool or program for get all dependency jar files from build.xml ?
Please check How To Check Dependencies Between Jar Files?.
http://www.jboss.org/tattletale or jdepend could help in getting dependencies between jars.
If you want to extract dependencies from a given build.xml , one option is to write XML parser and process ant file. Not an easy task. Another option will be write a listener for each build task. If the task is javac then query its classpath.
With maven-assembly-plugin it's possible to package a project into a single jar w all the dependencies.
I have not used it by myself, but one-jar seems to do what you need. It also has an ant task and offers an ant example.