Archive for October, 2005

CuiseControl, everything is a project

Monday, October 31st, 2005

I spent the best of last night working on CC-352 which maps every node in the cruisecontrol file to a plugin, including the root (implicitly, i.e. it if you don’t name it cruisecontrol it should still work) and the projects (explicitly). (In reality plugin and property are still handled slightly differently, but that shouldn’t be a limitation yet).

The main benefit apart from a very good code cleanup is that you should now be able to preconfigure the whole projects, and create aliases for your projects. Here’s a very simple example:

<cruisecontrol>
  ...
  <!-- note the classname may change during commit -->
  <plugin name='ant1.6project' classname='net.sourceforge.cruisecontrol.ProjectConfig'>
    <schedule>
      <ant antscript='/usr/local/lib/ant1.6.5/bin/ant'>
    </schedule>
    <listeners>
      <currentbuildstatuslistener file='${project.dir}/buildstatus.txt'>
    </listeners>
  <plugin>
  <ant1.6project name='project1'/>
  <ant1.6project name='project2'/>
  ...

So if you are an organization with many projects under CI with CruiseControl, and if your projects have a very similar setup, this should reduce considerably your config file size.

If you use CruiseControl, we could use your help in testing the new feature. Don’t look for it in CVS. You can find the current patch here, or get a build from http://moca.dynalias.com, build >= 118. Send your comments to the Jira issue or on the devel list.

I hope you will enjoy it as much as I enjoyed coding it :)

update: Jeffrey already committed the code to the trunk. Great!

Multiple parrallel m2 installs

Thursday, October 13th, 2005

I’ve encountered the need to install different versions of m2 (maven 2) simultaneously. That’s something you will probably never have to do, but maybe this little description will help you.

The basic idea is to use wrapper scripts that configure m2 to use different settings. Here’s a full explanation.

Background Information

m2 User Profile

m2 stores most of its information in your user profile. This directory, usually

${user.home}/.m2

contains in my case the following files:

settings.xml
repository/

My m2 Requirements

I fix the occasional bug in m2 and also test the latest trunk version for any regression with regard to my build. So I use both a stable m2 and a more unstable trunk version. Trying to mix m2-2.0-beta-3 and m2-2.0-beta-4-SNAPSHOT dependencies in my local repository resulted in issues and forced me to wipe out my local repository. Rebuilding this one took ages, so I decided to find a way to avoid having to do that again. Furthermore I really wanted to validate my builds from a clean build environment.

The Setup

So I decided to have a parrallel install of m2 beta-3 and m2 trunk. The following setup is Linux specific. Should be pretty easy to adapt it to Windows.

  • the settings.xml allows you to set the <localRepository>. Unfortunately you cannot store this information in your <profile>. As one cannot yet use system properties in the settings file, we have to create 2 files, one for each installation
  • m2 does not require M2_HOME/bin to be in the PATH.

Basics

Taking this into account, I have the following install:

  > ls ~/.m2/
  ~/.m2/settings-m2b3.xml
  ~/.m2/settings-m2trunk.xml
  ~/.m2/directory-m2b3/
  ~/.m2/directory-m2trunk/
  > echo $PATH
  /usr/local/lib/java/bin:/home/jerome/local/bin:/home/jerome/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
  > which m2
  > which m2b3
  /home/jerome/local/bin/m2b3
  > which m2trunk
  /home/jerome/local/bin/m2trunk
  > cat `which m2b3`
  export M2_HOME=/home/jerome/local/lib/maven-2.0-beta-3/
  $M2_HOME/bin/m2 -s ~/.m2/settings-m2b3.xml $*
  > head -2  ~/.m2/settings-m2*.xml
  ==> /home/jerome/.m2/settings-m2b3.xml < ==
  <settings>
    <localRepository>/home/jerome/.m2/repository-m2b3</localRepository>

  ==> /home/jerome/.m2/settings-m2trunk.xml < ==
  <settings>
    <localRepository>/home/jerome/.m2/repository-m2trunk</localRepository>
  >

