The Unbearable Stupidity of Modeling - a talk by Ed Merks

"Unbearable stupidity of Modeling" is the name of a 50 minute long tech talk to be given by Ed Merks himself at EclipseCon 2009. Choosing such a title is a very good example of Reverse Engineering ... that is ... accept the mis-conception before disproving it! In this case it may be an attempt to clear out some of the so-called disadvantages or problems with using EMF.

I was just browsing around on some of the talks in the EclipseCon website and I found this. The heading of Ed's talk makes a bold statement, and so does almost all of the content in the abstract. If a guy who is using EMF in his projects/requirements reads through the abstract will be taken slightly aback by the tone except for one last line which changes the tone completely. Nice trick to make people read on ;)

I so want to listen to Ed speak about this topic ... given the different nature of the abstract itself the whole topic ... i think will be an eye opener for many of us. People who have an oppurtunity to attend EclipseCon ... don't miss this talk! You can find the abstract here.
Can't wait for the content of the talk to come out ... coz I cannot make it to EclipseCon (the reason is simply complicated ;)

Manage Extension Locations in Eclipse Ganymede

    An Eclipse developer is very quick to spot the very visible difference in the new Ganymede release. We are used to download an IDE and customize the configuration using the Help -> Software Updates -> Manage Configuration. Guess what! there is no more a Manage Configuration option anymore in Ganymede. Instead its called Software Updates for Installed Software and Available Software.

   It looks kinda complicated at first, let's see how do u Manage Configuration in Eclipse Ganymede. This article gives a clear picture.

Save an EMF Resource with or without namespace!

  We tried out this one somewhere in 2007, but i suddenly felt the need to write about it now( i dono, funny like that!). Well coming to the point... serializing an EMF Resource to an XML file actually seems strange but sometimes it becomes necessary. I'll not get into the details of why do we need an XML file with no namespace! and just tell you how to do it.

  When an XML file is parsed using Resource API, for every XML element a corresponding model element is searched from an EPackage instance. This EPacakge instance is normally registered to an namespace URI. For eg. <myns:SHIPORDER>  XML element may map to an EClass ShipOrder in the model and myns URI is registered to an instance of ShipOrderPackage.  So when the SHIPORDER XML element is encountered Resource API understands that an object of type StudentType is to be created.

  Now, what if the XML element has no namespace... it'll look like this: . If we want to continue the usual way, then we have to do:

• Register the EPackage instance to an empty namespace URI.
  
• extend the XMLHelperImpl class and override getQName(EPackage, String, boolean) method
• bind this XMLHelper implementation to your model's generated XyzResouceImpl through createXMLHelper() method.

The first point is quite straight forward. Although its better to register ur EPackage instance to both empty as well as the required namespace URI. For the second one, you need to extend the class org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl and override the method specified above to suit ur requirements. Here's an example (considering the good old ShipOrder schema model)

/**

 * let's save without namespace!

 * just delegate to appropriate Resouce API 

 *

 */

public class ShipOrderXMLHelper extends XMLHelperImpl {

protected String getQName(EPackage package1, String name,

boolean mustHavePrefix) 

{

   if( isNameSpaceNeeded() ) {

    // let's send what ever prefix that's got as the arguement

    return super.getQName(package1, name, true);

   }

   else {

    // i don't want a namespace prefix 

    return super.getQName(package1, name, false);

   }

            return "";

}

}

  Now that we have our implementation of XMLHelper, let's bind it to the generated ShipOrderResource implementation.

/**

 *

 * The Resource associated with the package.

 *

 * @see org.example.shiporder.util.ShiporderResourceFactoryImpl

 * @generated

 */

public class ShiporderResourceImpl extends XMLResourceImpl {

/* (non-Javadoc)

* @see org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl#createXMLHelper()

* an override to bind our helper implementation

*/

protected XMLHelper createXMLHelper() {

return new ShipOrderXMLHelper();

}

    // other generated ShipOrderResouceImpl methods follow.        

} //ShiporderResourceImpl

   That's it you are all set to serialize an EMF resource without namespace. Before you go for a coffee ... one last thing ... do not forget to create ur EMF resource from the generated XyzResourceFactory.

Back To Basics!

Some interesting articles about basics that an eclipse (or a Java) developer must know.

1. Let's start with the classpath itself!
> Here's an interesting article on IBM Developerworks by Elliot Harold. Good read this one.