Fetching artifact programmatically through REST/API in Nexus 3.x

There is so many case where it is desirable to pull down artifact from Sonatype #Nexus using REST API, unfortunately #Nexus 3.x Rest API are still under development…

Some use cases in Nexus 2.x:

  • You have a script that uses #REST call to pull down the LATEST maven artifacts every night from Nexus and deploys them.
  • You make extensive use of the #REST API in all your puppet modules
  • You use the #Atlassian #Puppet module for Nexus for creating repository, groups, assigning repository to groups, updating the main config settings, things like proxy, email, realms, and so on. The Puppet module is simply a wrapper over the Nexus REST API and allows to essentially import those abstractions into #Puppet Config Management

Here is one possible workaround that does not use any REST API mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy
-Dartifact=log4j:log4j:1.2.17:jar -DoutputDirectory=./

which is equivalent to https://gist.github.com/cedricwalter/e7739aab3d370ef83f1a13b8322e50be.js Gist Link

maven-release-plugin with GIT

Problem with the #maven release plugin

You may recognize yourself with the following use-cases:

  • We have several big modules/repositories with many branches. Per repository we have one parent pom and 50+ children poms. This is for a large JEE project (400 K lines of code) that it is delivered to several different clients.
  • We create feature branches, bug fixes, integration branches, release branches etc. We have many versions of the same application deployed to different production environments.
  • Every time a new branch is created, the version tag in the parent pom and all children poms need to be updated
  • When these branches need to be merged all these poms cause conflicts and they need to be manually resolved, because some times there are other changes in the poms besides just the version change. It is a major problem for us. 
  • We change the version on every branch because we have a continuous integration server that builds every branch and runs regression tests against every branch, therefore the versions must be different per branch.
  • Being able to keep the new version isolated to one file (the parent pom) really makes sense here. (Child pom inherits version from parent property)
  • We need to use SNAPSHOTS as we cannot have every developer build the whole system. Developers need to use artifacts built by #TeamCity for their feature branch and they cannot be changing to the last build version they depend on every time a new development build is created.

The #maven release plugin create a lot of issues that have been around for many many years.

Continue reading maven-release-plugin with GIT

Update Maven pom version on GIT checkout in TeamCity

Here is a solution to the following problems

  • Deriving #Maven artifact version from #GIT branch,
  • Update pom version on #GIT checkout automatically,
  • Add the ability to use Pull request with Apache #Maven.

You have a workflow requirement that require you to have the artifact version of a module externally defined from the current branch in #GIT.

For example

You want to start working on a new feature branch “feature-memory-improvement”, so you branch from master a new branch named feature/feature-memory-improvement

Having unique snapshot is a something you need to share your code using a #Maven repository, so you may want to have into the branch all pom.xml version changed to

<version>FEATURE-MEMORY-IMPROVEMENT-SNAPHOTS</version>

changing all your pom.xml and doing a technical commit  will create merge conflicts when using pull request!

One solution, while not perfect is to do the following:  You can add a separate execution to run a goal which will change the version of the POM automatically in the #Maven reactor. This small script will do it¨

Continue reading Update Maven pom version on GIT checkout in TeamCity

List of interesting Maven 2 repositories

I compiled here a list of the major Apache #Maven repositories (read an intro to repositories) for You, You can contact me, or post a comment if you would like to add a missing one to the list.

And of course mine at http://maven.waltercedric.com

Install Atlassian Confluence in 15 minutes

confluence.logo

In this small post, you will learn how to install Atlassian Confluence in no more than 15 minutes. It do not replace the online installations manual (The Confluence Installation Guide is for people who are installing Confluence for the first time. Check the requirements and supported platforms, then download and install Confluence), but mainly complement it, with some of the best #Linux practices (ADDED points).

 

 

Tux Droid Plugin for Atlassian Bamboo continuous integration server

tux-droid-linux-companion

Tux Droid is a #Linux wireless Tux mascot (210mm x 180mm x 140mm – with lowered wings) with a programmable interface, allowing it to announce events by its gestures and by ALSA driven sound. The events are detected by specific gadgets, which are handled by the Tux Gadget Manager. The Tux Droid supports #Linux kernel 2.4 or later and needs a 800 MHz CPU and 128 MB RAM. It communicates by infrared to the USB port (1.1 or 2.0) and for media detection it needs an internet connection. The mascot is driven by Atmel AVR RISC microcontrollers. From http://en.wikipedia.org/wiki/Tux_Droid

 

Bamboo is a continuous integration server from Atlassian Software Systems, the makers of JIRA, Confluence and Crowd. Bamboo is free for philanthropic and open-source projects. Academic and commercial organizations are charged based on type of license. Some other features of Bamboo are its unlimited build plans and unlimited projects that provide instant feedback and a platform to collaborate with other team members for build projects, and its ability to run distributed builds. It integrates with existing development tools, and it can be integrated with popular source code systems.

With this plugin

You can notify your Tux Droid with your TeamCity build results!

After login you can find the new notificator Tux Droid in your notification settings. You need your Tux Droid server IP and port  to connect your Tux to Bamboo. After you have saved the parameters you can configure your individual notification settings for just all projects/specific projects/build failures/…

Each registered User can customize Tux Droid messages or choose different Attitunes.

 

Some useful resource how to develop a Bamboo plugin with #Maven 2

Plugin will appear soon at

http://tuxdroid-bamboo.waltercedric.com/

Note you may be interested by the TeamCity continuous integration server version at http://tuxdroid.waltercedric.com/