In Quarkus, to include random files as classpath resource, we use quarkus.native.resources.includes (https://quarkus.io/guides/writing-native-applications-tips#including-resources).
How to include files in the file system? I.e. something read using new File(thePath).
If we use Jib, we simply put those files inside src/main/jib. But that's for non-native.
Building a native binary has nothing to do with adding files to the file system of the target platform.
If your goal is to create a container image using the native binary and also add files to the container image's filesystem, then you can use Quarkus with Jib and the files to src/main/jib (as you mentioned). These files will be included on the built container image as described here.
Related
I have a simple question (documentation does not seem to provide a straightforward answer).
I am trying to copy over various resources (images in this case) while running an asciidoctor gradle task.
The directory structure is not the best, meaning that the adoc files and the assorted images are not logically placed but this is something that I cannot change.
I am trying to find a why to do so and I stumbled across the resources option of asciidoctor. Now my main question is how can I configure it correctly in order for it go through all the directories in the base directory and copy over whatever is not a .adoc file over to the target directory (while maintaining the same folder structure)?
Probably you don't need it anymore, but for anyone interested:
The solution is now described in 'Processing Auxiliary Files' section of Asciidoctor Gradle plugin docs.
Here you can see example:
resources {
from(sourceDir) {
include 'images/**'
include 'resources/**'
include 'some_dir/**/*.png'
exclude 'other_dir/**/notThisOne.png'
}
}
If you have a gradle-script anyway, you could use gradles copy task. Just define all sources of your images and copy them to one directory.
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html
So we have a project that is basically nothing but test files and other projects depend on it to run tests. Problem in the past has been that these items are being unpacked in locations outside of the target directory. That means you end up with modified files and new files, none of which are committed. The files are XML and are used to generate other files. What is the Maven standard location for these files? I'm looking here and I don't see anything that jumps out at me as a conventional location. I can wing it, of course, but I'd prefer to use a standard if it exists:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide
I'm considering this location:
${project.build.directory}/generated-test-resources/resources
The standard directory for test resoures like xml files is:
/src/test/resources
The way to include these test-only kind of projects is by using test-jar as described here.
There are plenty of questions and answers about how to ignore the __MACOSX/.DS_Store files created by Mac OS X...
I would like to know how to go the other way, and include the __MACOSX/.DS_Store files, specifically when working with zip files created on another platform. Simply zipping up the file structure is not enough; it seems that there is some kind of hidden flag in the zip file that is marking that part of the file structure in the zip as the mac resource fork.
Creating the resource fork on the other platform isn't the issue, I'm specifically trying to generate a zip file that properly includes already existing resources. Any thoughts? Will I need to create my own zip tool?
Using websphere 8.5. I am trying to use Monitored Directory deployment and use a deployment properties file using this guide
I have enabled the monitored deploy in the global settings. I have also extracted the properties file using wsadmin and verified that it contains the correct configuration (eg. path to a shared library).
I have put the myconfig.properties file in:
C:\websphere\myserver\monitoredDeployableApps\deploymentProperties
I then drag my application test-ear-app.ear (an ear file containing a war file) into:
C:\websphere\myserver\monitoredDeployableApps\servers\my_server
As a result the app is automatically loaded but the myconfig.properties is NOT loaded and hence I need to manually specify the shared library afterwards.
Any ideas why the myconfig.properties is not loaded?
Actually when you deploy using property file you don't drag ear to monitored directory, but just the property file. So in your case you should just drag myconfig.properties to the monitoredDeployableApps/deploymentProperties directory. In your config file you have to define location of your ear by EarFileLocation=/temp/yourApp.ear it will be automatically loaded and installed in proper scope defined by the TargetServer/TargetServer/TargetCluster properties.
See detailed description in page Installing enterprise application files by adding properties files to a monitored directory
As I read, I think the procedure is the opposite of what you were currently doing : drop the Ear first and then start the install process with the props file.
Once I use "Build->Publish->Create Service Package Only" to pack my Azure role I get two files. One is the .cscfg - a tiny XML file with service configuration. The other is the package itself which is in fact a ZIP archive with .cspkg extension.
The .cspkg file contains the .cssx file which grows larger and larger as I add stuff into my role. So I assume that the .cssx file contains all the contents of my role, binary files included. If I open it with a viewer - it doesn't contain any recognizable patterns, just some binary content.
I want to be sure that the package contains all the right stuff before I upload it to Windows Azure but since I can't analyze the .cssx file I can't do that. Is there a way to analyze the .cssx file to verify that it was assembled right?
Rename the [filename].cssx file to [filename].zip and use and open the file using your prefered archiving utility.
Before you can do this you need to follow some steps to disable encrypting the archive.
More detailed info here