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.
Related
Having installed Vaadin as an Eclipse Plugin several months ago, how do I find out which version of the Vaadin Framework is currently installed on my machine?
First of all we need to differentiate between the 2 key concepts at hand:
Vaadin framework: a set of libraries (or dependencies, or jars) that are used to develop rich internet applications. They'll be packaged with your application and deployed in a web server
Vaadin Eclipse plugin: a utility designed specifically for Eclipse to help you develop using the Vaadin framework
So, while it is true that the plugin can help you get started with developing a Vaadin application, eg creating a maven project from a prototype, it has almost nothing to do with the Vaadin version (almost because probably a certain version of the plugin will be compatible with a limited range of framework versions).
On the other hand, each project that uses the Vaadin framework, will include these dependencies somehow.
if you chose to manually download the zipped files and place the jars in your project, they should contain the version in their name eg vaadin-server-8.0.6.jar. And even if they've been renamed, you can open the jar (they're just zip files) and inside the META-INF folder you'll see a MANIFEST.MF file which you can open with your favourite text editor and check the version, eg:
if you're using some dependency management mechanism such as maven (or ivy, gradle, etc) then you can look in the specific build file for the referenced version, eg:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-server</artifactId>
<version>8.0.6</version>
</dependency>
In conclusion, a Vaadin version is not exactly installed on your PC (you can have multiple versions downloaded in your local maven repo), but rather a certain version is used in a project, and you should look inside that project to figure out which one exactly is being used.
What is the difference in dependencies and dev_dependencies in a pubspec.yaml? It seems that when I run pub get the dev_dependencies aren't downloaded.
dev_dependencies are dependencies that are not available for code in the resulting application, but only for tests, examples, tools, or to add executable tools like for code generation to your project.
dev_dependencies of any dependencies in your project (dependencies or dev_dependencies) are always ignored when you publish to pub.dev.
See also https://dart.dev/tools/pub/pubspec
There are two types of dependencies, one is regular and the other is dev.
dependencies:
Regular dependencies are listed under dependencies:—these are packages that anyone using your package will also need.
dev_dependencies:
Dependencies that are only needed in the development phase of the package itself are listed under dev_dependencies.
If your package (say A) depends on another package (say B) (which has dev-dependencies), then your package A ignores the dev-dependencies of package B.
However, your package A depends on the packages listed by Package B's dependencies.
Pub supports two flavors of dependencies : dependencies and dev dependencies.
Dev dependencies differ from regular dependencies in that dev dependencies of packages you depend on are ignored.
Here’s an example:
Say the transmogrify package uses the test package in its tests and only in its tests. If someone just wants to use transmogrify—import its libraries—it doesn’t actually need test. In this case, it specifies test as a dev dependency.
Its pubspec will have something like:
dev_dependencies:
test: '>=0.5.0 <0.12.0'
Pub gets every package that your package depends on, and everything
those packages depend on, transitively. It also gets your package’s
dev dependencies, but it ignores the dev dependencies of any dependent
packages. Pub only gets your package’s dev dependencies. So when your
package depends on transmogrify it will get transmogrify but not test.
The rule for deciding between a regular or dev dependency is simple: If the dependency is imported from something in your lib or bin directories, it needs to be a regular dependency. If it’s only imported from test, example, etc. it can and should be a dev dependency.
Using dev dependencies makes dependency graphs smaller. That makes pub run faster, and makes it easier to find a set of package versions that satisfies all constraints.
Here, You can learn more about dependencies
Is Dart library exactly the same Java package ?
Is Dart package exactly the same Java library (JAR) ?
A package is a set of libraries which can for example be deployed to pub.dartlang.org. I guess this is similar to a jar file.
A library is one Dart script file with or without a name (or a set of Dart script files with part/part of) and is the boundary for privacy. Private members are only visible or accessible from within the same library.
I would like to install the fsharp compiler from Github on my Debian system, and the usual way would be to create a deb package first and then install it (so it is possible to uninstall it later, etc.). What is the easiest way to achieve this? All the examples of how to use dh_make assume you have a source tar.gz appropriately named, whereas I don't. Also I need to use some prefix for the autogen script:
./autogen.sh --prefix=/usr
I am not sure it this makes the task any more difficult.
This should actually be fairly simple to achieve with a binary package - which will also be cross-platform because the F# compiler itself is written in F#. The compiler itself is fairly standalone and depends only on a few BCL libraries. There are versions that run on Mono.
More important than installing the compiler is the integration with your platform's build system(s). Microsoft ships a Microsoft.FSharp.targets file for MSBuild, I don't know whether that will work with Mono's xBuild.
I have put together a blog post that explains where to find the various bits that make up the F# compiler and how to package them to compile on a platform that has only .NET and MSBuild (AppHarbor in my case), which you may find helpful.
I am trying to compile a j2ee project, and the solution file includes many source projects, libraries. some of source projects have dependency with other source projects. And this compile task will be done by using ant task. is there third party library allows me to do this task quickly?
next step after compiling will be export to ear file.
Thanks for helping.
You can do it using Grand, Ant2dot or VizAnt