The following is a summary of the plugins proposed by the article. Of course all of them are opensource/free.

The full IBM article can be found here: http://www.ibm.com/developerworks/java/library/j-ap01117/


Exception in thread "main" java.lang.AbstractMethodError: org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at org.apache.commons.configuration.XMLConfiguration.save(XMLConfiguration.java:880)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration$FileConfigurationDelegate.save(AbstractHierarchicalFileConfiguration.java:454)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:546)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:513)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:491)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:403)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.save(AbstractHierarchicalFileConfiguration.java:199)


After doing some search on google I found that this can be a problem with the xerces XML library (xercesImpl.jar). Checking the 3rd party libraries I am using in my project, I found a library that was using and distributing an earlier version of xercesImpl.jar.

I downloaded the latest version (2.91) of xercesImpl.jar from the Apache xerces project (http://xerces.apache.org/mirrors.cgi#binary) and replaced in the 3rd party library I was using the xercesImpl.jar file with the one I downloaded. Now everything seems to work fine, even in Java 1.6. 

Today I read an article in ComputerWeekly that there is a shortage of .NET skills (http://www.computerweekly.com/Articles/2007/09/03/226513/employers-struck-by-shortage-of-.net-skills.htm)

It would be interesting to work on a contact .NET project and see the potential of applying Model Driven techniques in practice… But I guess I will have to find some time to study for the certification first.

The error was something about java inconvertible types. I don’t know if it is the new version of eclipse or Java 1.6. Looks like for some reason the compiler doesn’t recognise that Rule.class is of type Class<? extends Rule<S, T>>, so as to call the public <S, T> T transform(Class<? extends Rule<S, T>> ruleType, S source)

A simple solution is to ct the Rule.class expression to Class (it sounds weird but it worked).

So the transform and transformAll methods become:


public Object transform(Object object) {
Class r = Rule.class;
return transform(r, object);
}
public List<? extends Object> transformAll(List<? extends Object> sourceObjects){
Class r = Rule.class;
return transformAll(r, sourceObjects);
}


However, Alloy v4.0 has been developed from scratch and it is based on the kodkod model finder. The AST implementation has changed substantially and the convenience methods provided on the AST model elements are fine tuned for the Alloy compiler. For example Signature constructors are private and I couldn’t find a way to update the properties of Signatures (i.e. the Multiplicity of the Signature) after a Signature has been created.

Of course this is perfect if you have an Alloy model and you just want to parse, but not very convenient if you use an MDA approach to instantiate Alloy AST objects. For example in UML2Alloy you can change the Multiplicity of a Signature (i.e. change from set to some to enforce that some Signature instances will exist in the model). If you don’t have access to the Multiplicity attribute of the Signature class, after the object has been created, complicates the situation.

Moreover the AST class elements have been defined as final so there is no way you can override the Alloy v4.0 AST classes.

So, I spent almost 1 day evaluating the situation and trying to find a solution. One solution would be to create my own implementation of Alloy’s AST. Another would be to create wrapper classes of Alloy’s AST that will have pointers to the actual Alloy implementation.

Then I stepped back and thought about the siltation. Well, I already have a rather stable implementation that uses Alloy v3.0 AST. In Alloy v4.0 the AST has NOT changed. Just the concrete syntax. So the solution is easy.

Currently in UML2Alloy after the Alloy AST objects have been generated by SiTra, a visitor is used to create a text file that contains the Alloy model. So, all I have to do is use another visitor and override the methods that create the part of the model for which the concrete syntax has changed.

For the time being I am thinking of working in my spare time for the MCPD: Web Developer certification. The main reason for this is that I need to get my mind off the PhD from time to time. I also have a free copy of VS 2005 Professional, when I attended the launch tour, so practising for the exams shouldn’t be a problem. My plan is to be ready for the first exam by sometime at the end of August. Let’s see if I can make it!

The file can be found at: http://www.codegeneration.net/audio/cgn-episode1.mp3