I'm trying to get to the source sets. IIUC from How to get the project Extensions in gradle tooling?, there's no API that allows such access but I'm hoping I've missed something.
See sample code at: https://github.com/foragerr/tooling-api-custom-model
I extended the example at http://gradle.org/feature-spotlight-gradle-tooling-api/ , adding a new function to custom model to expose java.main.srcDir.
run ./gradlew invocation:run to demonstrate.
http://gradle.org/feature-spotlight-gradle-tooling-api/ shows how to create a Model that can expose a plugin's internals. https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/groovy/org/gradle/api/plugins/JavaPlugin.java shows that the Java plugin doesn't implement such a model. Therefore, getting to the source sets via ProjectConnection isn't possible.
Related
I am working on creating an internal library/starter for my team that will add support for creating native images, providing all of the hints that our currently unsupported dependencies will need. I really like providing the metadata via code (using RuntimeHintsRegistrar), but there are also certain classes that need to be initialized at build time for whatever reason.
Right now I'm passing the --initialize-at-build-time and the classes to the Spring Boot Maven Plugin via the BP_NATIVE_IMAGE_BUILD_ARGUMENTS, but ideally I'd like to avoid each consuming app having to include this in their own POM's plugin configuration.
I also understand that I can go more low-level and provide the argument inside of the META-INF/native-image directory in a native-image.properties file, but I'm not sure whether that will play nice with the Spring-provided RuntimeHintsRegistrar effectively creating that underneath the covers.
What is the best way to tell native-image the classes that should be initialized at build time without each consuming app having to pass it in their own POM? Also, if I use the GraalVM tracing agent to generate hints, will those hints play nicely with the ones that RuntimeHintsRegistrar generates?
Thanks in advance!
I need help in getting clarification for below mentioned points
I have a swagger json. From this I want to generate Model separately by passing java as language. api and invoker clsses by passing spring as language and want to add model jar as dependency. Because I want to use model for different projects commonly. So I want to include a build task to generate model jar every time to get latest models from json. and will issue swagger code gen command with spring as language while trying to create project. Is this correct way of handling. If not can someone let me know best of handling this.
How to handle versioning from swagger.
I am new in using swagger and spring. Please suggest me best to go
I do something similar. I have my models in a separate project which is then a dependency for a bunch of API projects. This is because the APIs sometimes call each other, so need to know about each others objects.
What I do is:
Swagger structure:
In the models project I have a swagger containing just the definitions (empty object as paths)
In the API projects I have a swagger which references the definitions in the models project
Build process
Build the models project first with generateApis = false
Build the APIs with typeMappings and ImportMappings in the config, telling them to take all the models in common from that namespace
I use the maven plugin to run the codegen. I have a pretty hacky bash script that updates the type mappings in the pom when I have added new objects to the models
Both provided in samples/toolingApi/customModel and Feature Spotlight examples of Gradle Tooling API custom model use plugin to register the model. However in order to apply the plugin it's necessary to either change build.gradle or use initialization scripts, which are supported by GradleConnector (yet).
How can I register a custom model within Tooling API itself, so my application can retrieve projects' information in a custom format without changing their build.gradle files? How can I get a reference to ToolingModelBuilderRegistry implementation in an application code?
Init scripts are supported, they are just an argument like any other.
projectConnection.models(ModelType).withArguments('--init-script', pathToInitScript).get()
Question
How do I interact with Gradle Projects programmatically?
Context
I need to retrieve the Build Information provided in:
org.gradle.api.DefaultProject.
But I see no way of getting the Project/SourceSets/Configuration container objects through java.
All the documentation I see describes how to achieve this using groovy DSL.
Thanks
I created some system properties in TC build configuration.
The value of these properties are passed to a maven configuration this way:
clean test -Dargument1=%system.property1% -Dargument2=%system.property2%
And this works as expected.
What I want to do now is to modify the value of the system properties when the build finish, so the next build will get these values.
Is it possible to do that programmatically, through Java or using Maven?
Is this the correct approach?
You can define build properties for this. Once your build finishes, you can craft a Maven plugin that sends a post request to TeamCity and alters the values for these build properties for the build type.
If I where you, I would craft maven task, which will update your properties via TeamCity restAPI on build completion.
It looks like mostly elegant way to do this task.
Full explanation for restAPI plugin could be found here:
http://confluence.jetbrains.com/display/TW/REST+API+Plugin
What is needed for your use-case is described here:
Build Configuration And Template Settings
Build configuration parameters: GET/DELETE/PUT http://*teamcity_url_goes_here*/httpAuth/app/rest/buildTypes//parameters/ (accepts/produces text/plain)
You could craft a request to update your parameters.
One more interesting thing: If you want to execute requests to REST API inside a TeamCity build running on the same server, you can use %teamcity.serverUrl% predefined parameter to construct URL