Thorsten Kamann

If you are using the famous Issue tracker JIRA by Atlassian you are able to change the workflow. Workflows are used to define the status an issue can get. Between the 2 statuses there are a transition. In JIRA you can translate the statuses (Administration | Status | Translate).

But for transitions there is not such a dialog. But there is an solution for this. You can modify the language property file. If you use an script you can do this automatically. But one step after another

1. Locate the language library

In JIRA all language files are bundled in a library. This library you find in WEB-INF/lib in your JIRA installation.For the german translation the library is named language_de_DE.jar.

2. Extract the JAR and edit the JiraWebActionSupport_de_DE.properties

The JiraWebActionSupport_de_DE.properties is in the package com/atlassian/jira/web/action. You can edit this file with a simple editor. For every transititon you must add one or two properties:

• for the title
• for the submit button, if you transition needs a dialog (e.g. the reopen issue has a dialog where you can leave a comment)

For instance you have a transition Test Issue. This transition doesn’t need a dialog. So you need only one property:

testissue.title=Testen

As an exteded example you have a transition named Issue tested. For this you need a dialog the user can leave a comment. In this case you need 2 properties:

issuetested.title=Getested
issuetested.submit=Test abschliessen

After you finished the modification you can repackage the JAR.

3. Restart JIRA

This you should really do before you start with the next steps.

4. Add the needed properties to the transitions

The next step is to create a relation between JIRA and the properties. This can be done in the panel for modifying transitions (Administration | Workflows | Steps (of the workflow you want to change) |  Click on the transition | Properties of the transition). In the page loaded then you can add the needed properties.

What you need to add is a key-value pair. The key is for JIRA. With this key JIRA knows what kind of i18n text this property represents. The both relevant key are:

• jira.i18n.title (for the title)
• jira.i18n.submit (for the submit button)

As value you can add the properties you add to the language file (JiraWebActionSupport_de_DE.properties). After you are done you can close every dialog and activate the workflow.

As a result you see something similar to this:

Hmm…there are many steps…is there a chance to simplify this?

Yes, of course. You can create a script to do this automatically. For example I have one written in Groovy doing all steps automatically:

//Points to the language_de_DE.jar
def langPack = new File("...")
 
//Points to the folder the modified JAR should be copied to
def targetDir = new File("...")
 
//Points to the folder the langPack should be extracted to
def tempDir = new File(System.properties["java.io.tmpdir"]+"/language_pack")
 
def langFile = new File(tempDir, "com/atlassian/jira/web/action/JiraWebActionSupport_de_DE.properties")
 
//Create the antbuild for some common tasks
def ant = new AntBuilder()
 
if (tempDir.exists()){
    ant.delete(dir:tempDir)
}
 
ant.mkdir(dir:tempDir)
ant.unzip(src:langPack, dest:tempDir)
 
//Using Groovy's multiline strings
def t = """
issuetested.title=Getested
issuetested.submit=Getested
"""
 
//Append the existing content with our extended properties
langFile.text = langFile.text + t
ant.zip(basedir:tempDir, destfile:new File(targetDir, "language_de_DE.jar"))
ant.delete(dir:tempDir)
 
//Build JIRA
"cd /opt/jira".execute()
"build.bat".execute()
 
//Restart Tomcat
"cd /opt/tomcat/bin".execute()
"catalina.sh start".execute()

With this simple script you can do all steps automatically. One thing isn’t really nice. The properties you append to the original languagge file are saved in the script. This should be changed if there are more than a handful properties.

This article is about the managing of Domainobjects with the Spring Framework. Domainobjects are often initilized with the new keyword. This avoids the usage with Spring, because there aren’t Spring Beans. But with AOP and the @Configurable Annotation of Spring you can manage these objects too.

This article is in german and published at Jaxenter.
You will find them here: http://it-republik.de/jaxenter/artikel/Mit-Spring-und-AOP-Domaenenklassen-verwalten-2644.html

Certainly you know that Groovy is one of the dynamic languages published in the last years. There are some languages with this approach: Ruby, JRuby, Python, PHP, JavaScript and many more.

Groovy is a little bit special if you are a Java-Developer. Groovy is built on the top of the Java-Platform. So it is easy to learn the concepts and syntax of this nice language. Aside of powerful syntax enhancements there are the dynamic approach. With the Meta Object Protocol (MOP) you are able to analyze and change every Object.

Getting all properties of an Object

Properties in Groovy are a little bit special. In difference to fields a property always have a Getter-/Setter-Method. It is very easy to get all of such properties:

def someObject = new SomeJavaObject()
someObject.metaClass.getProperties().each{
    println it.name
}

With this codefragment you get a list of all properties of the Object someObject. The content of this list are groovy.lang.MetaBeanProperty. With this class you can

• get and set the field
• get and set the Getter and Setter separately
• query for a special property

You can see in Picture 1 the Classdiagram of the MetabeanProperty class. With the help of this class you can easily analyze and change existing Groovy classes.

Picture 1: Classdiagram of groovy.lang.MetaBeanProperty

What is a MetaClass?

Every Class has some meta informations. This are informations about fields, properties and methods. Additionally it exists an invokeMethod. This method is used to call dynamically methods of Groovy Classes. The behaviour of this method is similar to the Reflection mechnism of Java (you know the package java.lang.reflect?).

