Apparently there is no plugin for building Debian packages from Jenkins, but what would be the best way to do it without a plugin?
Should I just call a shell script as a post build step, which would create the package or is there a more elegant way?
We are developing a Java project which is built using Maven and packed as a debian package using a shell script.
You could try the deb-maven-plugin as part of your Maven build but to be honest if your script is working, I'd stick with that. No reason for it to be a post build step though, you can use the exec-maven-plugin to run your script from within Maven.
Related
when I search for installing maven, I found videos on how to instal maven on eclipse and how to instal maven on MAc.It may be very basic question but just wondering whats the purpose of installing maven on MAC? I use maven on eclipse already
You would install Maven to be able to execute the mvn command from the command line (usually Terminal.app). This is usually because you need to do things that your IDE does not easily allow you to do, or to ensure that your project builds correctly with plain Maven.
This is important because the Maven emulation in Eclipse is good but not perfect (as there are some design decisions in Eclipse that do not work well with the Maven mindset). A typical situation is that Eclipse does not treat src/test different from src/main and Maven does. The easiest way to ensure this, is to build your projects from the command line once in a while.
I'm learning gradle and some questions bother me
When I want to use gradle, I'd better use gradlew. But when I want to use gradlew, I need a installed gradle. So is that a story about chicken and egg?
Should be gradle-wrapper.jar uploaded to git repository? Some docs say git should track it, but it seems not good to track a binary file with git.
Using ./gradlew you are using a gradle wrapper. The wrapper is part of a project and it is able to download and install a specific version of gradle.
The Gradle Wrapper consists of a few files in your project directory:
gradlew: The shell script Unix users can run to execute Gradle tasks
gradlew.bat The bat script Windows users can run to execute Gradle tasks
gradle/wrapper/gradle-wrapper.jar The wrapper’s executable JAR; this is where the wrapper code resides
gradle/wrapper/gradle-wrapper.properties A properties file for configuring the wrapper
Using the wrapper guarantees that every developer on your team in a specified project is using the same version of Gradle and that they can run Gradle builds.
You should make sure all these are committed to version control
You can easily change the version of gradle used in the project just changing the gradle/wrapper/gradle-wrapper.properties file with the distributionUrl properties. For example:
distributionUrl=https\://services.gradle.org/distributions/gradle-4.0-all.zip
You can find more info about the wrapper here.
Using ./gradle you need to download and install manually the gradle version before.
It means that every developer in a team can use different version on the same project.
How can I configure my Gradle script to automatically download PhantomJS for my tests to use, so that I don't have to manually install it somewhere on my build server?
I see a phantomjs-maven-plugin that seems to do exactly what I want, but I don't know how to use it in Gradle.
What is the difference between using gradlew and gradle or are they the same?
The difference lies in the fact that ./gradlew indicates you are using a gradle wrapper. The wrapper is generally part of a project and it facilitates installation of gradle. If you were using gradle without the wrapper you would have to manually install it - for example, on a mac brew install gradle and then invoke gradle using the gradle command. In both cases you are using gradle, but the former is more convenient and ensures version consistency across different machines.
Each Wrapper is tied to a specific version of Gradle, so when you
first run one of the commands above for a given Gradle version, it
will download the corresponding Gradle distribution and use it to
execute the build.
Not only does this mean that you don’t have to manually install Gradle
yourself, but you are also sure to use the version of Gradle that the
build is designed for. This makes your historical builds more reliable
Read more here - https://docs.gradle.org/current/userguide/gradle_wrapper.html
Also, Udacity has a neat, high level video explaining the concept of the gradle wrapper - https://www.youtube.com/watch?v=1aA949H-shk
gradle vs gradlew
gradlew is a wrapper(w - character) that uses gradle.
Under the hood gradlew performs three main things:
Download and install the correct gradle version
Parse the arguments
Call a gradle task
Using Gradle Wrapper we can distribute/share a project to everybody to use the same version and Gradle's functionality(compile, build, install...) even if it has not been installed.
To create a wrapper run:
gradle wrapper
This command generate:
gradle-wrapper.properties will contain the information about the Gradle distribution
*./ Is used on Unix to specify the current directory
I'm new to compiled web development, and I'm just trying to figure out the build/deploy process.... I've done:
mvn clean install
on a project, which built and deployed the project and now I can see it. If I want to make changes to the codebase, do I really need to run mvn clean install again to re-build and deploy the changes or is there a way to do a quicker build without using a "proper" IDE?
I'm using vim/gvim
Thanks!
Maven already handles the dependencies and only re-builds the necessary files... unless you throw away all previous build artifacts with clean! You should only need to use clean when you run into problems, or when you have checked out a different version from version control. Usually, mvn install should suffice.
You can integrate that with Vim; the simplest is to
:set makeprg=mvn
and then trigger a build with :make install.
Plugins build on that simplistic setup, e.g. check out:
maven-plugin
maven-ide