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).

Translate statuses in JIRA

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.

Add properties to transitions

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:

Translated Transition

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.

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?).

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.

The Sample

There are a sample project to this article. You can download it here. The sample is an Eclipse Project. You need at least 3 plugins to get the sample running:

• SpringIDE (http://springide.org/updatesite)
• GroovyIDE (http://dist.codehaus.org/groovy/distributions/update/)
• Maven Integration (http://m2eclipse.sonatype.org/update/)

Additional to these plugins it is recommend to install a native Maven from http://maven.apache.org. The embedded Maven of the Maven Integration sometimes have problems with Groovy-based tests. To enable another Maven Installation you can add it in the Preferences (Window -> Preferences -> Maven -> Installations). After you have prepared your Eclipse you can import the sample and run it with Run As -> Maven install.

Spring and Annotations

Spring supports a lot of annotations. Additional to the standard Java 6 annotations like (@Resource, @PostConstruct, @PreDestroy,…) there are a number of Spring-Annotations:

• @Autowired – injets a resource byType or byName
• @Required – marks a property as mandatory
• @Component – marks a class as Component. This you need for @Resource, @Autowired
• @Service – similar to @Component
• @Controller – marks a class as Controller for SpringMVC
• …

If you want to use dependency injection with annotations you can

package testprojects.spring.annotations;

import javax.annotations.Resource;

public class Demo{
  @Resource(name="otherResource")
  private Other resource;
}

In this case the Java field named with resource should get a reference to another bean with the symbolic name otherResource. To get this work you must define a bean with this symbolic name:

import org.springframework.stereotype;

@Component("otherResource")
public class Other{}

Now we have configured our classes with annotations. But Spring doesn’t know that he should scan our classes for annotations. This we can do with the element context:component-scan in an applicationContext.xml:

At the start of the ApplicationContext of Spring all classes in the package testprojects.spring.annotations will be scanned for annotations. If Spring found any the context will be build – similar to the XmlApplicationContext

.

The Problem

If you take a closer look at the class Other you will see the import of¬† org.springframework.stereotype. This will make the class depend to the Spring Framework. Thats very bad, because we won’t have such a dependency. But what we can do? The solution is quite simple. Let us define our own annotation for this case and re-configure Spring in that way that our annotation instead teh Spring one will be used to mark classes as Components. The definition of the annotation is simple and a one-to-one copy of the original annotation provided by Spring:

package testprojects.spring.annotations;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.springframework.stereotype.Repository;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Component {

  /**
  * The value may indicate a suggestion for a logical component name, to be
  * turned into a Spring bean in case of an autodetected component.
  *
  * @return the suggested component name, if any
  */
  String value() default "";
}

The next step is to tell Spring that he doesn’t use its own @Component-Annotation but our annotation. This can do with the context:component-scan element, too:

The important changes are the attribute use-default-filters. If you set this to false, Spring ommit his own annotations. In this case you can define you own annotation classes with the context:include-filter element.

And now… a sample

Now we want it get together. To demonstrate the mechnism we want to create an own Annotation as replacement for the Spring @Service-Annotation. Then we mark a PoJo with this annotation and write a Unittest to verify that Spring use this class as Spring-Bean.

1. Create the Service-Annotation

package testprojects.spring.annotations.Service;

@Target( { ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface MyService {

  /**
  * The value may indicate a suggestion for a logical component name, to be
  * turned into a Spring bean in case of an autodetected component.
  *
  * @return the suggested component name, if any
  */
  String value() default "";
}

2. Add this annotation to our class

import testprojects.spring.annotations.Service;

@MyService
public class ServiceBean {

}

3. Re-configure Spring to use the @MyService-Annotation

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xmlns:p="http://www.springframework.org/schema/p"
   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
   http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

   <context:component-scan
     base-package="testprojects.spring.annotations" use-default-filters="false">
     <context:include-filter
         expression="testprojects.spring.annotations.Service"
         type="annotation" />
    </context:component-scan>
</beans>

4. Write a Unittest to verify that Spring is using the annotated class as SpringBean

@RunWith(SpringJUnit4ClassRunner)
@ContextConfiguration
public class ServiceAnnotationTest{

  @Autowired
  ServiceBean serviceBean

  @Test
  final void testServiceAnnotation(){
    Assert.assertNotNull(serviceBean)
  }
}

bcbcbc