I want to do an 'apply from: ./gradle/script/common.gradle' in my root build.gradle and have it be available to all of my subprojects.
I've tried putting the apply in the 'subprojects' but because the path is relative it won't always resolve, (the subprojects are not flat). I've also put it outside of the subprojects at the root but then the targets aren't resolved by the subprojects.
I haven't been able to find a way to get the working directory in a way the 'apply from:' likes, or how to get the root directory or directory that the original gradle script is being executed from.
In your root build.gradle.:
allprojects { // or: subprojects { ... }
apply from: "gradle/script/common.gradle"
}
Should you ever need an absolute path to such a script, you can always do "$rootProject.projectDir/gradle/script/common.gradle".
Appending "apply false " in each line had solved the issue for me.
Example
id 'org.springframework.boot' version '2.5.5' apply false
id 'io.spring.dependency-management' version '1.0.11.RELEASE' apply false
Related
Project structure:
/lib/modules/mod1.py
/mod2.py
/subdir1/subdir2/mod3.py
/configs/config.yaml
mod3.py imports mod2.py. mod2.py imports mod1.py. mod1.py loads configuration files that are at a relative path to mod2.py using os.getcwd().
The problem is that when mod3.py imports mod2.py, mod1.py attempts to load the config files from a path relative to mod3.py (i.e. /subdir1/subdir2/configs/config.yaml instead of /configs/config.yaml)--this, of course, doesn't work.
I believe understand why this isn't working (os.getcwd() get the path of the originally executed file).
How can I fix this so that mod1.py will use a path relative to mod2.py even when mod2.py is imported from mod3.py?
I haven't been able to find a built-in way to do this in Python, so what I ended up doing is this:
mod1.py:
configs_list = os.getcwd().split('/')
for x in configs_list:
# Check each directory in list, bottom up. 'pop()' list on
# each failure. Assign var and break loop when configs path is found.
if not os.path.exists('/'.join(configs_list) + '/configs'):
configs_list.pop()
else:
configs_path = '/'.join(configs_list) + '/configs'
break
configs_path is then used to prefix the specific configuration file name(s) in mod1.py. Since every call to mod1.py will occur from within a project's directory structure, and every project has only one configs directory, this should (and has so far) correctly identified the configs directory regardless of where in the project the given script is being run from.
I'm open to better or more Pythonic ways of doing this, if anyone has input.
I'm trying to build a Gradle JAR project that is a subproject of another and would like the output JAR file to be in a parent directory (to be specific in the "lib" directory of the parent, or sibling). How do I configure Gradle for this and where is this documented?
In build.gradle, add:
libsDirName = '../../lib'
The config settings are shown in the official Gradle docs for the java plugin.
BTW, I fully agree with the intent behind the comments and answers given by Peter and Hiery, but sometimes the simplest solution is the best one.
Agreed with the comment Peter typed. However I think you want to express that the parent project depends on the output of the submodule. Expressing that and ensuring that the parent copies the output of the submodule to its 'lib' directory makes more sense.
task assembleSubModules(type: Copy) {
destinationDir = file("lib")
into("lib") {
project.subprojects.each { p ->
from(p.tasks.withType(Jar)*.outputs)
}
}
}
My settings.gradle file looks like:
include "serverTest", "shared"
And the serverTest build.gradle file looks like:
group = 'gradle'
version = '1.0'
defaultTasks 'build'
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = JavaVersion.VERSION_1_6
dependencies
{
compile project(':shared')
}
The directory structure is: The top level holds the settings.gradle file and it has folders shared and serverTest in it. Then in the serverTest directory there is the build.gradle file.
When I run gradle at the top level it outputs:
:shared:compileJava UP-TO-DATE
:shared:processResources UP-TO-DATE
:shared:classes UP-TO-DATE
:shared:jar UP-TO-DATE
:serverTest:compileJava UP-TO-DATE
:serverTest:processResources UP-TO-DATE
:serverTest:classes UP-TO-DATE
:serverTest:jar UP-TO-DATE
:serverTest:assemble UP-TO-DATE
:serverTest:compileTestJava
:serverTest:processTestResources UP-TO-DATE
:serverTest:testClasses
:serverTest:test
I don't want it to execute the task :serverTest:test though. I tried changing my defaultTasks to just compileJava but that didn't work, does anyone else have any ideas?
Well this question has been asked in different ways , the main theme of the question is;
How to exclude sub tasks of build task?
1 . gradle build -x test
The above instruction is helpful while executing gradle build command from CLI; this exludes test task, but we want to exclude test task programmatically in build.gradle file. Look below the answer for the respective question.
2 . check.dependsOn -= test
Copy this small script in your build.gradle file.
Now when you execute gradle build from CLI, your tests won't run at all.
Cheers !
You could try to disable the task only if a build task is present... Something like:
project(":serverTest").test.onlyIf { !gradle.taskGraph.hasTask(":shared:build") }
I want to add an deployment item to my test. As far as I understood up until now, the path is relative to the solution. I want the path to be relative to the project. Otherwise, the project can't be used in multiple solutions.
How can I configure the deployment Item to be relative to a project dependent variable?
I was hoping for something like: [DeploymentItem(#"$(ProjectDir)..\..\bin\$(Configuration)")] but I don't find any documentation and it does not seem to work.
I just did a small test. Just plain wizard code and one deployment item:
[TestMethod]
[DeploymentItem("stdafx.cpp")]
void TestMethod1()
{
Assert::Fail();
};
and the trx file shows the following line:
Warning: Test Run deployment issue: Failed to get the file for deployment item 'stdafx.cpp' specified by the test 'TestProject1.UnitTest1.TestMethod1': System.IO.FileNotFoundException: Could not find file 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'.
System.IO.FileNotFoundException: Could not find file 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'.
File name: 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'
which means that "stdafx.cpp" is searched relative to the solution directory (which is in ...\depoymentItemTest) and not the project directory (which is in ...\depolymentItemTest\TestProject1)
I know this is an old question, but my answer may help others.
I was able to solve this problem with two simple steps:
Create the following build event on the test project:
xcopy /I /S /Y "$(TargetDir)*.*" "$(SolutionDir)\bin"
This will copy all the contents (including sub-directories) of the project folder to a folder "bin" relative to the solution.
Add the following DeploymentItem to the test class:
[DeploymentItem ("bin")]
This will copy all the bin contentes to the test folder
This mechanism may be refined (if required) with additional filters both in the build event and the DeploymentItem
Let the test setup copy the file to Environment.CurrentDirectory.
Has anyone been successful doing this?
It should work by just calling make in the root directory if:
1) You have the GOROOT env variable set
2) You have access to the directory in which go is installed
I had neither. Point one can easily be solved by using gomake instead of make. The problem is that i haven't added the bin directory of the go directory to the root users PATH, so i had to start up a root termianl, export the go bin directory to the PATH and then call gomake in the Go-SDL directory.
My case seems to be pretty special though, but maybe it can help.