I use a standard Maven/Gradle project structure putting source code under src/main/kotlin and automatically collected resources under src/main/resources:
\myapp
-\src
-\main
-\kotlin
-\com
-\projectname
-\MyApp.kt
-\resources
- som_file.txt
This works fine to package my distribution with the distZip task and all resources end up in a jar which is then zipped into the following structure:
myapp
-\bin\
-\libs\
I am not sure where to put external config files in my Kotlin project (e.g. db.config) which the user could edit later. Is there a correct location for external config files in Gradle project?
Related
I am working on a Gradle task for a java project. The task needs to read files from a subfolder of the project’s resources directory. I was expecting to find a standard way for Gradle to access project resources but have been unable to find one. Does Gradle provide simple way to find and import resource files? Maybe through a plugin?
If you mean the src/main/resources folder, then no. That is by convention used by the Java plugin to hold resources for the actual module and not the build classpath. But if you just want to read a file in it from a task, just use normal Java, Groovy or Kotlin APIs. You don't need a plugin for that.
Here is one for Groovy:
task printMyResource {
doLast {
logger.quiet(file("src/main/resources/subfolder/my_file.txt").text)
}
}
(The file method resolves a path to a File object relative to the project folder.)
I'm developing a Liferay 7.2 theme (WAR-style) using Liferays "Gradle Theme Builder". I configured it to generate CSS source maps, too. This works fine, except that the original SCSS files are not deployed with the theme WAR file -- the source maps, on the other hand, are deployed. In the end, the DevTools in the browser ask the server for about 200 non-existent SCSS source files, which I cannot assign by hand to a local file (it looks like Firefox and Chrome removed that feature a while ago; and no matter how much I play with local files and workspaces in the DevTools, I cannot get the browser to recognize the local files as "these are the sources I'm looking for!").
I tried to configure the gradle war task to include those scss files in the resulting WAR, but:
The Theme Builder is a gradle plugin which configures the war task programmatically and sets an exclude to **/*.scss (see the sources here). Changing that plugin is out of question, so how can I override that exclude in my build.gradle?
Alternatively, I tried to run a second war task after the first, with the intention of adding those scss files to the existing WAR file (having the added benefit of a different task to run if I want a "theme development build"):
task fragmentWAR(type: War) {
group 'build'
description 'Prepares a war with scss files'
dependsOn war
from('build/buildTheme') {
include '**/*.scss'
exclude '**/.sass-cache'
}
}
task fragmentDeploy {
group 'build'
description 'Goes to war with scss files'
dependsOn += fragmentWAR
dependsOn += deploy
}
deploy.mustRunAfter(fragmentWAR)
But that messes up the WAR file: some files are now created twice in the WAR, others are missing completely.
In the end, I need a way to deploy the scss files along with the transpiled css and the css source maps into my testing server. Has anybody got any idea how to circumvent that exclude configured by the theme builder plugin -- or any other idea that might help me here?
Have you tried using the generator-liferay-theme NPM module instead of the Gradle Theme Builder plugin? Use v9.x of generator-liferay-theme for Liferay 7.2.
See
https://github.com/liferay/liferay-js-themes-toolkit and
https://github.com/liferay/liferay-js-themes-toolkit/tree/master/packages/generator-liferay-theme for more details.
When I generate my theme using this module, I see that both .scss and .css.map are files included in my theme .war file.
Hope it helps.
I'm using the J2V8 library to run some javascript functions in the cordapp, but I'm having troubles to access the js files (or refer to them) during runtime, because when the project is built the js code is copied into the build/resources folder, not reachable from any running node (as far as I know).
I realized that I need to include the js source code into the corda.jar files, produced when I run gradle deployNodes.
I tried to add the following to the build.gradle file:
jar {
baseName = 'something'
from('src/main/resources/js_library') {
include '*.js'
}
}
but it doesn't solve my problem. Do I need to extend some tasks in the net.corda.plugins in some way? Or is there a way to access the build/resource folder once the cordapp is running?
The corda.jar is the node JAR that your applications are intended to run on/against and it isn't intended to be modified for apps.
Your own CorDapp JAR should be generated automatically by the "jar" task if you're applying the correct gradle plugin (cordformation for V1, cordapp for later versions). This JAR will be on the classpath and contain all of the files in your resources directory. For example "src/main/resources/js_library" will be available in the root of the CorDapp JAR and can be accessed directly during runtime from the classloader of any of the classes in your CorDapp. See the answer here to learn how to access files within a JAR.
With regards to the play framework plugin for gradle:
In the generated executable playBinary file that is created in build/stage/playBinary/bin/, there is a line that reads:
CLASSPATH=$APP_HOME/lib/src.jar
The last part, "src.jar" seems to be determined by the root directory that your assets were compiled in. For example if you ran gradle dist from a directory named "AProject", the classpath would instead be:
CLASSPATH=$APP_HOME/lib/AProject.jar
Is it possible to override this name in the :createPlayBinaryJar task so that I can set this to be deterministic and agnostic of where assets are compiled?
In the Gradle samples (included with version 2.2.1) there is a java/multiproject project.
The settings.gradle file defines the following projects:
include "shared", "api", "services:webservice", "services:shared"
Note that services is not itself a project, merely a directory which contains the webservice and shared projects.
When I run the command gradle build from the root directory, I notice that after gradle successfully builds it creates inside the /services directory a /build directory containing /lib and a /tmp directories.
Inside of /services/build/lib is a jar: services-1.0.jar which contains very little; specifically just a META-INF/MANIFEST.MF file containing:
Manifest-Version: 1.0
provider: gradle
So what is causing Gradle to build a jar for this non-project? And how can I prevent this behavior in my similarly structured multiproject project?
/services isn't a project, I don't want to create anything inside /build folder at all. Yes I could just delete it, but I would like to avoid the unnecessary work of building this jar/running any tasks on this non-project in the first place.
To be honest I've no reasonable idea why gradle builds this folder. I guess that because it's a kind of a transient folder. However it can be excluded by adding the following piece of code to main build.gradle script:
project(':services').jar { onlyIf { false } }
Desired effect (services.jar elimination) can be also obtained with the following settings.gradle content:
include "shared", "api", "services/webservice", "services/shared"
File instead of project paths are included.
My guess would be that this is a combination of the next 2 gradle rules:
When you're including subprojects in the build.settings file using the include keyword according to Gradle Documentation here:
the inclusion of the path 'services:hotels:api' will result in
creating 3 projects: 'services', 'services:hotels' and
'services:hotels:api'.
In simple words, this means that the inclusion of services::webservice will also build the services project
The bulid.gradle file in your root that applies the 'java' plugin. According to Gradle Documentation here every configuration defined in the root.gradle takes effect for all sub projects. This means that it will also hold as the default configuration for the services project. As the 'java' plugin was applied a jar will be created, but as there is no src/main folder under the services directory nothing will be compiled and the jar will include only a META-INF/MANIFEST.MF file.