Related to How to convert OpenAPI 2.0 to OpenAPI 3.0? i know that there are some external tools to convert OpenApi 2.0 to 3.0, but I need to convert and generate it while building maven project.
Are there any maven plugins to convert existing OpenApi2.0.yaml specification file into OpenApi3.0.yaml specification file during building process?
Related
I am a newbie in Ballerina.
I am importing a platform lib as a executable jar , which is an inter op method call in java using openstack swift api using jclouds.
There has been a known issue with JCLOUDS where it fails to build due to gson version issues higher than 2.5 not compatible with jclouds
Apache jclouds java.lang.NoSuchMethodError when using Rackspace in a Spring Boot application.
I face the same error when trying to execute this inter op method call from my bal file which was built during ballerina build. Upon inspection of the jar, which ballerina created during the build of the project , it shows that the jar is created with a set of prebuilt dependencies with gson 2.7.
is there any way i can change this dependency , i am not also very clear on how ballerina packages all this jars during the build phase of bal files.
It will help to have a detailed understanding on what happens below the hood when ballerina build is invoked.
The following GitHub issue explains why we had to package com.google:gson:2.7 with any Ballerina executable jar.
https://github.com/ballerina-platform/ballerina-lang/issues/17878
Let me try to explain why Ballerina compiler packages some third-party jars with the executable jar created for your Ballerina program. We can categorize these third-party jars into two main categories.
Jar dependencies of the Ballerina runtime
Jar dependencies of each Ballerina module that you've imported in your program.
Dependencies of the Ballerina runtime
Every Ballerina executable program contains the Ballerina runtime - the bare minimum layer on top of the JVM that is required to execute any Ballerina program. Runtime contains the Java implementations of Ballerina values, types, Ballerina modules in the lang lib, and the runtime type checker logic. This layer is essential to enforce Ballerina language semantics on top of the JVM.
At the moment, Ballerina runtime depends on many third-party Java libraries. GSON is one such library that we are planning to remove soon. You can get more details from the above issue.
Dependencies of a Ballerina module
Each Ballerina module, whether it belongs to the standard library or whether you pulled it from the Ballerina central, may depend on one or more third-party Java libraries. The Ballerina module author lists these dependencies in Ballerina.toml of the project in which they develop the Ballerina module. Here are some examples.
ballerina/http
ballerina/kafka
While I was working on this answer, I realized the requirement of a debugging tool that emits the details of third-party libraries. It would be nice if this tool can be integrated into the ballerina command-line tool. Here is the issue that I've created to track this.
https://github.com/ballerina-platform/ballerina-lang/issues/20116
Does upgrading to jclouds 2.2.0 resolve your symptoms? It includes JCLOUDS-1500 which upgrades the gson dependency to 2.8.5.
I am writing an Api and I need to do documentation using swagger. I am using spring boot 1.3.5 because application server is old and has java 6 configured cannot upgrade to 8 as of now. Can we use springfox swagger with java 6?
In the current version of Springfox is specified jdkVersion = 1.8, so you are out of luck. But slightly older versions like 1.0.1, should be compatible. Look at the values for sourceCompatibility and targetCompatibility
I am trying to implement for my grails project using 1.3.7 version. I am using ant build instead of Gradle build tool. I am not able to find
Which version of codenarc will support to Grails 1.3.7?
Versions above 0.9 and under 1.0.
We are currently using grails 2.2 and are trying to upgrade to 2.4, but we have an issue.
In BuildConfig.groovy, we have a few dependencies and plugins that use latest.release.
For example: 'com.example:myplugin:latest.release'.
In grails 2.2, this would work as expected. In grails 2.4, I receive an error: Error Resolve error obtaining dependencies: Could not find artifact ...
We are using the latest version of Artifactory. The error indicates that grails is looking in the correct location, but cannot find it.
If we specify a specific version then grails finds it ok. For example: 'com.example:myplugin:12.03.01'
Has something changed with latest.release since version 2.2? Should we now specify the version numbers?
Thanks.
The latest.release syntax is Ivy specific and only worked with the Ivy resolver. Grails 2.4 uses Aether a dependency resolver which is the dependency resolution engine found in the Maven build tool. In Maven the syntax for expression the latest version is slightly different. See http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
So to get the latest version you expression a minimum version with no upper bound. Example:
compile ":feeds:[1.6,)"
Anyone know if I write a Grails plugin using Grails 2.2.1 (which uses Groovy 2.0) and use some Groovy 2.0 features e.g. #TypeChecked and if a Grails project that is using an earlier version of Grails and an earlier version Groovy use this plugin?
the plugins and groovy versions of course are not backward-compatible in terms of new features. you shall prepare a backward-compatible version of your plugin by removing groovy 2.x features out of it