Publish an artifact to a Maven repository using Gradle

I have been using Gradle as a build tool for my Java/Groovy/Scala projects in the last 12 months and I'm very happy with it.

I'm not going into a full description of Gradle, there are plenty of resources available on the Internet praising this awesome build tool. If you don't know it already, I really recommend considering it for your next project.

One of the very attractive features of Gradle, is the seamless integration with Maven repositories. You can easily declare your dependencies as belonging to a Maven repository or to a file based repository.

Similarly, you can upload artifact to a Maven repository with very little code. The following is an example of a Java project build file producing a jar file that gets uploaded to an Apache Archivia Maven repository. For some reasons, I couldn't find a complete example in the (otherwise exceptional) documentation, so I thought to post it here as a reference. 



apply plugin: 'java'
apply plugin: 'maven'


// Project configuration is used for Maven deploy:
version = '1.0-SNAPSHOT'
group = 'io.fiandes.sandbox'


configurations {
     deployerJars
 }


repositories {
     mavenCentral()
 }


dependencies {
   compile 'com.google.guava:guava:r07'
   deployerJars "org.apache.maven.wagon:wagon-webdav-jackrabbit:1.0-beta-6"
}


 


uploadArchives {
    repositories {
        deployer = mavenDeployer {
            uniqueVersion = false
            configureAuth = {
                authentication(userName: 'user', password: 'password')
            }
            configuration = configurations.deployerJars
            snapshotRepository(url: "dav:http://192.168.1:1:8080/archiva/repository/snapshots/", configureAuth)
            repository(url: "dav:http://192.168.1.1:8080/archiva/repository/internal/", configureAuth)
        }
    }
}

The dependency on 
"org.apache.maven.wagon:wagon-webdav-jackrabbit:1.0-beta-6"

is needed because Gradle doesn't quite know how to handle the WebDav protocol.

The Google Guava dependency is there as an example, it is not needed for the Maven publishing purpose.

Finally, the "uniqueVersion = false" flag is needed to avoid Gradle to create weirdly named artifacts. The most interesting thing here, is that Gradle will generate the Maven POM for you and upload it to the Maven repository. 

Another very cool feature is the automatic uploading to the correct repository depending on the version name. If the version name ends with "SNAPSHOT" (capital letters), Gradle will automatically upload the artifact to the repository "snapshotRepository". If the version is not marked as SNAPSHOT, it will be uploaded to the regular releases repository.

 

Start Oracle Weblogic Server 11g as a Windows Service

Oracle Weblogic Server 11g (10.3.x) doesn't offer any simple way to start the Weblogic domain as a Windows service.

Oracle documentation about setting up a Windows service is here: http://download.oracle.com/docs/cd/E12840_01/wls/docs103/server_start/winservice.html

Unfortunately, the documentation is wrong (at least using version 10.3.3) and the Windows service doesn't start after following Oracle instructions.

This is the script that I have used to succesfully run a Oracle Weblogic Domain as a Windows service:



echo off
 SETLOCAL
 set DOMAIN_NAME=mydomain
 set USERDOMAIN_HOME=C:\bea_domains\mydomain
 set SERVER_NAME=AdminServer
 set PRODUCTION_MODE=false
 set JAVA_VENDOR=BEA
 set JAVA_HOME=C:\Oracle\Middleware\jrockit_160_17_R28.0.0-679
 set MEM_ARGS=-Xms256m -Xmx512m
 set WLS_USER=weblogic
 set WLS_PW=123456790
 call "C:\bea_domains\mydomain\bin\setDomainEnv.cmd"
 call "C:\Oracle\Middleware\wlserver_10.3\server\bin\installSvc.cmd"
 ENDLOCAL
 

Notes:

DOMAIN_NAME: the name of your domain (really?)

USERDOMAIN_HOME: full path to your domain

SERVER_NAME: if you create a domain using the Bea tool, the standard name is always AdminServer.

WLS_USER, WLS_PW: these should not be necessary, but doesn't harm to add them

The trick here is calling "setDomainEnv" before the call to the Service creation script.

Fix "Same Policy Origin" errors in Chrome

So, say your are writing some Javascript code and you want to POST a form using AJAX. There are plenty of ways for doing that, using JQuery you can do something like: 

$.post("http://someremoteserver:9001/customer/create", $("#customerForm").serialize(), function(data){


... do stuff with the POST result.


}, "json");


 

If you try to POST to a server that is different from the one your page is originating from, you will incur in the infamous Javascript error:

XMLHttpRequest cannot load http://someremoteserver:9001/customer/create. Origin http://localhost:9000 is not allowed by Access-Control-Allow-Origin.
 

This error comes from the Same-Origin policy:

The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin. This policy dates all the way back to Netscape Navigator 2.0.

For testing purposes, you can easily disable this security features in Chrome, starting the browser with the flag:

--disable-web-security
 

In Windows, you can simply add the flag to the Chrome shortcut. On Mac, you can open Terminal and run:

 

open -b com.google.chrome --args --disable-web-security

Please, be aware that this solution has to be used as a temporary fix to a local development environment issue. For production, I recommend reading this Stackoverflow entry about production grade solutions to Same-origin policy errors.

Start a Cygwin session from Total Commander

When starting with a new Windows laptop there are a bunch of softwares that I install automatically. Among those, I have Total Commander and Cygwin.

Total Commander is a highly configurable, dual paned, file manager for Windows. It's the most awesome piece of software you can install on your Windows box. The real fun with TC comes with the customization.

One of the aspects you can customize, is assigning hot keys to specific commands, for instance opening a Cygwin terminal in the same folder where TC is open.

Those days, the default terminal that comes with Cygwin is Mintty (here are the 9 reasons you should use Mintty instead of the default Cygwin terminal). So, to open Mintty in the same folder where TC is open you have to follow those steps:

  1. Open TC, Configuration -> Misc.
  2. In the "Redefine Hotkeys" section, select the hot key you want to associate to the action (mine is WIN+ALT+D)
  3. Click on the magnifying glass icon near "Command" 
  4. In the "Category" list, scroll down to the "usercmd.ini" line and click on the button "New..."
  5. Give a meaningful name to the command (mine is cm_opencygwin)
  6. In the following window, enter the following string into the "Command" box:

        d:\cygwin\bin\mintty.exe -e d:\cygwin\bin\bash -c "/bin/xhere /bin/bash.exe '%L'"    

Please note that you should change the location of your mintty executables.

That's pretty much it!