Installing Artifactory on Ubuntu

I was messing around with some permissions settings on our “Live” verison of Artifactory, as you do, and then suddenly I thought “No! This feels wrong… I’m sure there’s someone who would be having a fit right now if he knew I was guffing around with the permissions on the live version of Artifactory…”. That someone is of course me. So I duly pressed cancel, and decided to do things “properly”, i.e. install a local version of Artifactory and mess around with that one instead.

Easier said than done.

How NOT to Install Artifactory on Ubuntu

If you want to know how to install Artifactory on Ubuntu, I’d suggest skipping to the “How to Install Artifactory on Ubuntu” section, below. However, if you’d love to know exactly how to NOT install Artifactory on Ubuntu while following the Artifactory installation instructions and getting really annoyed, then read on!

I decided to install it on my Ubuntu VirtualBox VM, because surely that would be easier than installing it on my Windows box, right? My Ubuntu VM is running java 1.7. So I downloaded the artifactory zip and extracted it. Dead easy! Then I followed this particular instruction on the artifactory installation webpage:

Before you install is recommended you first verify your current environment by running artifactoryctl check under the $ARTIFACTORY_HOME/bin folder

But by default it wasn’t executable, so I had to chmod it, duuuuh! So I did that, ran it, and I got the following error:

ARTIFACTORY_HOME not set

Er, well, no, I haven’t set ARTIFACTORY_HOME, that’s true. I had no idea I had to set it anywhere. So I set it in my profile, sourced it, and all that stuff.

I ran the artifactoryctl check command again and got another message saying:

Cannot find a JRE or JDK. Please set JAVA_HOME to a >=1.5

But that’s rubbish! I totally have 1.7 installed!! I checked my paths and all the rest. All looked fine to me. After a little while I got bored of seeing that exact same message, so I decided to just stop bothering with this stupid “artifactoryctl check” thing, and just moved on with the installation by running the $ARTIFACTORY_HOME/bin/install.sh script

ffs!

Gah! Not logged in as root. Sudo sudo sudo.

That’s better. I got a little message saying “SUCCESS” which was nice, followed by:

Installation of Artifactory completed. You can now check installation by running:

> service artifactory check

Okey dokey then, I’ll go do that!

Gahh!!! SUDO MAKE ME A SANDWICH!!!

Sudo !! is probably my most frequently typed command, along with “ll” (swiftly followed by “ls -a” when I realsie the ll alias hasn’t been setup. I’m an idiot, ya’see).

Anyway, following a swift sudo !! I got the following message:

Found JAVA= in JAVA_HOME=

Cannot find a JRE or JDK. Please set JAVA_HOME to a >=1.5 JRE

Erm, I’m pretty sure that’s not right. I definitely remember installing Java 1.7 and setting JAVA_HOME. So I echoed JAVA_HOME. Sure enough, it’s pointing to my 1.7 installation path.

Turns out that setting it in my bash profile wasn’t good enough, and I had to also put it in the following file:

/etc/artifactory/default

Oh, and don’t put the symlink path in for JAVA_HOME, that didn’t work. I had to put the full path in (/usr/bin/java got me nowhere). I literally had to put the full location in (mine was /usr/lib/jvm/java-7-openjdk-amd64/jre/). Anyway, that just about did it. Piss easy!

How to Install Artifactory on Ubuntu

  • Make sure you’ve got Java 1.5 or above installed, and make a note of the full path, as you’re going to need this later (mine was /usr/lib/jvm/java-7-openjdk-amd64/jre/).
  • Download the artifactory zip and extract it somewhere.
  • Go to your artifactory bin dir and make the install.sh file executable
  • Now run sudo ./install.sh – this will copy some files around the place and setup some paths.
  • Edit the file /etc/artifactory/default and put the FULL Java path in there as JAVA_HOME
  • Make sure JAVA_HOME is also set in /etc/environment
  • run “sudo service artifactory check”
  • If it all looks good run “sudo service artifactory start”
  • Go to http://localhost:8081/artifactory/
  • You’re done!

​How Do You Do Fixed Bid With Agile?

https://i2.wp.com/photos2.meetupstatic.com/photos/event/d/2/7/7/highres_18713879.jpeg

Last week I went along to an Agile Evangelists Meetup in London. The speaker was Kim Lennard, who works for consultancy firm Equal Experts and is currently working with one of their clients, O2. Her background is in managing Agile transformations, which is what she has been involved with for the last couple of years at O2.

