I want to use Gradle to build the snapshot version for file-uploader https://github.com/valums/file-uploader .
My grade version is 1.4 and when I run gradle zip on Mac OS X 10.7.5, it shows BUILD SUCCESSFUL, but I can not where can I find the result file ?
From the project's build.gradle file:
task zip(type: Zip) {
baseName "$filename-$version"
from files("$buildDir")
destinationDir file('release')
}
So the destination folder is called release, you'll find it under the project root.
Related
Hello I need to upload to Artifact the results of the VSBuild of the Solution but I can not use OutPutpath I get an error that the solution can not copy to certain files.
If I do not put an outputpath in the argument everything works fine, but I do not know what is the place of the VSBuild results to upload them to Artifact.
When using the VSBuild task to build a solution, normally the build artifact should be output into the directory of each project in the solution. So, the output path you set on the VSBuild task should be a relative path to each project directory.
You can follow the steps below to set up your pipeline:
On the VSBuild task, set the output path like as this.
-p:OutputPath={the relative path}
After the build, use the Copy files task to copy the artifact files form the output path to the directory $(build.artifactstagingdirectory).
Then use the Publish Pipeline Artifacts task to publish the artifact files from the directory $(build.artifactstagingdirectory).
The above are the most common steps to build projects and publish build artifacts in the build pipelines.
I'm performing this on Windows, so some of these operations might be different for Linux/Mac users.
Steps To Reproduce
Step 1: Clone the Corda V3 Kotlin template into a new folder
git clone https://github.com/corda/cordapp-template-kotlin.git MyFirstCorDapp
Step 2: clean and deploy nodes with gradle
./gradlew clean dN
Output
This image illustrates the JAR files that have been built and deployed into a cordapp folder for a node
Questions
Why does deployNodes produce MyFirstCorDapp-0.1.jar? This file
doesn't seem necessary.
Why is cordapp-contracts-states-0.1.jar so big? Given that this
was compiled directly from the kotlin template with no changes, I'd
expect this to be much smaller.
The reason why MyFirstCordapp-0.1.jar is appearing is because of this line:
task deployNodes(type: net.corda.plugins.Cordform, dependsOn: ['jar']) {
The root project has a kotlin plugin so creates a jar so the deployNodes deploys it.
One solution would be to use a subprojects closure to skip the root project
task deployNodes(type: net.corda.plugins.Cordform) {
subprojects.each { subproject ->
dependsOn(
subproject.tasks.matching { task ->
(task.name == 'jar')
}
)
}
The reason why cordapp-contracts-states-0.1.jar is "so big" (775 KB) is because the corda gradle plugin packs some dependencies in it.
When sbt-assembly builds a fat jar, it places all the dependencies in the main folder. I need to construct a jar that looks like this
--domain
domain classes
-- lib
dependency classes
is it possible to do this with sbt assembly, or any other plugin?
If you want to seperate your app jar file and your dependecy jar files, here is the most practical method i found with sbt;
Create project/plugins.sbt file if not exists and add following line:
addSbtPlugin("org.xerial.sbt" % "sbt-pack" % "0.8.0")
After adding this line refresh your project.
Note: Plugin version might change in time.
When sbt refresh finishes update your build.sbt file like this:
lazy val MyApp = project.in(file("."))
.settings(artifactName := {(
sv: ScalaVersion,
module: ModuleID,
artifact: Artifact) => "MyApp.jar"
})
.settings(packSettings)
Then run:
sbt pack
Or if you're doing this for child project, run this:
sbt "project childproject" clean pack
This will nicely seperate your main jar file and your dependency jars.
Your app jar will be in target scala folder.
Your dependencies will be in target/pack/lib.
In this way you can deploy your dependencies once.
And whenever you change your app, you can just deploy your app jar file.
So in every change you don't have to deploy an uber jar file.
Also in production, you can run your app like:
java -cp "MyApp.jar:dependency_jars_folder/*" com.myapp.App
I am trying to create a fat jar file in a multi-project Gradle build, something like the following:
root
+-- project1
+-- project2
project1 provides the basic functionality, which is then used by project2 to create an executable jar. The executable JAR needs to contain all of the code from the dependencies so that it can be run standalone.
For external dependencies this works fine. In project2 I create a new configuration:
apply plugin: 'maven'
apply plugin: 'java'
configurations {
// configuration for JARs that need to be included in the final packaging
includeInJar
}
and then add the dependencies:
dependencies {
includeInJar 'com.fasterxml.jackson.core:jackson-databind:2.2.3'
...
configurations.compile.extendsFrom(configurations.includeInJar)
}
The packaging then looks like this:
jar {
manifest {
attributes "Main-Class": "com.acme.project1.MyTest"
}
// import all dependencies into the Jar so that it can be run easily
from {
configurations.includeInJar.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}
The jar is correctly built with all of the files from the external dependencies. The problem comes with the project dependency to project1:
includeInJar project(':project1')
When this is present, I get an error when it tries to assemble the JAR that it can't find the jar (e.g. project1-0.4.0.jar) in the project1 build/libs directory as it does not exist. The message is correct, as project1 builds a SNAPSHOT jar (e.g. project1-0.4.0-SNAPSHOT.jar).
The question is, why does the configuration refer to the non-SNAPSHOT jar when the project is building SNAPSHOT jars? What can I change so that it finds the correct jar?
As a comment :
In my opinion, fatjar is not a great pattern. Maybe Gradle application plugin would fit your need ?
I found the answer to my own question.
The problem was that we have some additional scripting at the project level which is apparantly making a change to the version at the end of the configuration phase.
When the fat jar configuration is assembled, the 'plain' version is used. This is then changed to the -SNAPSHOT version before the jars are built.
Moving the from { ... } code into the build phase by wrapping it in doFirst { ... } is enough to fix the problem, although the real fix is obviously to avoid changing the version in the middle of the in the first place.
I've a JRuby-based standalone application with the following structure:
my_app
- bin
- my_app # that's a launcher script
- lib
- my_app.rb
And when I warble in the top level directory, it doesn't generates a jar file as expected but instead a generates a war file. And this war, as expected, follows the war file's standard structure.
I've followed the documentation to do it:
https://github.com/nicksieger/warbler
"If your project do not have a .gemspec, Warbler will attempt
to guess the launcher from the contents of the bin directory
and use the lib directory as the lone require path. All files
in the project will be included in the archive."
Anyone already did it?
Thanks a lot!
This functionality is in version 1.3.0 which unfortunately hasn't been released yet. Try the prerelease version on rubygems.org (gem install warbler --pre).