Are Maven’s opinionated conventions all that useful for any semi-complex build environment?
We use Apache Ivy as our dependency management tool of choice; backed by an installation of Sonatype Nexus. Recently, due to a restructure of some internal projects we’re using Maven to publish (some) snapshot artefacts into our nexus repository and then referencing them when the time comes to generate our nightly downloads. You’d think this would be a relatively simple thing to do, but it was really much harder than it should have been.
The cost of a new integration is outweighed by the cost of maintainence
When we first started building Interlok we had a very clear design goal; it’s about the lowering the cost of maintenance as opposed to lowering the cost of new development. It’s simply a happy by-product of our design goals that the cost of integrating a new system is lowered as well. When faced with a classic integration problem; whether or not it’s customer facing or just integrating various back-end systems; once you have the process up, running and in production; the maintenance of that integration is going to be the major cost factor.
The kind of project I love is the kind that is small in scope; you have a tricky piece of integration that you can’t do with your current piece of software. It starts off small, but when you see the business value, you start using the software more and more. We had exactly this kind of project about 10 years ago. The customer put our software in place, and the first time we hear from them again was Jan 2015. Their license had expired. They had never upgraded; they’d never raised any support calls; our software had been working quite happily in the background extracting and sending all their documents. For me; this is great advert for Interlok. It just works.
Character encoding can be the bane of your life when you’re doing integration. It’s all fine and dandy when you’re dealing with the US-ASCII character set, but it all goes wrong when you start dealing with internationalised data. Even worse, there are situations where the source data is a mix of 2 different character encodings and you get 2 different byte representations for the same character. This is down to the source application not respecting encoding properly; screwing it all up.
Why isn’t Unison in the EPEL repository for CentOS 7
I generally use unison to keep my work environment on various machines in sync. I use it like a poor man’s Dropbox in effect; call me old fashioned but I don’t tend to use any cloud storage provider for security reasons. Unison means that it is trivial for me to move between my main development environment and other platforms, but as a project it appears to be unloved. I’ve recently installed a couple of instances of CentOS 7 in my test lab, and unison isn’t provided; it’s not in in the epel repository either.