There was no fixed “theme” for this particular meetup, but instead, Kim ran a sort-of “open-space” forum, where we were all invited to come up with questions/topics, and then we voted for whichever ones we wanted to discuss first. Once we’d voted, it turned out that nobody really wanted to talk about the topic I’d suggested, which was “how do you implement agile in a company which has geographically distributed teams” (even cheating and voting three times for my own topic didn’t work) but rather, people seemed to want to talk about “How Fixed Bid & Agile Go Together“. There were a lot of agile consultants in the crowd, clearly, and I was outvoted 😦

How Do You Do Fixed Bid With Agile?

Not being an agile consultant, I didn’t really know what a “Fixed Bid” contract was, or how it worked. Basically fixed bid contracts have an agreed up-front cost, and payment isn’t based on the amount of time or resources expended so you can understand how this might seem incompatible with agile. Interestingly, Kim said it was always a good idea to find out why a contract was being done on a fixed-bid basis, rather than cost-plus, for instance. I got the general impression that fixed-bid contracts were difficult to deal with and if possible, it would be favourable to convince the client to alter their contract basis. Of course, that’s unlikely to be possible in most cases, I would imagine.

Great Expectations

Kim’s first bit of advice for dealing with fixed-bid contracts was to manage expectations appropriately. Fixed Bid is a harder environment, and you have to manage the risks associated with it.

You have to be smart about how you manage expectations

 

One way of doing this is to get the client involved on a day-to-day basis, so they can clearly see and understand the challenges and issues you experience every day. These challenges and issues represent the risks to the project – if the client sees and experiences them at first hand, just as you do, then their “expectation” will be accordingly adjusted. I liked this bit of advice and I would also encourage this “good-practice” to be extended to all agile projects, not just fixed bid!

Great Expectations are good, Realistic Expectations are better.

When I was at university, I decided to catch up on some of the classic literature that I had widely ignored during my school days, and embarked upon a mission to read the likes of Dickens, Dostoyevsky, and that other bloke who did the plays. I started with Oliver Twist by Charles Dickens, which I loved, and then went on to read Great Expectations, which wasn’t as good as I thought it would be. Haha. Aside from that being an awful joke, it highlights the need to manage expectations appropriately. With fixed bid contracts it’s essential to highlight areas of risk and make sure you don’t over promise & under deliver – you have to be pragmatic and realistic. Let the client know exactly what represents a risk to delivering on time & on target. In other words, don’t give your client Great Expectations unless they’re also Realistic Expectations.

What are the Risks?

Kim identified a number of factors which could contribute to projects not delivering on time or on budget (i.e. risks), and these are:

  • Over-promising. This leads to under-delivering, obvs!
  • Not knowing your team’s velocity. Maybe they’re a new team, and not very well established. This could mean that you under or overestimate the velocity from one sprint to the next, leading your client on a merry dance, and thus risking their trust.
  • Relationship with the client. How well do you know your client? Do the clients understand you and your team? Is there trust? Do you have shared goals and a shared ethos? If the answer is “no” to any of these, then you have yourself a risk!
  • Dodgy requirements! That old chestnut 🙂 If the requirements are unclear or subject to change, then this is certainly going to impact your delivery and as such this must be flagged as a risk.

Read-only Gradle Wrapper Files Are Bad, mmkaay

I’ve just been messing around with a Gradle build using Gradle Wrapper, trying to import an ant build which does some clever stuff. I couldn’t get it to work, so I eventually changed the Ant script to just echo a variable, and then just tried importing the ant file into gradle and calling the echo task, like this:

ant file (test.xml):

    <target name=”test” >
<echo>the value of main.version is ${main.version}</echo>
</target>

Gradle file:

ant.importBuild ‘test.xml’

And I was just running this:

gradlew test

Simples, right? Well, as it happens, no. I’m running the 1.0 “release” of gradle wrapper (which is actually versioned as 1.0-rc-3, strangely enough). Whenever I tried to run my highly complicated build (ahem), I got this lovely error:

Could not open task artifact state cache (D:\development\ReleaseEngineering\main\commonBuildStuff\.gradle\1.0-rc-3\taskArtifacts).
> java.io.FileNotFoundException: D:\development\ReleaseEngineering\main\commonBuildStuff\.gradle\1.0-rc-3\taskArtifacts\cache.properties.lock (Access is denied)

Access is denied! Gah! Of course it is! Wait, why is access denied? Well, basically that file is read-only because it’s in source control and I’m using Perforce. I removed the read-only flag and the build worked. Problem temporarily solved. It’s going to be interesting to see how this is going to work in the C.I. system…