Automated Build of RCP Artifacts with Maven Tycho – A field report (Part 2)

In my last post of this serie, I described how to solve the dependency problem. In this post, I will describe how to build Eclipse Plugin and Eclipse Feature with Maven Tycho and which problems I have.

POM Definition

The procedure for both Eclipse artifacts is similar. In both, you have to insert a pom.xml and fill it with the Maven coordinate (group id, artifact id and version) and the packaging type. But there exists some rules about the content.

The packaging type is depended by what Eclipse artifact should be built:

Eclipse Artifact	Packaging Type
Eclipse Plugin	eclipse-plugin
Eclipse Feature	eclipse-feature

The version specification in the POM is depended by the version specification in the manifest (in case of Eclipse plugin) and by the version specification in the feature.xml (in case of Eclipse feature) respectively:

MANIFEST.MF / feature.xml	pom.xml	Description
1.5.1.qualifier	1.5.1-SNAPSHOT	Development version
1.5.1	1.5.1	Release version

The specification of the artifact id in the POM must be equal like  the bundle symbolic name in the manifest (in case of Eclipse plugin) and by the specification of the id in the feature.xml (in case of Eclipse feature) respectively. That’s all you need to define the pom.xml. Then call only mvn clean install and the Eclipse artifact is built by Maven Tycho.

Troubleshooting

I met two problems during the introduction of Maven Tycho for the building of Eclipse plugins. The first problem was that Maven Tycho sometimes throws a NullPointerException during the read-out of the manifest file. The reason is that a blank must be between the colon, that follows after the manifest header, and the command.

# Don't
Import-Package:com.library.*

# Do
Import-Package: com.library.*

The second problem was that Maven Tycho throws compiler error althought everything is alright in Eclipse. The analyse of the error message shows that the command for the Import-Package in the manifest is not completed.  A second analyse shows that package names of used Eclipse RCP artifacts are missing. After adding these missing package names in the manifest, Maven Tycho builds without error. But this also means that Eclipse does not generate the manifest osgi-compliantly.

Recognize Puppet Managed Files – Part 2

In the first part I’ve described the basic usage and the installation with Puppet of Chris Jones’ TangledStrings plugin for vim. You may want to refer to this post before; it’s found here: Recognize Puppet Managed Files – Part 1.

Now this article is about a different way of installing the plugin with Puppet. The reason for this alternative is to make it possible also for non-root users to use the plugin. As per default this is not possible, since the TangledStrings plugin needs read access to the yaml file(s) below /var/lib/puppet/client_yaml/catalog. Here Puppet stores a yaml file which contains all managed resources. But this file will be only readable by user Puppet and root.

Additionally there are some hard-wired strings inside the plugin once it is installed. They contain user specific information. So we need to find a way to make those strings dynamic and fill them with the correct user information. I will describe both, accessing the yaml file as well as the dynamic generation of the user data here.

Accessing the Yaml data
This part is quite easy to accomplish. Some analysing turned out that these files/directories were preventing a normal user from accessing the file:

• /var/lib/puppet/client_yaml
• /var/lib/puppet/client_yaml/catalog
• /var/lib/puppet/client_yaml/catalog/your.host.here.yaml

I checked this by using the same command the plugin is using:

grep -h title /var/lib/puppet/client_yaml/catalog/*.yaml | awk '{ print $2 }' | grep '^/' 2>/dev/null

Issuing this command as the user you want the plugin to be executed will give you a permission denied error message as long as there are no sufficient access rights.

Finally I turned the manual chmod commands into an appropriate Puppet configuration:

  file {'/var/lib/puppet/client_yaml':
    ensure => directory,
    mode => 0755,
  }
  
  file {'/var/lib/puppet/client_yaml/catalog':
    ensure => directory,
    mode => 0755,
  }
  
  file {"/var/lib/puppet/client_yaml/catalog/${fqdn}.yaml":
    ensure => file,
    mode => 0644,
  }

Using an ERB template for configuring the plugin
In the first part of this post I simply copied the extracted plugin as a file resource to my Puppet agents. The structure of the installed plugin looks like this:

[root@somehost ~]# tree .vim
.vim
├── doc
│   ├── tags
│   └── tangledstrings.txt
├── plugin
│   ├── tangledstrings.vba
│   └── tangledstrings.vim
└── .VimballRecord

2 directories, 5 files
[root@somehost ~]#

If you look at the file .VimballRecord you will the see the user specific strings I mentioned:

tangledstrings.vba: call delete('/root/.vim/plugin/tangledstrings.vim')|call delete('/root/.vim/doc/tangledstrings.txt')

Obviously the user’s home directory is hard-coded there. In Puppet making a string dynamic is a straightforward issue. So I simply turned file .VimballRecord into an ERB template VimballRecord.erb. The content of this template looks like this:

tangledstrings.vba: call delete('<%= user_home %>/.vim/plugin/tangledstrings.vim')|call delete('<%= user_home %>/.vim/doc/tangledstrings.txt')

The user_home variable will be replaced by Puppet with the correct user’s home directory. Of course we need the appropriate configuration inside Puppet’s manifest file. I’m showing only the relevant parts here:

  $youruser_home="/home/youruser"
  
  configure_vim { "youruser": 
    group => "yourgroup",
    user_home => "${youruser_home}",
  }
  
  configure_vim { "root": 
    group => "root",
    user_home => "/root",
  }
  
  define configure_vim($user_home, $group) {
  
    file {"$user_home/.vim":
      ensure => directory,
      source => 'puppet:///modules/unix-common/vim',
      recurse => true,
      purge => false,
      group => "${group}",
      owner => "${name}",
      mode => 0755,
    }
  
    file {"$user_home/.vim/.VimballRecord":
      ensure => file,
      content => template('unix-common/VimballRecord.erb'),
      recurse => true,
      purge => false,
      group => "${group}",
      owner => "${name}",
      mode => 0755,
      force => true,
    }
  }

This way one will always have an individually configured user for the plugin. Beware that you need to install also the rest of the plugin’s files. I’ve described this in the first part of this post.

Verifying
If everything went well and you open a Puppet managed file, you will see a warning message like this one:

Warning message displayed when a Puppet managed file is opened.