I'm used to creating custom Spring Boot based libraries with a number of different beans per library. A target Spring Boot app then would use #Import to make a subset of those Beans available w/out importing all of the beans from an external library. An external library would also include spring integration tests (i.e. #SpringBootTest).
I'm trying to replicate this functionality in Micronaut. I've created an external library using 'io.micronaut.library' gradle plugin. It also contains some micronaut integration tests (i.e. #MicronautTest).
Per https://docs.micronaut.io/latest/guide/#beanImport I expected none of the beans to be imported by default. However, I've noticed that a class annotated with #Singleton was imported by default. I suspect this is due to its inclusion in the META-INF/services/io.micronaut.inject.BeanDefinitionReference within the library jar. If I remove META-INF/services/io.micronaut.inject.BeanDefinitionReference from the jar manually then none of the beans are imported by default and I can use explicit #Import to import what is needed.
The package of the library is com.some.micronaut.http while application package is com.some.somethingelse so the namespaces do not match. Both the library and the application are written in Kotlin.
Is there a way to control which beans are imported from an external library? Or can I control which bean references are included in META-INF/services/io.micronaut.inject.BeanDefinitionReference?
Here is a relevant build.gradle portion from the external library:
plugins {
id("org.jetbrains.kotlin.jvm") version "${kotlinVersion}"
id("org.jetbrains.kotlin.kapt") version "${kotlinVersion}"
id("org.jetbrains.kotlin.plugin.allopen") version "${kotlinVersion}"
id 'io.micronaut.library' version "3.1.1"
}
dependencies {
implementation("io.micronaut:micronaut-http-client")
implementation("io.micronaut:micronaut-jackson-databind")
//test
testImplementation 'io.micronaut.test:micronaut-test-junit5'
testImplementation 'org.junit.jupiter:junit-jupiter-params'
//wiremock for http client tests
testImplementation 'com.github.tomakehurst:wiremock-jre8:2.32.0'
}
I'm flexible about usage of io.micronaut.library plugin but I do need to be able to run #MicronautTest as part of the library build.
For now, I've removed META-INF/services/io.micronaut.inject.BeanDefinitionReference from the library jar explicitly in my build.gradle:
jar {
exclude('META-INF/services/io.micronaut.inject.BeanDefinitionReference')
}
and then used #Import in my application to explicitly import the desired components. I've also submitted an enhancement request.
Related
I'm developing a Play application in Scala as a hobby project. I'm using Gradle as a building tool.
I want to generate API documentation using swagger. My goal is to generate swagger.json file containing my REST API documentation in JSON format with Gradle task during build of the project.
To generate the swagger file I'm using swagger-gradle-plugin. I have annotated controllers and methods in the controllers with proper annotations from swagger.io.swagger_play library.
Unfortunately, play annotations are not recognized by the plugin. File swagger.json generated using Gradle resolve task only picks up JAX-RS annotations I put in the controllers when trying to make plugin work.
For example, when I annotated a controller with
#Api(value="testController", tags = Array("Test controller")
annotation, the resolve task produced empty swagger.json file.
When I annotated the controller with JAX-RS annotation
#Path("/")
and then added JAX-RS annotations to the method inside the controller
#GET
#Path("testEndPoint1")
resolve task generated documentation for /testEndPoints1. But annotations from swagger.io.swagger_play are still ignored so there is not much information in the generated documentation.
I saw there are some plugins for sbt, but I want to make it work using Gradle.
Is there any way I can generate swagger REST API documentation in Play application while using Gradle building tool?
Versions of the tools in the project:
Play 2.8
Gradle 6.5.1
Scala 2.12
io.swagger.core.v3.swagger-gradle-plugin 2.1.6
io.swagger:swagger.play_2.12:1.7.1
EDIT:
Gradle configuration of the plugin:
resolve {
outputFileName = "swagger"
outputDir = "build/swagger_doc"
classpath = sourceSets.main.runtimeClasspath
readAllResources = true
openApiFile = file("openapi_config.yaml")
}
I'm building an API using Google Cloud Endpoints Framework v2 on Java AppEngine Standard.
Using Endpoints Framework means you can easily generate Java Client Library.
However I am unable to change version of this generated Client Library from maven pom or another way.
Is there a way to modify the version of the client library generated ?
You can modify the version of the client library by changing the version in your #Api annotation.
#Api(
name = "echo",
version = "v1", // Update this value
// ...
The generated api client's <version> tag in the generated pom.xml will be prefixed with the api version (and will contain a suffix of the version of the google-api-client library used, as well an optional SNAPSHOT label if you're working with a snapshot).
An example pom.xml snippet for the above definition might look like:
<groupId>com.example.echo</groupId>
<artifactId>echo</artifactId>
<version>v2-1.25.0-SNAPSHOT</version>
<name>echo v2-1.25.0-SNAPSHOT</name>
<packaging>jar</packaging>
We are using Grails 2.4.5 and are trying to use the RestBuilder class to implement some functional tests for our REST API's.
I have included compile "org.grails.plugins:rest-client-builder:2.1.1" in the BuildConfig.groovy file.
I can see that the plugin is downloaded but do not see the RestBuilder class in any src directory. I also do not see any references to other dependencies that might include RestBuilder.
Could this be an issue when the plugin was upgraded/moved for Grails 3.x?
Thanks,
Kathy
Could this be an issue when the plugin was upgraded/moved for Grails
3.x?
No.
You are expressing a dependency on org.grails.plugins:rest-client-builder:2.1.1 which depends on org.grails:grails-datastore-rest-client:3.1.4.RELEASE and that is where grails.plugins.rest.client.RestBuilder is coming from. You should see the corresponding jar file under your home directory in /.grails/ivy-cache/org.grails/grails-datastore-rest-client/jars/grails-datastore-rest-client-3.1.4.RELEASE.jar.
I am trying to implement JPA using DataNucleus in an OSGI Environment (Apache ServiceMix). I am following the guide mentioned here - http://www.datanucleus.org/products/datanucleus/jpa/osgi.html (Section under Name "JPA and OSGi")
As per the documentation here I am using the DataNucleus JPA jar. So I have Deployed this Jar on ServiceMix as follows -
osgi:install mvn:org.datanucleus/datanucleus-jpa/2.1.7
osgi:start bundleId
As this jar export the persistence provider,I have correctly changed the provider in my persistence.xml file to be org.datanucleus.jpa.PersistenceProviderImpl (which is exported by the above bundle) rather than usual org.datanucleus.api.jpa.PersistenceProviderImpl which is in a normal J2EE JPA APP.
I also have the DataNucleus Core Bundle running on my ServiceMix, which was installed on my ServiceMix using the following -
osgi:install mvn:org.datanucleus/datanucleus-core/4.0.0-release
osgi:start bundleId
Please Note: I donot have the datanucleus-api-jpa bundle running on my ServiceMix, as per the documentation, the datanucleus-jpa bundle would export the necessary classes and hence datanucleus-api-jpa bundle would not be required.
At runtime, I am getting the following error Caused by: java.lang.ClassNotFoundException: org.datanucleus.PersistenceConfiguration not found by org.datanucleus.jpa [261]
What I have noticed is that the DataNucleus Core version 4.0.0-release does not have this class, but this class exists in all previous releases (3.2.15).
I cannot deploy DataNucleus Core Version 3.2.XX onto my ServiceMix, because I have other bundles using DataNucleus Core 4.0.0-release and having both is not an option because of Singleton Creation problems.
Please let me know, if you need me to post my code, I will do so.
Please help
Cheers,
Abhijit
In conclusion, you are using incorrect/invalid jars. "datanucleus-jpa" was removed back in v2 of DataNucleus. All recent versions using "datanucleus-api-jpa" (or "datanucleus-api-jdo" if using JDO). A simple download of the DataNucleus zip file for 4.0.x would show this very clearly.
Ok, I want to manage Constants at Server level, so com.mattbertolini.hermes.Hermes is a solution.
Please see all my steps:
1- I downloaded hermes-1.2.0.jar & import into correct Library of eclipse (no problem)
2- Create MyConstantsWithLookup.java at client package
import com.google.gwt.i18n.client.ConstantsWithLookup;
public interface MyConstantsWithLookup extends ConstantsWithLookup {
String myMsg();
}
3- create MyConstantsWithLookup.properties file in the same client package. The file has this line:
myMsg=Deleted
4- In ServerData.java in Server package
MyConstantsWithLookup my = Hermes.get(MyConstantsWithLookup.class, "");
String extra=my.myMsg();
When tested in eclipse it works fine but I got Warnign message in eclipse:
[WARN] Server class 'com.ibm.icu.util.ULocale' could not be found in the web app, but was found on the system classpath
[WARN] Adding classpath entry 'file:/C:/Users/eclipse-jee-juno-SR1-win32-x86_64/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.5.0.v201212122042-rel-r42/gwt-2.5.0/gwt-dev.jar' to the web app classpath for this session
For additional info see: file:/C:/Users/eclipse-jee-juno-SR1-win32-x86_64/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.5.0.v201212122042-rel-r42/gwt-2.5.0/doc/helpInfo/webAppClassPath.html
I am not sure what this warning's about? is it serious?
The code was running ok but why eclipse generated this warning?
This class (com.ibm.icu.util.ULocale) is a replacement for java.util.Locale, so it seems Hermes has a dependency on it.
Download the ICU4J jar from http://site.icu-project.org/download and add it to your project's build path.
Source: Matt Bertolini at https://github.com/mattbertolini/Hermes/issues/3
You need to add the ICU4j jar located at http://site.icu-project.org/
to your classpath. The reason you have the ICU classes inside the
gwt-dev.jar is because GWT includes them for its Java to JavaScript
compiler. This is regrettable since it often times falsely reports the
files on your classpath.