In Gradle 2.0 documentation
there are some options to provide the 'init.gradle' file
command-line
init.gradle file in USER_HOME/.gradle/ folder
init.gradle file in USER_HOME/.gradle/init.d/ folder
init.gradle file in USER_HOME/init.d/ folder
and 'If more than one init script is found they will all be executed'.
My use case is that we have some project that uses old Gradle version(1.7) and the syntax is not supported in Gradle 2.0 for example.
We usually provide repos info in the init.gradle file.
How can I provide only one init.gradle file to my project build?
Or how to disable execution of all init.gradle files (and I will provide all the given parameters inside my build file)?
Related
I have created a build with Jenkins for a spring boot application and it is creating a war file.
Now I want to create a second job which should create a zip file with the war file created and appsepc.yml file and a folder "scripts" folder which contains some shell script that the appspec.yml file uses. Can anyone let me know how to do this?
The job name is "Package" so the following is the structure where the different files are.
.jenkins\workspace\Package\target\cpproject.war
.jenkins\workspace\Package\appspec.yml
.jenkins\workspace\Package\scripts\after_install.sh
.jenkins\workspace\Package\scripts\before_install.sh
.jenkins\workspace\Package\scripts\start_server.sh
.jenkins\workspace\Package\scripts\stop_server.sh
Thank you.
See the Maven Assembly Plugin:
The Assembly Plugin for Maven enables developers to combine project output into a single distributable archive that also contains dependencies, modules, site documentation, and other files.
Currently it can create distributions in the following formats:
zip
...
mavenLocal() currently serve my need by searching at my local m2 for my dev builds.
Is there other way to tell gradle to search for local m2 without changing build.gradle or other source code file?
You can use Initialization Scripts.
There are several ways to use an init script:
Specify a file on the command line. The command line option is -I or
--init-script followed by the path to the script. The command line option can appear more than once, each time adding another init
script.
Put a file called init.gradle in the USER_HOME/.gradle/ directory.
Put a file that ends with .gradle in the USER_HOME/.gradle/init.d/
directory.
Put a file that ends with .gradle in the GRADLE_HOME/init.d/
directory, in the Gradle distribution. This allows you to package up a
custom Gradle distribution containing some custom build logic and
plugins. You can combine this with the Gradle wrapper as a way to make
custom logic available to all builds in your enterprise.
Example init script
initscript {
repositories {
mavenLocal()
}
}
Check out docs for details.
I have an off the shelf application that ships a version of gradle with it. It also has scripts that are hard coded to set GRADLE_HOME to this location.
I want to zip up this dir, put it in nexus and replace it with the gradle wrapper.
How do I configure the gradle wrapper to download this zip from nexus and extract it to a specific location in the project?
EDIT: In the gradle-wrapper.properties I have
distributionPath=wrapper/gradle
However, I end up with it being unzipped to
...\wrapper\gradle\gradle-2.3-bin\8gn7esgljqyucijpbynjk93oc\gradle-2.3
How do I get it to unzip to the path I specified and not to the subdirs?
The location to which Gradle gets unpacked is a combination of the distributionBase and distributionPath properties in gradle-wrapper.properties file. The location specified by distributionPath will always be considered as relative to distributionBase. The only available values for distributionPath are GRADLE_USER_HOME and PROJECT. Even when using PROJECT the wrapper will still generate the folder structure you see above.
If you want to control this more precisely I'd suggest not relying on the wrapper to do this and instead add a task to your build specifically for this purpose.
In the gradle documentation says:
Builds which utilize a buildSrc directory will generate a second
profile report for buildSrc in the buildSrc/build directory.
How can we do that (utilize build/Src) via the gradle sript, couldn't you help me?
You may put your helper scripts/classes to various places. One of them is buildSrc directory.
See below quote from gradle documentation.
When you run Gradle, it checks for the existence of a directory called
buildSrc. Gradle then automatically compiles and tests this code and
puts it in the classpath of your build script. You don't need to
provide any further instruction. This can be a good place to add your
custom tasks and plugins.
Your qoute only tells that if you use buildSrc directory, you will have second profile report.
With the Maven assembly plugin I know I can set the permissions of the files contained within my tar such as here. However can I use the plugin to set the permissions of the tar itself?
Maybe I should just the ant plugin but this is a little messy
I haven't tested this, but you might be able to use "exec-maven-plugin" to do this.
How to change permission of jar packaged by maven? I am using maven assembly plugin
"Use maven:exec plugin to execute chmod"
So the idea is that you would add another plugin to the pom.xml file that sets the permission on the tar itself.
The only drawback that I see is that you have to have the name of the file in the plugin xml code in the pom file. That's fine as I have that listed in in the maven-assembly-plugin. But the file extension is found in assembly.xml (.zip, or .tar-gz), so if you change the file extension in assembly.xml, you would have to remember to change it in the pom.xml file. Not a big hassle, but it might be easy to miss on your first review.