Tag Archives: Maven

Trigger Continuous Delivery every GitHub commit

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

Crucial piece of puzzle when developing web application is Continuous Delivery. Testers or users can by early access to alpha version contribute to development process. Design,  requirements, architecture or performance problems can be catched much sooner.

I am going to show how to set up this process with usage of Maven and Jenkins. Target environment is hosted on Tomcat7. Source code is hosted on GitHub. Because I am type of developer that tries to avoid polling as much as possible, I am going to show how to trigger this process by GitHub’s cool feature called WebHooks.

1. Create Continuous Delivery job

Creation of Jenkins job and integrating it with Maven is very easy. Will quickly cover this:

  • Create it with “New Item” -> “
  • Set up GitHub URL in section “Source Code Management” (Authentication is not needed in my case, because my GitHub repository is public)
  • Skip section “Build Triggers” for now, will come back to this later.
  • Configure “Build” section with POM path and goals you are using for building your WAR file
  • Set up “Build Settings” -> “E-Mail Notification”

Save and try to run the Jenkins job. This is very common and basic Jenkins job configuration. Now we are about to set up deployment of WAR file into Tomcat7. But here comes dilemma into play. There are two very mature ways for deployment. I will cover both and let reader pick one.

a) Continuous Delivery with usage of tomcat7-maven-plugin

  • First of all we need to enable access into Tomcat7. Edit $CATALINA_HOME/conf/tomcat-users.xml (CATALINA_HOME is Tomcat’s home directory) and configure role and user as follows
<role rolename="manager-script"/>
<user username="deployer" password="===PASSWORD===" roles="manager-script"/>
  • Configure Tomcat7 credentials for Maven in configuration file settings.xml. This file is usually located in <user_home>/.m2.
<server>
	<id>tomcat-server-alpha</id>
	<username>deployer</username>
	<password>===PASSWORD===</password>
</server>
  • Set up tomcat7-maven-plugin into pom.xml
<plugin>
	<groupId>org.apache.tomcat.maven</groupId>
	<artifactId>tomcat7-maven-plugin</artifactId>
	<version>2.2</version>
	<configuration>
		<url>https://[JENKINS-URL]/manager/text</url>
		<server>tomcat-server-alpha</server>
		<path>/[TOMCAT-DEPLOY-PATH]</path>
	</configuration>
</plugin>
  • Lastly add additional Maven goal “tomcat7:redeploy” into Jenkins job

b) Continuous Delivery with usage of Jenkins Deploy plugin

  • Install Jenkins Deploy plugin
  • In Jenkins job that builds WAR, configure “Add post-build action” -> “Deploy ear/war to container”

jenkins-tomcat-deploy

2. Jenkins – GitHub integration

  • Blocking requirement here is to have Jenkins server accessible from web. If you can’t for whatever reason, you must stick with polling the source control in Jenkins.
  • Install GitHub plugin into Jenkins
  • Generate Personal access token in GitHub for Jenkins. This can be found under “Edit Your Profile” -> “Applications”

github-generate-new-token

  • Set up GitHub plugin to use generated token in Jenkins. You can find this section in “Manage Jenkins” -> “Configure System” -> “GitHub Web Hook”. Note that you don’t need to use password. API URL is “https://api.github.com”

jenkins-github-web-hook

  • Create WebHook in Github. Open repository -> “Settings” -> “Webhooks & Services” -> “Create Webhook”
  • Use Jenkins URL with suffix “/github-webhook”. Jenkins will replace automatically as you configure jobs, so that it’s not needed to create GitHub hook for each Jenkins job
  • After creation you can test webhook via three dots in “Recent Deliveries”. HTML error code “302 Found” means that it’s working fine (even when GitHub highlights it with exclamation mark).

github-webhook-creation

  • Finally enable GitHub triggering in Jenkins job

jenkins-job-triggers

That’s it. Github commit should cause deploy into Tomcat now.

References

  1. Jenkins GitHub plugin documentation
  2. Tomcat Maven plugin documentation
twittergoogle_plusrss

Share Dependencies Between Tycho and Plain Maven project

twittergoogle_plusrss

Facebooktwittergoogle_plusredditlinkedinmail

