Archive

Archive for March, 2010

Git Internals – a diagram

March 31, 2010 Leave a comment

A beautiful diagram from Git Internals:

Highly recommended! Both PDF and screencast are really good.

Advertisements
Categories: Git Tags:

Hudson: Git and Maven plugins

March 27, 2010 7 comments

Suddenly, something went wrong .. 😦
A usual Hudson job pulling sources from Git repository started to fail with NPE:

Parsing POMs
[nexttags-CI] $ c:\Winny\java\jdk1.6.0_18\/bin/java -Xmx1024m -XX:MaxPermSize=512m -cp c:\dev\hudson-slave\maven-agent.jar;C:\Winny\java\apache-maven-2.2.1\boot\classworlds-1.1.jar hudson.maven.agent.Main C:\Winny\java\apache-maven-2.2.1 C:\dev\hudson-slave\slave.jar c:\dev\hudson-slave\maven-interceptor.jar 3841 c:\dev\hudson-slave\maven2.1-interceptor.jar
<===[HUDSON REMOTING CAPACITY]===>channel started
channel stopped
ERROR: Processing failed due to a bug in the code. Please report this to users@hudson.dev.java.net
java.lang.NullPointerException
	at java.util.Hashtable.put(Hashtable.java:394)
	at java.util.Hashtable.putAll(Hashtable.java:466)
	at hudson.maven.MavenBuilder.call(MavenBuilder.java:156)
	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:688)
	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:632)
	at hudson.remoting.UserRequest.perform(UserRequest.java:114)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:270)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

What ?! But it worked half an hour ago. Hmm, that’s interesting …

After re-installing Hudson from scratch, installing it locally on my machine, going back and forward with versions, creating simple jobs doing absolutely nothing except pulling sources from various Git projects and running "mvn clean" .. I still couldn’t git rid of this error.

Well, it was clearly time for some debugging and .. here we go!

For some reason Git plugin started to pass null value for GIT_BRANCH environment variable.
This caused Maven plugin to fail in System.getProperties().putAll(systemProps) call.

The solution was to use "master" as default Git branch instead of "**" or empty String:

My versions were: Hudson v1.352, Git plugin v0.8.1

P.S
Some Hudson links:

Categories: Git, Hudson, Maven Tags: , ,

Multi-level ternary operator

March 24, 2010 Leave a comment

Love one. Can’t be easily debugged, probably .. But reads very nicely:

String getScmClass()
{
    ( this.@scmClass == 'svn' ) ? 'hudson.scm.SubversionSCM'  :
    ( this.@scmClass == 'git' ) ? 'hudson.plugins.git.GitSCM' :
                                  null
}

Still, standard mapping is usually better – it allows to dump all known options:

Map    scmClasses = [ svn : 'hudson.scm.SubversionSCM',
                      git : 'hudson.plugins.git.GitSCM' ]
String getScmClass()
{
  def    scmClass = scmClasses[ this.@scmClass ]
  assert scmClass, "Unknown [${this.@scmClass}]. Known classes are ${scmClasses.keySet()}"
         scmClass
}
Categories: Groovy Tags: ,

Moving to a private WordPress hosting

March 22, 2010 Leave a comment

I think I will be moving to a private WordPress hosting within time.
The problem with WordPress.com is that it:

  • .. is annoyingly slow oftentimes.
       There were cases when “Update” operation just stuck for no reason and I had to repost
       the whole article.
  • .. doesn’t allow to install any custom plugin, theme or widget

I mean, it’s good as a free service but from all SaaS-es I’ve met recently – this one definitely needs to go more personal, so I’m giving DreamHost a try now. Any other recommendations may be?

But, of course, I wouldn’t like to lose WordPress.com community and auto-generated links service so I’m planning to repost everything here from my personal WordPress setup.

Categories: Web Tags:

Using Groovy++ with Maven – an update

March 22, 2010 2 comments

In his comment to “Using Groovy++ with Maven” Joern Schimmelpfeng has correctly pointed out about transitive dependencies that may be added to groovypp POM, eliminating the need to specify them explicitly.

He’s right! That’s what we have Maven dependencies mechanism for.

It is now fixed so you can use

<dependency>
    <groupid>org.mbte.groovypp</groupid>
    <artifactid>groovypp-all</artifactid>
    <version>0.2.0</version>
</dependency>

or

<dependency>
    <groupid>org.mbte.groovypp</groupid>
    <artifactid>groovypp</artifactid>
    <version>0.2.0</version>
</dependency>

Full examples:

Now it looks practically the same – what’s the difference then?

As previously, groovypp-all.jar contains all required libraries, repackaged in one jar:

In addition to groovy ("groovy", "org.codehaus.groovy" packages) and groovypp ("org.mbte.groovypp" package) it also contains antlr, asm, commons-cli and junit libraries, some of which are stored under modified package names to avoid collisions with libraries that may be available already in your project.

groovypp.jar is bound to all above libraries in separate jars, as declared by its <dependencies>.

