I'm working on automating SVN Tag generation through JAVA and need some suggestions to start of with. This is how we do it manually - Check out a maven project/plugin from SVN repo and run a set of maven commands (mvn clean test, mvn release:prepare) to generate SVN tags, mvn release:prepare is the final command that would run unit tests, generate the tag and commit it to SVN and I'm working on automating this process.
I had a look at svnkit api which I can make use of to check out a project to the local file system and find a way to run the set of maven commands to generate tag URL, is there a maven JAVA plugin through which I can trigger maven commands? Or is there a much better way to do this other than JAVA?
I did my research on svn kit but could not find any relevant info to automate the maven process, probably I'm missing out on something.
It seems that you are looking for continuous integration.
I would recommend you to evaluate the use of Jenkins, which can be configured to periodically poll changes from SVN and launch a Maven build. Then, if the build succeeded and you decide to release it, you can perform a Maven release from Jenkins, which would take care of invoking the corresponding Maven goals. You can also configure a post-commit hook in SVN in order to launch a build after each commit.
Related
I am working on a project that I need to build a maven pipeline for versioning and release.
I am doing like this:
Change version manually by running mvn versions:set -DnewVersion=2.0.0.
Check the project detail and detect if it is snapshot or release. I have my own custom plugin and a parameter which returns the final version, e.g. 2.0.0-SNAPSHOT. BUT HOW CAN I return this value and feed it to another plugin?
I compile the project and generate the jar with new name, from 2.
And...
I know I can handle every step by a CL command but what I want to know and confused me is that how to embed everything in pom.xml and just run mvn install and nothing else.
Each plugin needs some arguments that should be able to change that. I know I can use the <argument> tag under <configuration>, but some of the plugins do not have the argument tag.
How can I have a solid solution and config everything in my parent POM beforehand?
Also I do have my own plugin but I am not sure if it is possible to embed all things to that and I just run myplugin:Install.
For building a SNAPSHOT, you usually just run mvn clean verify on your project. If you need special plugins, you can configure them in the configuration section following the advice in the plugin description.
For building a release version, you should use a build server (like Jenkins). There, you can construct all the steps much easier than in Maven. If for some reason, you cannot do that, use the maven release plugin.
I use Eclipse to code my project and in order to debug\run it I have a "Maven Build" configuration with a goal.
My question is: How can I run a script file that deletes my log files before the debug starts?
Thank you.
You can't do it automatically buy you can use a script or an ant file linked from your external tools menu. So before debugging you would need to run that external tool.
Maybe there is another way. You can delete it from a maven goal if you launch the app with maven. I don't know exactly how. You can launch with maven with the exec plugin. Codehouse site is down (terminated) so I link this tutorial:
http://www.vineetmanohar.com/2009/11/3-ways-to-run-java-main-from-maven/
EDIT:
You can delete the files using Apache Maven Clean Plugin:
http://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
You need to make both steps (delete logs and run with both plugins) execute when you build with the same goal and in the right order. I don't know how to do it but I am quite sure it is possible.
I am trying to find a solution for the following puzzle. I have java projects, managed by maven, which needs some native dependencies to work (run unit and integration tests). Those are provided in form of deb packages, which needs to be installed prior to running a build.
I use Jenkins for CI. Native dependencies can not be installed on Jenkins nodes, because of conflicts with other builds and they can change often. What I do now is not to create a Jenkins job type 'maven', but 'freestyle' and use a pbuilder to create an clean sandbox, install all that is necessary and invoke maven build.
This is working great, but I am loosing Jenkins maven goodies like automatic upstream projects, trigger build when dependency change, etc. Jenkins simply does not know that maven is there.
Finally, my question. Is there a way how to achieve both, isolate build so installed libraries does not affect other builds and leverage Jenkins's 'magic' applied to maven builds and their dependencies?
You could split your build in three jobs, which trigger the next one.
Create needed environment
Run maven job
Clean Up
Even a Freestyle job has "Invoke top-level Maven targets". You could use that to get "maven goodies" while also having ability to run other build steps.
There is an option to "use private Maven repository" which will make sure it will use the .m2/repository folder location relative to the workspace. If you need to separate into multiple jobs, you can use "Custom/shared workspace" between those jobs.
Even in Maven-style job, there is an option to use private repository, so that one job does not affect another.
The problem can be solved by using distributed Jenkins builds. Slave agents can be configured to provision clean environment (e.g. via VMs, docker,...) for each build and tear it down after build is done. This way Jenkins job can be of Maven type and any changes done by pre-build step will not affect others.
More information can be found here.
Consider docker. There you can run processes in isolated environments just as you want. Docker works in a way that it easily communicates with Jenkins.
As a benefit you can also use that docker container to run local builds in the same environment as they run in Jenkins.
I have a Maven project configured in Bamboo (version 5.3). I would like to be able to use the developers section in my pom.xml in order to send build notifications to the developers defined in that section. This was possible in other Continuous Integration tools I have used before. Is there a hook that can be used in Bamboo to make it work?
If you want to use maven project configuration for sending emails, use maven itself for this job. It will work for any environment and CI tool you choose.
Provide 'build-success' + 'build-failed' profiles with configured maven-changes-plugin in your pom.xml.
Add corresponding calls into post-build handling:
mvn changes:announcement-mail -P build-success # for successful build
mvn changes:announcement-mail -P build-failure`# for failed build
I was wondering if there is a standard way (i.e. a plugin) to apply a set of patches during a Maven build. Patching the code base in a dedicated step before building is getting tedious as soon as you have different builds or generated sources.
To give an example, this script should deploy 3 different versions from a fresh SVN checkout:
#!/bin/bash
# checkout project
svn checkout http://example-project.googlecode.com/svn/tag/v1_0 example-project-read-only
cd example-project-read-only
# build example-project-1.0
mvn deploy
# build example-project-1.0-a3
mvn -Dmaven.patch.dir=/path/to/patchesA -Dmaven.patch.buildSuffix=a3 clean patch:patch deploy
# build example-project-1.0-b0
mvn -Dmaven.patch.dir=/path/to/patchesB -Dmaven.patch.buildSuffix=b0 clean patch:patch deploy
Currently I'm doing similar things with another build script I'd like to get rid of. Therefore I'm considering to write such a plugin if it's not available yet. (Maybe with dedicated patch artifacts for easy distribution as an added bonus?)
The maven patch plugin might help.
The Patch Plugin has a single goal that can apply either a single declared patch or a directory of patches. Application of an entire patch directory can be configured with various patch-inclusion, -exclusion, and -ordering options:
I haven't heard of any such plugin. However I imagine that you could do something with profiles that applied patches and conditionalized the build dir. Sounds interesting.