I am on a project witch develops an adapter utility for a legacy closed-source library which is treated as black box and due to licence agreements cannot be shipped along with the adapter utility.
In order to build the project the library needs to be in the class path which is no problem as long as I am using an IDE (IDEA in my case) but how can I tell Gradle having this dependency during building without adding it directly to build.gradle?
Related
I am currently in the process of trying to deploy my JavaFX application (either with a jar or an installer, however an installer would be preferred). I have seen some sources point to using jlink, in which I have tried to no avail.
While I would have no problem building normally with jlink, I am trying to include a custom serialization utility I made with Maven and Java 17 (no JavaFX, but it is a single modular with a module-info). To import this into my project, I am simply adding it as a dependency. Additionally, this dependency requires SnakeYAML, which I don't believe is a modular project? (Important later)
Now, with this dependency, if I try to run javafx:jlink, I typically get an error like "jlink does not work with automatic modules" (in reference to my serialization utility).
My setup:
JavaFX 17.0.1
JDK 17.0.1
Maven 3.8.4
IntelliJ IDEA ultimate
So, my main two questions:
Should I even bother with jlink, especially if I am trying to get an installer?
With modular projects like my JavaFX project, how do I add dependencies from other modular projects (and also, within the serialization utlity, somehow shade SnakeYAML) and allow them to be compiled with JavaFX?
Should I even bother with jlink, especially if I am trying to get an installer?
No.
You can make use of jlink during the process, but, in my experience, it is not necessary. Also, the images jlink creates can be a little difficult to integrate with what is required by jpackage, which you will need to use anyway.
Instead, use jpackage, not jlink if you want an installer.
jpackage can both link your application and create an installer, but jlink can only link and cannot create an installer.
With modular projects like my JavaFX project, how do I add dependencies from other modular projects (and also, within the serialization utlity, somehow shade SnakeYAML) and allow them to be compiled with JavaFX?
Don’t shade jars when packaging, it is not necessary. Also, if the jars are modular, it will break their modularity and they might not work (for example the JavaFX jars are not supported when shaded into a jar).
To add compile dependencies, you are already using Maven, just use its compile dependency mechanism.
For jar dependencies which you have created yourself, use the Maven install command to install the dependencies into your local repository, or use the install facilities in your repository manager (e.g. jfrog artifactory), if you use one.
The modern maven build process and the IDE integrations (at least Idea anyway) will automatically configure the correct paths for compilation of the declared dependencies so that they are available from the module path if they are modular and the class path or as an automatic module if they are not modular.
Include the dependent jars in your package. This can be done two ways:
if the jars are modular, link the jars into the runtime image included in the package:
Both jlink and jpackage can do this, but when creating an installer, use jpackage for the linking not jlink as jpackage will ensure all files in the image are in the right location for the installer, but jlink will not, in my experience using Java 17 tools.
if the jars are not modular, then include them in a lib directory in the package. In the startup script for your application, which is included in the package, place the lib directory for the non-modular library files on the class path, so that they can be found.
Additionally, this dependency requires SnakeYAML, which I don't believe is a modular project?
Follow the tutorial at:
https://github.com/dlemmermann/JPackageScriptFX
A description of JPackageScriptFX:
demonstrates how projects can use scripts to build self-contained, platform-specific executables and installers of their JavaFX applications via the jdeps, jlink, and jpackage tools
the scripts do not try to create a fully modularized solution but instead try to enable existing projects / applications, which often use non-modularized 3rd party dependencies, to be packaged
I've recently moved from c# .Net / Visual Studio, to Java / Maven InteliJ Idea Community.
Some things that I expect my IDE to do for me seems missing:
Generating a dependency graph between my modules to see which module references what dependent modules. I expected some kind of GUI or plugin for visualising these connections - but find myself going through multiple pom files manually.
Viewing which external dependencies are used by my app across modules and compare their versions. Being able to add an external library that is already referenced by some of my modules, to a newly created module, without the need to copy paste pom xml.
NUGET was used for discovery of new libraries and updates in .Net, is there an equivalent tool for that in InteliJ+Maven ?
Thanks
IntelliJ has similar features :
1) The IntelliJ built-in maven plugin has a feature a show dependencies icon
2) You can enable the maven auto-import for your project, IntelliJ will check unresolved dependencies for you
I'm developing an Eclipse plugin that scans and modifies the AST of the currently open Java project.
I want to create a Java annotation that will appear as a known annotation in projects that use the plugin. The annotation's RetentionPolicy will be SOURCE (so it is discarded by the compiler), yet the plugin will be able to identify (using the AST) methods marked with this annotation and handle them accordingly.
For example:
#SkipAnalysis
public void foo() {...}
This annotation will be analyzed by the plugin while traversing the AST, yet it holds no value for the compiler.
How can my plugin contribute annotations to an open project in the workspace?
After some research, it turns out that this is impossible since annotations (and other classes or interfaces) can only be contributed via the build path. Eclipse plugins can change the build path, but cannot contribute their own source code to any project.
One of the possibilities is to create a library project containing the annotation, and then use the plugin's ability to modify the build path to add that library to the build path. However, this is cumbersome and adds unneeded dependencies to the project, and if the library is not copied to every other developer working on the project, may lead to compilation errors. An exception to that is if the project uses a build automation system (like Maven or Gradle), and the library is stored in a public repository (like Maven Central), assuring that each user that imports the project on every IDE will download that library. Again - possible, but cumbersome.
I have two separate android app projects that were made in android studio I am trying to combine project 1 into project 2 to make it all one app how would I go about doing this? I know how to do it in eclipse but not in android studio.
Please note they are both of these projects are android applications none of them are android libraries.
Any help would be amazing!
When I import project 1 into project module I get this error on grade build:
Warning:Dependency School Tools Calc lib.gz:SchoolTools:unspecified on project app resolves to an APK archive which is not supported as a compilation dependency. File: /Users/chrisdebrodie/Documents/School Tools Calc lib.gz/SchoolTools/build/outputs/apk/SchoolTools-release-unsigned.apk
You cannot have two "projects" as a single project in Android Studio.
Convert one (or both) project into libraries. Then create a "shell" project to build each app. The shell project is basically empty, or it may have build specific value overrides. The advantage here is that you can modify the library and changes will be immediately reflected in both/all versions. The drawback is that you will have to fix any issues in all projects that result from any change to any library. But you can then create the "combined" project in a similar manner.
After you convert one or both to a library you can create an aar file. This gives you the option to then include that aar as a gradle dependency. Be careful to remember that you will need to re-build the aar every time you modify that project - so if you have an indication as to which is the more stable codebase, go with that for the aar. This gives you the ability to "version control" the main project dependency so that you can make changes to one project without impacting the stability of the other.
Additionally, you can write scripts and use tools like Bamboo or Jenkins to do real-time updates to the aar - but that is like using a "snapshot" dependency. When you change the aar it may compile, but it may break the build of the second project without you knowing it until you do a build on that project. (And yes, you can include a build on that project as a part of the Bamboo or Jenkins script, but it isn't easy.)
There may be other alternatives, but these seem to offer enough options to produce a wide variety of build options.
I write a repo to handle this staff safely and easily: Jacksgong/android-project-combine.
Characteristics:
Just a developing env wrapper, it can't modify projects, safe to use.
Different Android projects develop together at the one Android Studio window.
Find References and Jump into source code rather than .class file on jar package.
Jump out of the each projects compile system and using the official compile system.
Very light, very fast for each time you want to refresh combine project.
Add one project as a module of the another's. This answer explains how to do it. Note that this answer is in response to adding a library dependency, but it will work for your situation as well.
I'm currently building an Android library. The library is divided into two parts:
Core features and functionality
Utility classes such as extended Activities, FragmentActivities etc.
Now when I tried building the library's structure as such, including ActionBarSherlock and AppCompat V7 created a conflict for Gradle. The two libraries are mutually exclusive. My solution was to build a core library and 2 wrapper libraries (one for ABS and another for AppCompat V7) then provide the user with both options. So I did the following:
For the core library project "core" I ran the gradlew assemble command. This in turn generated an aar file for my library "core.aar".
I created another library project "support" and added the core.aar as a dependency in my local maven for that project. (More info on that here)
I ran ./gradlew assemble for the support library which in turn created support.aar.
I finally added the support.aar file as a dependency for my application (just like step 2)
When I finish all that, I get a compilation error for my app saying that certain resources cannot be found in my library files in the exploded-aar folder. To be more precise, in my library I have certain drawables that are used in certain layout files, both in the library. These are not found anywhere.
Any idea what could be causing the problem?