When the gradle application plugin generates the startScripts, it generates for both windows and linux. Is there a way to exclude the windows script from going to bin/ when running distZip task?
It's possible to delete windows script in the doLast block of the startScrips task, as:
startScripts {
doLast {
delete windowsScript
}
}
You can use startScripts.enabled = false in your build.gradle file. Tested with gradle 3.4
One possible solution is to define an exclude spec for the distZip task in build.gradle as follows:
distZip.exclude "**/*.bat"
This will exclude all .bat files from the zip distribution.
Related
I'm busy deploying a .NET Core 2.1 application into our testing environment, but I'm getting the following error.
Error:
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'System.Diagnostics.EventLog', version: '4.5.0'
path: 'runtimes/win/lib/netcoreapp2.1/System.Diagnostics.EventLog.dll'
We are using the Windows Compatibility Pack to access the Event Log.
I have the following item in the dependency Json file:
"System.Diagnostics.EventLog/4.5.0": {
"dependencies": {
"Microsoft.Win32.Registry": "4.5.0",
"System.Security.Permissions": "4.5.0",
"System.Security.Principal.Windows": "4.5.0",
"System.Threading.AccessControl": "4.5.0"
},
"runtime": {
"lib/netstandard2.0/System.Diagnostics.EventLog.dll": {
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
},
"runtimeTargets": {
"runtimes/win/lib/netcoreapp2.0/System.Diagnostics.EventLog.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
}
}
Please advise how one should deploy these dependencies. Also, what is the root folder to this relative path runtimes/win/lib/netcoreapp2.0?
We actually found a solution for our scenario:
- Our situation was that we tried to run a netcoreapp based test project on our test agent
- dotnet test on the project file worked
- dotnet vstest sometimes worked on the project output directory (we are not sure why and on which setup)
- dotnet vstest did run into the above error when run into an other directory & downloaded from CI
- dotnet vstest did run into an AssemblyNotFoundException on the test agent (which didn't make any sense for us)
The solution was to use dotnet publish for our test project and use the "self-contained" output to run on the test agent. dotnet publish copied the required runtimes/win/lib/netcoreappX.X/*.dll files into the publish output directory.
After a lot of testing, the key issue seems to be the "RuntimeIdentifiers". There is a visible option for this when you publish, but in order to use it when just building you need to add a couple of tags to your .csproj file.
The first is:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
This will cause NuGet to retrieve the correct dlls (change the value depending on your needs). For me I was compiling to platform x86. I don't know what NuGet was getting by default, but whatever it was had different file sizes for the same files.
You also should then add this tag:
<SelfContained>false</SelfContained>
or else your build will default to copying the entire framework.
Also note that using the RuntimeIdentifier tag will cause your default output folder to include the value you specified. For example my subfolder became:
Project\bin\x86\Debug\netcoreapp3.1\win-86\
For publishing you should be able to do something similar; the problem will be to match your RuntimeIdentifier to your platform. You shouldn't need to specify SelfContained unless you specifically need to.
I am new to Gradle, so bear with me.. I am simply trying to call a .ps1 file to execute with gradle. How would I go about setting up a build.gradle file to execute the .ps1 file within the same directory? Thanks in advance!
You can use gradle Exec
Example:
task execPs(type:Exec) {
commandLine 'cmd', '/c', 'Powershell -File sample.ps1'
}
// add this task to your build.gradle file and execute gradle execPs
// You can use a different name for this task
// You can add a dependency to include this task as part of your normal build. (like below)
// build.finalizedBy(execPs)
// with the above command gradle build will call your task at the end of build
My Gradle build currently produces the following directory structure under a build dir in my project root:
myapp/
src/
build.gradle
build/
docs/
groovydoc/* (all Groovydocs)
libs/
myapp-SNAPSHOT.jar
myapp-SNAPSHOT-sources.jar
reports/
codenarc/
main.html
test-results/* (JUnit test results)
I would like to add the distribution plugin (or anything that accomplishes my goals, really) to have Gradle produce a ZIP file with the following directory structure:
myapp-SNAPSHOT-buildreport.zip/
tests/
(JUnit tests from build/test-results above)
reports/
main.html (CodeNarc report from build/reports/codenarc above)
api/
(Groovydocs from build/docs above)
source/
myapp-SNAPSHOT-sources.jar (from build/libs above)
bin/
myapp-SNAPSHOT.jar (from build/libs above)
After reading the plugin's documentation, I can't tell how to configure it to suit these needs. Its obvious that I need to run gradle distZip, but as to how to actually configure it to produce the desired directory structure, it doesn't seem to provide any documentation/examples. Any ideas?
Note: The JAR's version is obviously SNAPSHOT, and is passed into the Gradle build with a -Pversion=SNAPSHOT command-line argument.
The Gradle Distribution plugin automatically has defaults (the problem is that the docs do not tell us the defaults, but the Gradle project default structure is what is assumed) so if your Gradle project is fairly straightforward and already using src/main/groovy or src/main/java, you typically just need to...
Use the CopySpec reversing pattern of giving your into{} (makes a dir) containing the contents of from{} , rather than the reverse, like so:
apply plugin: 'groovy'
apply plugin: 'eclipse'
apply plugin: 'application'
distributions {
main {
baseName= 'vz_sde_dm'
contents {
into('bin/config') {
from 'config'
}
into('lib/samples') {
from 'samples'
}
}
}
}
Notice I did not need to define a from{} for my contents{}, but only into{}s that's because I am already using the default Gradle Groovy project layout and only added 2 extra folders (config & samples) under my project in Eclipse but needed those 2 folders to land into a slightly different hierarchy for my Distribution compared to my regular build folder layout.
I would probably not use the distribution plugin and instead just create a new custom Zip task. It would look something like this:
task buildreportZip(type: Zip, dependsOn: build) {
classifier = 'buildreport'
from('build/test-results') {
into 'tests'
}
from('build/reports/codenarc') {
into 'reports'
}
from('build/docs') {
into 'api'
}
from(sourcesJar) { // or whatever you source jar task name is
into 'source'
}
from(jar) {
into 'bin'
}
}
I was trying to make a custom layout also, and had real trouble figuring out how to exclude the project output from build/libs from the yourProject.zip/yourProject/lib directory (and excluding things in general) and putting it instead into yourProject.zip/yourProject.
After quite a few hours across multiple days of searching and poking around in the API I finally found something that worked using actual configurations of the Distribution and underlying CopySpec (documented here and here, respectively for Gradle 5.6.1, you can just replace 5.6.1 with current in the URL to get the most recent API docs, 5.6.1 just happens to be the version I'm using):
distributions {
main {
baseName = appName
contents {
filesMatching("**/${appName}.jar", {
if (it.getPath().contains('/lib/')) {
it.setPath(it.getPath().replace('lib/', ''))
}
})
into('config') {
exclude(['server.crt', 'spotbugs-exclusion-filters.xml'])
from 'src/main/resources'
}
}
}
}
For exclusions the only thing that worked was matching on a glob pattern and specifying the correct action (to copy it to the root dist directory instead of root/lib) with a Closure through the filesMatching method of the main distribution's content CopySpec. You can see also how destination for configs is changed from the root to the root/config directory. Thanks so Thad's answer for helping to guide me to the correct build configuration, also.
I'd like to be able to build Scala applications in Sublime Text 3 on Mac 10.9.3. I have Scala 2.11.1 and sbt 0.13.5 installed and they all work fine. I installed them by homebrew.
However, I can't seem to find how to create a build system for Scala projects. For example, this one doesn't work:
{
"cmd": ["sbt", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}
I found a couple of different ones as well but they didn't work for me, either. Your thoughts?
UPDATE:
[Errno 2] No such file or directory: 'sbt'
[cmd: ['sbt', 'test']]
[dir: /Users/alex/Documents/projects/scala/dir1]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
[Finished]
UPDATE2:
{
"cmd": ["/usr/local/bin/sbt", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}
An app:
class MainTest extends App {
println("Hellowa!")
}
The output:
[0m[[0minfo[0m] [0mSet current project to scala (in build file:/Users/alex/Documents/projects/scala/)[0m
[0m[[0minfo[0m] [0mCompiling 1 Scala source to /Users/alex/Documents/projects/scala/target/scala-2.10/classes...[0m
[0m[[32msuccess[0m] [0mTotal time: 4 s, completed Jun 16, 2014 4:51:38 PM[0m
[Finished in 7.2s]
Homebrew installs executables in /usr/local/bin, but the error text you have now provided shows that that directory isn't in your path.
Two ways you could fix it:
1) Change "cmd": ["sbt", "test"], to "cmd": ["/usr/local/bin/sbt", "test"],
2) Add /usr/local/bin to your PATH environment variable. Note that you'll need to do this in such a way that GUI apps like Sublime Text notice the change; see e.g. Setting environment variables in OS X? for details
Could SublimeSBT that's "Scala SBT build tool integration for Sublime Text 2 and Sublime Text 3." be a solution?
Why wouldn't you :D I am using SublimeSBT for quite some time, and the only complexity it's invoking cmd+shift+p followed by sbt start continuous testing. I would advice you to give SBTSublime a try before baking your own build system.
Personally I use SublimeREPL that support SBT. SublimeREPL allows you to launch SBT from Sublime. This avoided me to download another package, cause I already used SublimeSBT for python. I wanted a minimal configuration to code in scala, because my IDE was to slow. I first try to use my on build system but end up using SBT. The SBT offers great advantages in comparaison to other way of building your project.
First it compiles only files that need to (those who have been modified, and those who depend on them).
Second it's very handy for importing library. One line into your build.sbt file allows you to import library from github (usually this line is explicited on the github main page).
And third you can compile on every save, with the command "~compile", or "~; compile; runMain 'mainclass' "
I find the later pretty useful as it is often long to compile with scala. I often start to add a simple function, save, and while it's compiling I improve my first draw.
The main constraint is you have to put your code in src/main/scala or src/main/java if you have some Java files too, and you have to open the whole root directory with sublime.
Windows only!
If you already add the bin folder to the PATH variable:
{
"cmd": ["sbt.bat", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}
We are trying to migrate our Eclipse projects using ant builds into Android Studio using gradle. So far all is good except for our JUnit tests that use external json files. We have a ton of these where the the external file is located in the same directory as the java file. Is there a way to keep the java code and the json file in the same location and just modify the build scripts in gradle?
Current build directory is something like this \com\pack\krf\ contains MyFileTest.java and data.json. Source code to load json is this:
getClass().getResourceAsStream("data.json");
I do not want to change 300+ java files that have this same structure. Plus I do not want to group into the resource directory in gradle since some of these files will have the same name.
Here's the solution one of my teammates came up with. Add this to your build.gradle file after the android declaration. The print path is for debugging.
task alterResourcePath << {
sourceSets.testDebug.resources.srcDir('src/test/java')
sourceSets.testDebug.resources.srcDirs.each {
File f->
if(f.exists()){
println f.path
}
}
}
test.dependsOn alterResourcePath
By default gradle (like Maven) puts the resources under src/main/resources, so you'll have to tell Gradle to look for them in src/<something>/java instead:
android {
sourceSets {
instrumentTest {
resources {
srcDirs = ['src/instrumentTest/java']
}
}
}
}
if you are running robolectric test you do the same, but the robolectric plugins out there uses standard java source sets. So you won't do this inside the Android extension:
sourceSets {
test {
resources {
srcDirs = ['src/test/java']
}
}
}
If you use other sourceSets (per flavor or per build Type) you'll need to update those as well.