Showing posts with label hosting. Show all posts
Showing posts with label hosting. Show all posts

08 January 2020

Android library using GitLab as an aar repository


As your Android project begins to grow you will likely start to accumulate a few libraries. Not the official ones, like rxjava, androidx and so on, but I'm talking about ones you've developed yourself. These could be your entire network layer, your really really useful utils folder, or whatever. If you're a good developer you'll have these in separate modules or possibly even completely separate projects. To start with this is fine, you may be copying your aar files around or just being vocal about changes to your modules so your teammates can keep up to date.

This article gives a fantastic explanation of why it's a good idea to stop doing that:
https://inthecheesefactory.com/blog/how-to-setup-private-maven-repository/en

The author makes some excellent points why modules and copying aars are a bad idea. The ones I most agree with are:


Library distributed to other developers should not be modifiable. In case there is some problem, issue should be reported to developer involved to let them fix. Letting other developers directly access the source code might cause them accidentally doing a quick fix by themselves which will cause a big problem afterwards. 
Most of the problem listed above are solved except one: it's still hard to update and roll back over the version.

The solution is to use a repository. Basically give your library a specific version and deploy it to a repository so it can be referenced simply using nothing more than a gradle import. Luckily for us there are a few repositories out there and they can be easily made private. So we only allow permitted developers access to our libraries.

Jfrog is a great way to go, but this means you've probably got to manage a server yourself. What I was hoping for was a cloud method where I had no server admin and no setup process. So I turned to my old friend GitLab.

Now the first and most important thing to note is that the GitLab repository pattern (named packages) is not free. GitLab Packages is only currently available on the Silver package, which does incur a monthly cost. Although they do have a trial period, if you just want to give it a go. There is a project level setting to enable packages, but for me this was already turned on.

So that said, let's get to the code. First step is to create a library.

I created an Android library named "WorstLibEver" this is the extent of it:

public class HodorUtils {
    public String askHodor(String question){
        return "Hodor";
    }
}

I know, you're blown away aren't you?

Now we need to edit our gradle file:

First add this line to the top:

apply plugin: 'maven-publish'


Next you'll need to add the following to the bottom:

task sourceJar(type: Jar) {
    from android.sourceSets.main.java.srcDirs
    classifier "sources"
}

publishing {
    publications {
        bar(MavenPublication) {
            groupId 'com.test'
            artifactId 'worstlibever'
            version '1.7'
            artifact(sourceJar)
            artifact("$buildDir/outputs/aar/app-release.aar")
        }
    }
    repositories {
        maven {
            url "https://gitlab.com/api/v4/projects/zzz/packages/maven"
            credentials(HttpHeaderCredentials) {
                name = "Private-Token"
                value = GITLAB_PERSONAL_TOKEN
            }
            authentication {
                header(HttpHeaderAuthentication)
            }
        }
    }
}

Note that zzz refers to the project ID. This is the numeric ID from your gitlab main page.

One other thing I needed to do was upgrade to gradle version 5.5 in the gradle-wrapper.properties. Not doing this meant gradle couldn't find HttpHeaderCredentials.

You now need to go into GitLab and generate an access token. You do this is the user settings (not the project settings) and ensure the API access level is ticked. Copy the access token and add it to your gradle.properties file.

GITLAB_PERSONAL_TOKEN=xxx

That should be all you need. Clean, build and assemble your library and then run the gradle publish command. Your aar should be deployed to GitLab packages and it should now be ready for downloading. You can check in your GitLab packages section and you should see the details displayed there.

Now we goto our client, the app that is going to download and read our worst ever library. We open up our gradle file and add the following:

buildscript {
    repositories {
        google()
        jcenter()
        maven { url 'https://maven.google.com'}
        maven {
            url 'https://gitlab.com/api/v4/projects/zzz/packages/maven'
            credentials(HttpHeaderCredentials) {
                name = "Private-Token"
                value = GITLAB_PERSONAL_TOKEN
            }
            authentication {
                header(HttpHeaderAuthentication)
            }
        }
    }
}

allprojects {
    repositories {
        maven { url 'https://maven.google.com' }
        maven {
            url 'https://gitlab.com/api/v4/projects/zzz/packages/maven'
            credentials(HttpHeaderCredentials) {
                name = "Private-Token"
                value = GITLAB_PERSONAL_TOKEN
            }
            authentication {
                header(HttpHeaderAuthentication)
            }
        }
    }
}


Lastly we add in our dependency and we should be away:

implementation 'com.test:worstlibever:1.7'

That's it, happy coding!








25 January 2012

Assigning your GoDaddy domain name to your Amazon S3 bucket

In the previous post we setup a static website using Amazon Web Services (AWS) S3 bucket storage. Now we’re going to assign the fancy new godaddy domain we just bought to that bucket.
You will need:
    - A GoDaddy Domain
    - An working S3 bucket hosting your website

1. Bucket Name
First and foremost in the last post we named our bucket whatever we want. In this post it’s crucially important we are very careful with what we name our bucket. Amazon gets the bucket name to use from the URL, so you’ll need to match your domain with your bucket name. For example if my domain was www.mygreatwebsite.com you would need to make sure your bucket was called www.mygreatwebsite.com So if you haven’t already done that, go ahead and create a new bucket. You can easily copy and paste your files across from your old bucket. Of course make sure it’s setup as a website all works with the S3 URL.

2. GoDaddy Domain Manager
First we need to open what GoDaddy call the zone manager, there may be better ways to find it but here’s how i get there. Open godaddy.com, hover the mouse over Domains and click “Domain Manager” and login. Hover over Tools and click “DNS Manager”. In the list of your domains click “Edit Zone” next to your domain. You’ll see a bunch of information here, but in short you’re looking under the CNAME heading for www. By default it’s value is @. You need to remove this at symbol and change it to: mygreatwebsite.com.s3-website-eu-west-1.amazonaws.com
Obviously replacing the url with the one for your S3 bucket. Especially the “eu-west” bit and the mygreatwebsite.com with yourgreatwebsite.com and save. This is where the name of your bucket we mentioned in step one becomes so important.

You may want to check you don’t have forwarding turned on. The first time I set this up I just used domain forwarding, which is a neat and easy to use feature, but it just creates an iframe for your site, which won’t help your SEO one little bit. That said, it is a very quick and simple to use feature of GoDaddys. You can turn domain forwarding on and off in the DSN manager using the forward button at the top.

If you own http://mysite.com and http://www.mysite.com then (I believe) you have to either setup two buckets one called mysite.com and one called www.mysite.com or of course you could forward one domain to the other.

That’s it, sit back and be patient, domain changes can take a few hours to process so go buy some donuts and cross your fingers. Hopefully that all worked like a dream.

I owe a lot to this guy, Aaron Blohowiak and his excellent blog entry: http://aaronblohowiak.com/using-amazon-s3-and-cloudfront-to-host-a-stat

and also this this one by Steve Liles:
http://steveliles.github.com/pointing_a_domain_name_to_an_amazon_s3_bucket.html