I.e. no m2 installed on the regular PATH, but a m2b3 and m2trunk wrapper scripts configured to use 2 different settings.xml files, each one configured to use a different localRepository

If one needs to have a m2 executable in the PATH, (I need one), one can add the following line to the wrapper script:

    PATH=$PATH:$M2_HOME/bin

Installing The Trunk

Note: this only works with a m2 trunk taken from at least today (12 Oct 2005).

Thanks to MNG-1179 and MNG-1183 being fixed, one can now install the trunk in a new repository, without being forced to create a ~/.m2/settings.xml file (which I don’t use anymore)

First create this settings file for your trunk (in my case settings-m2trunk.xml).

Then build m2 using:

  > export M2_HOME=/home/jerome/local/lib/m2-trunk
  > export PATH=$PATH:$M2_HOME/bin
  > ./m2-bootstrap-all.sh -s ~/.m2/settings-m2trunk.xml

Usage

I now invoke m2b3 or m2trunk depending on what I want to do.
I can update the m2 trunk without fear of having a broken builder. Of course, one needs a little bit more of disk space. When changing builder on the same project. a m2 clean:clean should be performed before any other action.

  > du -sk ~/.m2/repository*
  16452   /home/jerome/.m2/repository-m2b3
  24140   /home/jerome/.m2/repository-m2trunk

Last Notes

Potential improvements: when MNG-942 is fixed, one will be able to do without having 2 different settings.xml file. This may turn both good (when both m2 versions are mostly identical, reuse is possible) or bad (if the structure of the settings.xml file has changed in a incompatible way, making it harder to reuse). Time will tell.

Guilt

Wednesday, October 12th, 2005

In modern societies, one is innocent until proven.
In the software developer world, one is guilty until proven.

Too many times did I blame the other party for my mistakes.

Think twice, speak/mail once…

Sunday, October 9th, 2005

- open source frameworks, development strategies modularity
- what makes a good design API analysis
- m2 plugin

Clean room open source mock API

Monday, October 3rd, 2005

Seeking legal advice.

Sometimes one needs to integrate open source software with a third party library. This library may not have a license allowing for free redistribution. This is the case with CruiseControl which integrates with SameTime and StarTeam. A contributor with access to the original libraries wrote support for those external tools in the form of a plugin that integrates with those libs. These plugins made their way into the official tree. As CruiseControl distribution model is to bundle all official plugins, it is problematic to support these plugins in an official way.

If someone makes a clean room implementation of the APIs, by only looking at the plugins,

Architecture of flexible open [source] solutions.

Sunday, October 2nd, 2005

- ABI/API
- In tree code: “we make you the honnor of supporting your code”. YOU make the effort to make up to our standards (whatever good they are)
- Internal API in-stability. If you break it, you fix everybody
- publicize API
- plugins & flexibility. Distribution, out of tree code, distributed testing, etc…

EULA & freedom

Sunday, October 2nd, 2005

Most of the time, using software forces you to agree to a EULA. This can create some interesting issues.

EULA are mostly about restrictions. They restrict your rights (and often restrict the compensations you can get out of the company who made the software). Thing is that some of these EULA are really restrictive. For example a particular EULA would forbid users to contribute to a competing software. Sounds fair on a first intent, but it really creates issues.

Another interesting issue is that the person who is responsible of agreeing to the EULA is not necessarily the same as the one using the software.

So how do handle EULAs in a wide company? You should probably first have a lawyer review the content of the agreement, especially when it comes to damage costs. You may want a technology commitee to review the EULA to see if it fits with your needs and infrastructure, a corporate policy to make sure your employees abid by the EULA they sometimes don’t even see, etc…

When you use Free Software, you don’t see any of this. The EULAs are Free Software License Agreements, and you should see them as giving you rights, not restricting them.

We often talk about hidden costs of Free Software, and this is obviously a hidden one for non-Free Software. Remember: it’s not just about money. It’s all about freedom. Lower costs is just a consequence of that freedom.