Saturday, December 13, 2014

Apache Ivy 2.4.0

Today Nicolas Lalevée has created a new release candidate Ivy 2.4.0.
Currently looking at the release candidate.
See vote email here

Friday, November 21, 2014

Configuration Drift

Recently in my day job I encountered an issue. Our continuous integration system is setup to build a Java project which is hosted in a Git/Atlassian Stash repository.

The java project is using native libraries (*.so on linux) which are referenced by one of our third party jars.

One of our feature branches wants to use the version 8 of this third party, the rest of the branches use the version 7.

The build agents run with a LD_LIBRARY_PATH containing the folder for the version 7 of the library.

The continuous integration server that we are using - TeamCity - can set environment variables - but I am not aware of a way of telling TeamCity to set up different environment variables for the same build configuration depending upon the feature branch being build currently.

Also I would not want to enter this requirement in the build configuration, because I would have to change the build configuration every time a developer does a merge.

I mentioned this problem under the keyword configuration drift in an issue TW-18911 of the bug tracker of JetBrains.

Today I looked at Travis CI. The documentation of Travis CI explains that Travis is using Travis.yml files which are checked in in the root of the source tree of the projects to be built. And Travis.yml is taken from the branch being built. Since Travis users can specify for instance the major version of the JDK to use for the build, they can build one feature branch with Java 1.7 and another with Java 1.8, and the developer preparing the change can even have the elegance to check in the change in Travis.yml at the same time that he starts making use of Java 1.8 and maybe changing his pom.xml or build.xml to indicate that the code needs to be compiled with source=1.8.

CruiseControl has a potential solution to this type of problem if one sets up one project per module to build and per branch. CruiseControl configuration supports includes. One can make a directory structure for the project configuration where each branch's configuration is in a separate folder. That's not a great solution either as it requires some scripting to setup this file/folder structure, and it must be done in advance of actually starting builds on a branch.

Conclusion : CI systems which want to be really helpful for agile teams should allow the developers to document basic facts about the build process in the source tree itself. In TeamCity's world, that would be at least the build steps page of the configuration.

As far as I know, Jenkins is configured from a web page and the configuration of the build steps does not come from a descriptor supplied by the developers and branch dependent either.


Sunday, August 31, 2014

Managing users in a web application

I am working at home on an exercise to create the skeleton of a commercial web site. Today I am working on the user management. One of the problems is how do you handle passwords. I have found these documents Storing passwords in Java web application and Jasypt: Java simplified encryption which explain me how to deal with this issue.

I have created a self-signed certificate for my application using this how to Create a Self Signed Certificate.

The examples here Main.scala and MySslConfiguration help me.

I am realizing that I can run as myself my application under port 443 on MacOS, because this is a UNIX like system. Changing the code to run under 8443.

Also I might need the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files.

I was not immediately lucky with MySslConfiguration. I am now using the sample found on the email thread titled Spray-can 1.3.1 ssl error no cipher suites in common

Saturday, May 31, 2014

Mac OS X Server Maverick upgrade

Today I have dealt with the aftermath of a Mac OS X Server Maverick upgrade.

Mac OS X Server has an integrated http server. The configuration files for the http server are now under /Library/Server/Web/Config/apache2

During the upgrade the configuration files are transformed.

In my case the loading of the .so files for Subversion in the httpd_server_app.conf file was removed, a special site file svn.conf was disabled by being renamed to svn.conf.SyntaxError, Also ProxyPass directives present in several of my site files were removed.

Maybe I should communicate these problems upstream to Apple ... or stop using the web server of Maverick and set up my own.

Oh and on top of that my Mail services were not working any more. I was not able to receive outside mail any more. It looks like I was receiving outside mail on port 465 and this does not work any more, I have had to open the port 25.

Sunday, May 25, 2014

Screen Sharing Issues with my Mac Mini running Maverick

Hi,

I have recently upgraded my Mac Mini to Mavericks.

The screen sharing from an IMac running Mavericks too is bad. When my mouse pointer is on the screen sharing window, the mouse pointer moves slowly by itself making it difficult to click on the proper window or control.

I found that article http://www.tristanbettany.com/2013/06/17/slow-screen-sharing-in-osx-vnc-performance-issues/ which gives a potential workaround.

In fact I am ending up using JollysFastVNC which works great.

Saturday, May 17, 2014

Voting today for French Conseil des Francais a l'etranger

Hi,

I am voting today for the French Conseil des Francais a l'etranger.

The vote is implemented by an applet which seems to want to run only with JRE 1.7.51

I looked in my Java Control Panel on the Mac, it displays the version which of the JRE which is installed but does not give the possibility to switch JRE.

The JRE used by the applet is under /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin . It looks like this is an actual copy of the JRE - currently I have a JDK 1.9, so there does not seem to be a soft way of switching the JRE version used to run the applets on the Mac.


So I have do download again a Java SE Runtime Environment 7u51.

I do that, and I try to install the DMG. Now I am getting an error message saying "newer version exists, refer to java.com/newerversionexists" which is a non existent URL.

Wednesday, April 9, 2014

Installing Java 1.9

Java 1.9


In order to be able to help implementing initial support for Java 1.9 inside Apache Ant,.I have downloaded and installed JDK 1.9 on my Mac.

Here is the Java 1.9 download site : https://jdk9.java.net/download/

In order not to be caught off guard with software starting suddenly to use Java 1.9 spontaneously, this Stack Overflow page : How can I change Mac OS's default Java VM returned from /usr/libexec/java_home comes in handy.

Now I can set  JAVA_HOME to /Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home and see for myself the test failures that Jan Matèrne has reported on the Ant Dev list.


Sunday, March 16, 2014

Upgrading Emacs on my Mac, using Homebrew

Yesterday, I realized that my Mac was slowed down by a process called distnoted.

A Google search taught me that Emacs was to blame for this issue.

I found this article on Stack Exchange. This is also mentioned on an emacs distribution list.

So I decided to upgrade Emacs from the 23.x build I got from EmacsForMacOSX.

I first tried the method described on The Wicked Dutch blog, building Emacs for Mac OS X.

This did not work for me.

I got this error :

configure: error: C compiler cannot create executables
See `config.log' for more details


This was happening after 10 minutes of build, pretty much in the last step, and I did not find an easy way to debug this, since especially the build directory gets deleted by the build script.

What did work was to use the methods described on the Installing Emacs on OS X wiki page of emacswiki.

Tuesday, February 4, 2014

Using the IntelliJ SBT plugin, and fighting the default Java version on MacOSX


I have downloaded the IntelliJ SBT plugin from this location.

The plugin's Github page is here : orfjackal/idea-sbt-plugin

I am running this on Mac OS X Mavericks.

I noticed a problem when opening the console : the Java version used to run the console was 1.8, which was generating a lot of errors. It looks like some scala or sbt basic libraries do not work fine with Java 1.8, or maybe it is the plugin.

So I was wondering where the SBT Console is pulling the Java version to use from. After a little bit of Googling, I found this article on Stack Overflow : How can I change Mac OS's default Java VM returned from /usr/libexec/java_home

This suggestion :

I think the only thing we might do is to change the plist:  
sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist 
and then modify the JVMVersion from 1.8.0 to something else that makes it sort it to the bottom instead of the top, like !1.8.0.

has allowed me to run the SBT console under Java 1.7.0 until all issues related with Java 1.8.0 are solved.