It is well known that RCP bundle is not the Maven’s best friend. Peacemaker between them is Maven’s plug-in Tycho. I was recently migrating my free time RCP based project into Maven Tycho. My goal was to share dependencies between normal Maven project and Tycho driven project. Plain maven project is needed for running TestNG tests (TestNG is not supported by Tycho).

There are two approaches how to automatically handle dependencies of Eclipse 4 RCP based project driven by Tycho:

  • manifest-first – this approach follows standard RCP/OSGi dependency mechanisms. All dependencies has to be also assembled into bundles. This is preferred and nicely described in tutorial suggested by Tycho’s website. It is hosted on github. But there are few problems complicating my goal:
    • It is needed to find existing bundle or create one for every dependency. Unhandy.
    • If I would use manifest-first approach, bundle dependencies wouldn’t be visible by non Tycho maven projects. I would need to have two set of dependencies. Redundancy.
  • pom-first – this is alternative approach when dependencies are packed into bundle by maven-bundle-plugin and this is used as dependency to project’s bundle. This approach is described here. Problem of this approach:
    • It is working only for Maven build and dependencies are not picked up by Eclipse.

Finally got the clue here (in the last approach) and came up with solution that is maybe not that pretty, but the dependencies are specified at one place and even Maven as well as Eclipse can pick them up. It is using some aspects both mentioned approaches.

I will show here only configuration crucial for my workaround. Whole project can be found on google code page. Let me describe maven projects structure:

artefact-inheritance

discography-organizer.parent – contains various properties used by child poms. Is also used to run build of all sub-modules.

discography-organizer.dependencies.parent – shared dependencies are specified here

discography-organizer.dependencies.bundle – is doing two important steps:

  1. maven-bundle-plugin to pack dependencies
    <plugin>
      <groupId>org.apache.felix</groupId>
      <artifactId>maven-bundle-plugin</artifactId>
      <version>2.1.0</version>
      <extensions>true</extensions>
      <configuration>
        <instructions>
          <Export-Package>*; -split-package:=merge-last</Export-Package>
        </instructions>
      </configuration>
    </plugin>
  2. maven-antrun-plugin to copy packed jar with all dependencies into location where it can be picked up by RCP project
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-antrun-plugin</artifactId>
      <version>1.7</version>
      <executions>
        <execution>
          <phase>package</phase>
          <configuration>
            <target>
              <copy tofile="${temp.dependencies.folder}/dependencies.jar">
                <fileset dir="${project.build.directory}" includes="*.jar" />
              </copy>
            </target>
          </configuration>
          <goals>
            <goal>run</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

discography-organizer.bundle – main RCP bundle project driven by Tycho. Expect Tycho call, there are two important configurations done:

  1. In plugin.xml configuration on tab “Runtime” choose dependency jar created by discography-organizer.dependencies.bundledependency-plugin-xml
  2. Pack main project classes into jar. This will be used by testing project discography-organizer.tests
    1. packing of application classes into jar
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.7</version>
        <executions>
          <execution>
            <phase>package</phase>
            <configuration>
              <target>
                <jar destfile="${temp.dependencies.folder}/${bundle.name}-TESTING.jar" 
                   basedir="${project.basedir}/bin"/>
              </target>
            </configuration>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    2. pom file for this test dependency
      files-in-bundle

      <groupId>sk.lkrnac.discorg</groupId>
      <artifactId>discography-organizer.bundle</artifactId>
      <version>TESTING</version>
      <packaging>jar</packaging>

discography-organizer.tests – normal maven project with tests. It is reading testing classes from jar created by discography-organizer.bundle

<dependency>
  <groupId>sk.lkrnac.discorg</groupId>
  <artifactId>${bundle.name}</artifactId>
  <version>TESTING</version>
  <scope>system</scope>
  <systemPath>${temp.dependencies.folder}/${bundle.name}-TESTING.jar</systemPath>
</dependency>

And that’s it. Dependencies needed by main bundle or test artifacts are packed into jar files. This workaround has side effects that I really don’t like. Dependencies are ugly packed in one jar for main bundle. But I can live with that because this approach enables me to combine features of Tycho and non-Tycho maven plug-ins. I am planning to use another Tycho’s features (automatic building and JUnit plug-in tests) and I have good start point for it.

If you can think of some simpler or more elegant solution please don’t hesitate to comment it. Thanks

twittergoogle_plusrss