Typically, Android and Java library developers publish their libraries on maven repositories (i.e: MavenCentral), and by giving out its compiled jar file. This makes it simple for developers to import the library into their projects using a java build automation system, which provides built-in capability to resolve dependencies, such as gradle or Apache maven. Unfortunately, importing libraries when developing an extension or component for MIT AppInventor or any of its distributions is limited into using its .jar file (and additionally .aar and .so library files for components).
So, using the maven artifact itself is in fact impossible, unless by collecting and downloading the dependency library file as well as all of its required dependencies one by one, which is indeed a lengthy process and could eventually result in missing libraries, causing a NoClassDefFoundError or compile errors, another option might be to download maven or gradle to build the libraries, although, getting the library files is typically not trivial, since this tools are mainly designed to build java projects, not to work as a dependency resolver.
Dependency resolver is a CLI which supports resolving and downloading dependencies given a maven artifact, without having to download them all one by one.
To learn more about downloading and running dependency resolver, please see the wiki.
This CLI is fully open source, you can find the source code on github:
This library is still under beta, it may not perform as expected in some situations, please let me know about any bugs, suggestions or feature requests by writing a post on this topic, or by opening an issue on github.
Cheers,
Mohamed Tamer
Support Gradle Kotlin implementations, i.e: implementation("com.test:test:1.0")
Implement progress reporting
Changes
Rename --compress flag to --merge
Updates code to Java 11. (Notice: Using a previous version of java when executing the CLI or GUI would fail ). This is change was made to support the javaFX implementation, in case you are OK of using JDK 8 with the CLI only, see the the Building Section in the GitHub wiki, you should be able to build the cli module using java 8. However, the automated CI would build the Jar file using java 11.
Warn when an AAR contains resources when using --jarOnly flag, since the resources will not be included in the output Jar file.
Internal Changes
Restructure the project into multiple gradle modules
Refactor most of the code
Rename packages from io.mohamed.* to io.mohamed.resolver.*.
Bug Fixes
Fix a bug where using the -v flag with the resolve command would prints the version text, instead of being treated as the abbreviation for the --verbose option.
Deprecations
Deprecates the --type flag, it’s automatically inferred from the artifact packaging. Setting it automatically was being overwritten.
hey i just tested it but somewhy here is a result when i try to run it from my command prompt -
PS C:\Users\asus\Downloads> java -jar dependencies-resolver-gui-0.3-beta.jar
Picked up _JAVA_OPTIONS: -Xmx2048M
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: io/mohamed/resolver/gui/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
No need, if you are going to go with sdkman, then it should apply the java version you want to use to the current shell only, however, the java 8 JDK you downloaded would apply globally to other sessions.
If you will install it manually, skip installing java 8 as you have it already installed.
You may only want to install it in case you want to switch back from java 11 to java 8 in the same shell session, using the use command, if not, it’s OK, just install java 11 and when you are done with using it, restart the terminal to use your computer’s default java 8.
$ sdk use java 11.0.12-open
Using java version 11.0.12-open in this shell.
asus@LAPTOP-FRA1ARJR MINGW64 ~
$ java -version
Picked up _JAVA_OPTIONS: -Xmx2048M
java version "1.8.0_291"
Java(TM) SE Runtime Environment (build 1.8.0_291-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)
Strange Maybe your previous java installation is conflicting with it, perhaps temporarily try to remove the java path from your PATH variable, restart the terminal, and re-run the command.
Great! Let me know if the program starts or any other error has occurred, for further development with java 8, either install java 8 using sdkman, or re-add it to the PATH variable.
Dependencies Resolver
Maybe your previous java installation is conflicting with it, perhaps temporarily try to remove the java path from your