Hello there Gradle gurus!
I'm seeking for your mighty experience and knowledge :)
I have a Gradle plugin that hooks a Jacoco agent to the jvm. Currently my code looks like this:
Task t = project.allTasks.getByPath(project.getName+":"+"test");
t.jvmArgs = ["-javaagent:"+jacocoAgentJar+"=destfile=" + coverageResultFile.getCanonicalPath()];
This is working fine but since dynamic properties are deprecated I want to somehow get rid of them. However... changing the code to t.ext.jvmArgs = ["-javaagent:"+jacocoAgentJar+"=destfile=" + coverageResultFile.getCanonicalPath()]; doesnt work.
Could someone please explain to me how am I supposed to hook the Jacoco agent to the jvm withought using this dynamic property?
Thanks
If you get a "dynamic properties" warning here, there is likely something wrong with your code, and it's not just a style issue. For one thing, the use of getAllTasks (which, by the way, takes a boolean parameter) is inappropriate here. Instead, you should use project.tasks.getByName("test"), which can be abbreviated to project.tasks["test"] or even project.test. Or, if you want to catch all test tasks, project.tasks.withType(Test).
you can configure directly the test task in the build file adding a configuration closure like this:
test{
jvmArgs "javaagent:"+jacocoAgentJar+"=destfile=" + overageResultFile.getCanonicalPath()"
}
Not a direct answer to your question, but you may want to look into the gradle-jacoco plugin.
Related
We recently updated to JDK 11 and the javadoc team has seen fit to remove frame generation from the javadocs in favor of a search box. Our community is comprised heavily of students who don't know what keywords to search for, but who can browse a sidebar and find what they need. For them a search box is useless. They require discovery through browsing. For that reason, we would like to turn frames back on by adding the --frames option to the javadoc task, and then we'll just never move off of JDK 11.
We are using Gradle 7.4.2 and there doesn't appear to be a method exposing the --frames option in the StandardJavadocDocletOptions class.
If the options section of my Javadoc task looks like this:
options.memberLevel = JavadocMemberLevel.PROTECTED
options.links "https://developer.android.com/references"
options.encoding = 'UTF-8'
Then I see those options in gradle's generated options file.
Adding...
options.setStringOption('-frames')
...does not result in any new option appearing in the generated options file. To be honest I have no idea what setStringOption() without the second string parameter actually does.
Adding...
options.setStringOption('-frames', '')
... results in --frames '' appearing on the generated options file, but that confuses javadoc.
I don't see anything in the Gradle documentation that indicates how one might add simply '--frames' to the command line of the javadoc executable. Or any other option that javadoc might expose, but the gradle version one is sitting on does not expose for that matter.
To set flags use addBooleanOption()
// build.gradle.kts
tasks.javadoc {
options {
require(this is StandardJavadocDocletOptions) // workaround https://github.com/gradle/gradle/issues/7038
addBooleanOption("frames", true)
}
}
Note that the Kotlin DSL requires a workaround https://github.com/gradle/gradle/issues/7038#issuecomment-448294937
I'm using spring-restdocs to generate docs.
I'm wondering if any property to fail the asciidoctor task while getting similar warnings when building the doc.
Snippet http-response not found at ../../../build/generated-snippets/find-list-configuration-fixed-assets-source-response/http-response.adoc for operation find-list-configuration-fixed-assets-source-response
Snippet path-parameters not found at ../../../build/generated-snippets/update-currency/path-parameters.adoc for operation update-currency
Unfortunately, this is not possible. There is an open issue https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/154 since 2015. If you read through this issue you will find a workaround. Maybe it will help you. :-)
This is possible starting with asciidoctor 2.0, by configuring the fatalWarnings option of asciidoctorj.
Documentation of fatalWarnings:
Patterns for AsciidoctorJ log messages that should be treated as fatal errors. The list is empty be default. Use setFatalWarnings to clear any existing patterns or to decouple a task’s configuration from the global configuration. Use fatalWarnings to add more patterns. Pass missingIncludes() to add the common use-case of missing include files.
Example:
asciidoctor {
asciidoctorj {
fatalWarnings missingIncludes()
}
}
I am not using the new maven-publish plugin which looks awesome and would work perfectly for this use case because I keep reading how no one can get the signing of the jars to work (though I am open to an answer that explains that as well as I haven't found a blog on that saying it would work at this point).
Soooo, I would like easily to switch between publishing locally for testing and remotely. My current build.gradle file is
https://github.com/deanhiller/webpieces/blob/master/build.gradle
which has a commented out local repo and I keep flipping commenting on and off and would rather like to avoid that. ie. these repos...
//repository(url: "file://localhost/tmp/myRepo/")
repository(url: "https://oss.sonatype.org/service/local/staging/deploy/maven2/") {
authentication(userName: sonatypeUsername, password: sonatypePassword)
}
I read a post on doing something here but this failed with cryptic closure errors...
Configuring multiple upload repositories in Gradle build
I put that in my subprojects section but that didn't work at all. Ideally, using the graph whenReady sounds the best as it would be cool to only use remote repo if I am doing the release target. I can't seem to get any of this to work though.
thanks,
Dean
EDIT: I was wrong, the below is only half working right now as when I ./gradlew jar, then I get this error... (so some targets work and others not...ouch)
Cannot cast object 'task ':uploadArchives'' with class 'org.gradle.api.DefaultTask_Decorated' to class 'org.gradle.api.tasks.Upload'
I did figure out a work around though it seems weird as targets in running tasks list are hidden now depending on if a variable is set which seems a little odd. I would think there is probably a better way of doing this so all tasks are still listed, but for now my build file works by just doing a
if(project.hasProperty('projVersion')) {
//task I want to be able to run
} else {
//other task I want to run when no projVersion
}
so it works...the tasks are just invisible now until I do ./gradlew -PprojVersion=X to view them.
I know this is subjective question and it will be closed most probably. But I don't know where to ask this question to get answer.
There is one small annoying thing with maven android plugin - it modifies original manifest file and if you are running maven in working folder your vcs is proposing you to commit these changes.
Example: we have several environments to run if I build build with beta environment it will modify app name in AndroidManifest.xml.
This is could be easily solved by copying original manifest and give reference to the copy to the android maven plugin. But I've decided to make it's more easy for developer so plugin will do this automatically except situation when developer specifies that he wants this update to be done under original manifest.
It was easy to modify functionality (copy file and replace property that keeps reference to the File) but the problem is that I need to pass this property to other mojos.
The property defined in abstract mojo AbstractAndroidMojo which doesn't have execute method. And all other mojos extend this class. The definition look like this:
/**
* The <code>AndroidManifest.xml</code> file.
*
* #parameter default-value="${project.basedir}/AndroidManifest.xml"
*/
protected File androidManifestFile;
I followed this answer:
private void updatePluginConfiguration ( String newManifestFileValue )
{
for ( Plugin plugin : project.getBuild().getPlugins() )
{
if ( plugin.getArtifactId().equals( "android-maven-plugin" ) )
{
Xpp3Dom configuration = (Xpp3Dom) plugin.getConfiguration();
Xpp3Dom manifestFileParameter = configuration.getChild( "androidManifestFile" );
if ( manifestFileParameter == null )
{
manifestFileParameter = new Xpp3Dom( "androidManifestFile" );
configuration.addChild( manifestFileParameter );
}
manifestFileParameter.setValue( newManifestFileValue );
break;
}
}
}
But unfortunately this doesn't work. There are many explicit ways to make it working but all of them will require to change all current mojos.
I wonder if someone knows why the answer doesn't work or how to make it working.
The code of updated plugin could be found here:
https://github.com/emartynov/maven-android-plugin/tree/keep-android-manifest
Thanks for everyone who read till the end.
Are you running your goal within the same lifecycle phase? If not, in the post you provided it's written:
Note: Any configuration changes are discarded at the end of the current phase.
The other thing to consider: are the goals run in order you expect? Have a look at this post: http://www.mkyong.com/maven/maven-plugin-execution-order-in-same-phase/ - Perhaps it's the ordering of plugins that you're having problems with.
Other thing to consider: perhaps you'd prefer a cleaner solution - to add such feature to the android-maven-plugin? Manfred Moser is usually open to proposals backed by pull requests ;)
I'll be most propably doing the very same thing in my plugin. The only difference is that I'm reusing goals from maven-dependency-plugin to copy dependencies within my custom plugin lifecycle. I'm trying to make a plugin for InstallShield projects building.
Does anyone has an example how to use the sourceFileExcludes element in the Maven Javadoc Plugin? I've tried the following, but cannot get it to work:
<sourceFileExcludes>
<sourceFileExclude>**/internal/*</sourceFileExclude>
<sourceFileExclude>**/Model/*</sourceFileExclude>
</sourceFileExcludes>
Have you specified excludePackageNames, cause based on the docs you should use them instead of what you've written.
<excludePackageNames>*.internal:org.acme.exclude1.*:org.acme.exclude2</excludePackageNames>
which seemed to be more approriate.
It might just not be working at the moment. There is bug logged in the plugin issue tracker - MJAVADOC-365