Which one to choose then?

  • If your application has already declared <dependency> on either antlr or asm and you
       don’t like them packaged twice (note, even in this case – there are no collisions due to
       packages modified), then you can choose the groovypp version.
     
       It usually works better in IDEA project as it doesn’t recognize "groovypp-all" jar as
       Groovy and tries to search for it elsewhere.
     
       Note: sometimes you may need to add an explicit junit:4.7 dependency, otherwise
       Maven brings old 3.8.2 JUnit version lacking classes required for Groovy++ compilation.
       It can be seen in groovypp example above, see the diff of switching from "groovypp-all"
       to "groovypp".
     
  • If you just want to just use Groovy++ without dealing with JUnit versions and you
       experience no Groovy-related IDEA problems – you can use groovypp-all.
Categories: Groovy, Maven Tags: , , ,

Git GUI Here

March 20, 2010 Leave a comment

Rather than right-clicking the folder and choosing “Git GUI Here” ..

"git-gui.bat":

@echo off
start d:\winny\Git\bin\wish.exe d:\winny\Git\libexec\git-core\git-gui --working-dir %*

assuming msysgit is installed at "d:\winny\Git"

Now, I only need to type "git-gui ." to launch it:

Much better. Hate it when someone forces me to use a mouse ..

Categories: Git, PC Tags:

Using Groovy++ with Maven

March 18, 2010 11 comments

Note, an update is available.

Groovy++ artifacts are now deployed in Maven repository at:

http://groovypp.artifactoryonline.com/groovypp/libs-releases-local/
and
http://groovypp.artifactoryonline.com/groovypp/libs-snapshots-local/

 

So you can compile your Groovy++ sources with Maven.
As in Groovy, where you pick up either groovy.jar or groovy-all.jar – you can do the same here:

  • Use groovy + groovypp + asm + antlr + commons-cli:
     
    <dependency>
        <groupid>org.codehaus.groovy</groupid>
        <artifactid>groovy</artifactid>
        <version>1.8.0-beta-1-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupid>org.codehaus.groovy</groupid>
        <artifactid>groovypp</artifactid>
        <version>0.1.18</version>
    </dependency>
    <dependency>
        <groupid>asm</groupid>
        <artifactid>asm-all</artifactid>
        <version>3.2</version>
    </dependency>
    <dependency>
        <groupid>antlr</groupid>
        <artifactid>antlr</artifactid>
        <version>2.7.7</version>
    </dependency>
    <dependency>
        <groupid>commons-cli</groupid>
        <artifactid>commons-cli</artifactid>
        <version>1.2</version>
    </dependency>
    

  • Use groovypp-all:
     
    <dependency>
        <groupid>org.codehaus.groovy</groupid>
        <artifactid>groovypp-all</artifactid>
        <version>0.1.18</version>
    </dependency>
    

As you see, the second way is much simpler so I suggest you stick to “groovypp-all”. It’s the same as a longer version but with all required libraries packaged nicely in one bigger jar. 

Of course, you’ll need to instruct Maven about repository:

 
    <properties>
        <repo>http://groovypp.artifactoryonline.com/groovypp</repo>
    </properties>


    <repositories>
        <repository>
            <id>libs-releases</id>
            <url>${repo}/libs-releases</url>
        </repository>
        <repository>
            <id>libs-snapshots</id>
            <url>${repo}/libs-snapshots</url>
        </repository>
    </repositories>


    <pluginrepositories>
        <pluginrepository>
            <id>plugins-releases</id>
            <url>${repo}/plugins-releases</url>
        </pluginrepository>
        <pluginrepository>
            <id>plugins-snapshots</id>
            <url>${repo}/plugins-snapshots</url>
        </pluginrepository>
    </pluginrepositories>

.. and configure GMaven plugin:

 
            <plugin>
                <groupid>org.codehaus.gmaven</groupid>
                <artifactid>gmaven-plugin</artifactid>
                <version>1.2</version>
                <executions>
                    <execution>
                        <id>compile-groovy</id>
                        <phase>process-sources</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <providerselection>1.7</providerselection>
                            <verbose>true</verbose>
                            <debug>true</debug>
                            <stacktrace>true</stacktrace>
                            <sources>
                                <fileset>
                                    <directory>${project.basedir}/src</directory>
                                    <includes>
                                        <include>**/*.groovy</include>
                                    </includes>
                                </fileset>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupid>org.codehaus.gmaven.runtime</groupid>
                        <artifactid>gmaven-runtime-1.7</artifactid>
                        <version>1.2</version>
                        <exclusions>
                            <exclusion>
                                <groupid>org.codehaus.groovy</groupid>
                                <artifactid>groovy-all</artifactid>
                            </exclusion>
                        </exclusions>
                    </dependency>
                    <dependency>
                        <groupid>org.codehaus.groovy</groupid>
                        <artifactid>groovypp-all</artifactid>
                        <version>0.1.18</version>
                    </dependency>
                </dependencies>
            </plugin>

Full examples:

If you didn’t do so yet – you’re welcome to join a community to take part in Groovy++ discussions and be notified about new releases (@groovypp is available as well).

Also, you can follow Alex Tkachman who is Groovy++ inventor at @alextkachman and DZone.