Picture 2: Classstructure of groovy.lang.MetaClass

Dynamically adding method to classes

With the help of this class you are able to add new methods to an existing class. Even final (and immutable) classes could be extended:

String.metaClass.toFirstUpper << {
	delegate[0].toUpperCase() + delegate.substring(1)
}

This little fragment adds one method to the final class java.lang.String. After this code is executed you can access this from your¬† Groovy Code. Please attend that this only works if you are calling the additional methods from Groovy. You cannot call it from your Java Code, because the Compiler doesn’t know anything of this additonally method. But you can use reflection with a simple invokeMethod to use the dynamically added method.

In Groovy you can use the new method directly:

def myString = "thisIsASimpleString"
assert "ThisIsASimpleString" == myString.toFirstUpper()

If you use Java you need to use Reflection

String myString = "thisIsASimpleString";
Method m = String.class.getMethod("toFirstUpper", new Class[]{});
assert "ThisIsASimpleString" == m.invokeMethod(myString, new Object[]{});

Adding static methods

This works for static methods, too.

public class Customer{
   String firstName
   String lastName
}
 
Customer.metaClass.static.create << { String first, String last ->
    new Customer(firstName: first, lastName: last)
}
 
assert "Thorsten" == Customer.create("Thorsten", "Kamann").firstNam

Conclusion

This was Part 1 of Dynamic Groovy. In the next part we see how to add dynamically add constructors, properties, and adding methods to interfaces.

Links

• http://groovy.codehaus.org/ExpandoMetaClass
• http://groovy.codehaus.org/ExpandoMetaClass+-+Methods
• http://groovy.codehaus.org/ExpandoMetaClass+-+Static+Methods

Testgetriebene Entwicklung ist ein Muss, um die Qualität von Software-Produkten zu sichern. Der wohl am schwierigsten zu testenden Teil einer Anwendung ist die Weboberfläche. Oftmals ist es so, dass Oberflächen lediglich manuell getestet werden – mit allen Nachteilen, die manuelle Test mit sich bringen. Das Gespann Selenium, TestNG, Groovy und Maven bietet Ihnen einen Lösungsansatz, mit dem Sie in vertretbarer Zeit automatisierte Tests für Weboberflächen erstellen können. Dieser Vortrag führt Sie anhand einer Webanwendung Schritt für Schritt durch den Prozess, sodass Sie danach mit eigenen Experimenten beginnen können.

In vielen Projekten ist das Spring-Framework das Mittel der Wahl. Zusätzlich werden in vielen Produkten Spring intern eingesetzt. Damit die Arbeit mit Spring uneingeschränkt Spass macht ist es wichtig einige Tricks und Kniffe zu kennen. In diesem Vortrag zeigt Ihnen der Referent, wie Sie effektiv Spring in Ihren Projekten einsetzen können. Die Themenbandbreite reicht dabei vom Tooling über Architekturthemen bis hin zum Testing:

• Spring-IDE: Features und Verwendung
  • Navigation zwischen Beandefinitionen und Code
  • Aspekte
• Architekturen unabhängig von Spring
  • keine HibernateTemplates
  • mein Code kennt nur Standards
  • eigene Annotations anstatt Spring-Annotations
• Testen mit Spring
  • Spring für Unittests
  • Dependency Injection
  • Angepasste Spring-Konfigurationen
  • DAO-Test

Große Entwicklungsabteilungen stehen oft vor dem Problem einheitlicher Entwicklungsprozesse und Werkzeuge. Nach einiger Zeit hat jedes Projekt eigene Prozesse und Werkzeuge etabliert. Dies ist nicht im Sinne der Entwicklungsabteilung. Softwaresysteme müssen i. d. R. über Jahre hinweg gewartet und erweitert werden – oft von einem Team, das sich neu in die Anwendung einarbeiten muss.
Nicht selten stellt die Rekonstruktion der Entwicklungsumgebung einen erheblichen Aufwand dar.

Dieser Vortrag beschreibt – anhand eines Erfahrungsberichts – den Aufbau einer strukturierten Entwicklungsumgebung, die auch für grosse Entwicklungsabteilungen skaliert.

• Zentrale Projekt- und Codeverwaltung (ähnlich wie Sourceforge)
• Buildmanagement mit Maven
• Entwicklungswerkzeuge basierend auf Maven und Eclipse
• Installierbare Teamserver mit Virtualisierungstechnologie für Continuous Integration

The Spring-Framework is a non-invasive framework. This means you can develop pure POJOs without any dependencies to the framework. You don’t need implement any interface nor you need to extend any base classes. However there are a lot of useful classes and interfaces provided by Spring – do you know the HibernateTemplate? – so you can use them if you want but you aren’t forced to use them.

If you remember the Spring 1.x stream without use of these templates make it very difficult to implement DAOs. This is much better with Spring 2 and JPA. For now you need only to inject an EntityManager and use the methods of them. That’s very nice, because of the EntityManager is a class out of the JPA/EJB3 standard.

Since Spring 2 there are annotation support. Not only standardized annotations are supported. Spring provides his own annotations. This is not so nice, because the use of this annotations makes your PoJos depend on Spring.

Continue reading