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()
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 just developed a custom component to wrap and add some functionalities to the standard mail component.
The component by itself works fine when creating the endpoint using a URI, but I would like to have the possibility to create the endpoint using the endpoint DSL.
I would like to pass from .to("mysmtp:hostname?port=25&to=<mail#domain.com>") to .to(mysmtp("hostname").port(25).to("<mail#domain.com>")
To write my component I started from the project generated from the Maven archetype camel-archetype-component and, as advised here, I checked that the Camel Component Maven Plugin is included in my POM.
Looking at the official Camel documentation it seems the code for the endpoint DSL should be auto-generated starting from the meta-model extracted from the component code, and this seems to be confirmed by the fact that, for instance, the MailEndpointBuilderFactory is in the generated sources of the camel-endpointdsl (here).
Is there any additional step I need to take to have my component working with the endpoint DSL or do I have to code the Builder myself?
This is not yet supported - only the out of the box components are in the camel-endpointdsl. There is a JIRA ticket about adding support for 3rd party, but its not a high priority at this moment.
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
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.
We have several in-house developed application in Groovy/Grails and use a shared plugin containing code that is common to all applications. We're needing more advanced authentication (LDAP, CAS, etc.) so it's time to implement the Spring Security plugin. I've been doing a bunch of reading on it, but I'm stuck at something as simple as changing the URLs and GSP pages that are used for the login and logout. I'm assuming that we'll also need a custom controller to make these changes.
In a normal situation where an application is using the Spring Security plugin, changing the default controller and/or GSPs seems to be as easy as just creating a file with the same name and location as the original files (since application files override plugin files). However, we're including the Spring Security plugin in our shared plugin which then is included in the application ... so unless it's possible to have one plugin override another plugins files this sort of solution doesn't seem to work here.
What would be the correct approach for overriding the default login/logout pages, url, and possibly controllers being used?
The controllers and GSPs are part of the plugin in 2.0. If you want to customize them copy them from the installed plugin directory to your project in the same folders and make the changes there. App files always override plugin files because the plugins are compiled first, then the app, so the app's files take precedence.
This procedure worked successfully for me.