Archive

Posts Tagged ‘Eclipse’

Eclipse Project Set Editor

January 15, 2013 2 comments

psfeditorAn Eclipse Project Set file (.psf) enables quick export and import of files from a repository like Git, SVN etc. Eclipse currently supports exporting files in a repository as a Project Set file. An editor for an existing PSF file is currently missing. The means updating an existing PSF file (for example, adding a new project, removing an existing project etc.) means editing PSF XML by hand!

The Project Set Editor provides a simple user interface to view and edit PSF files (similar to Manifest Editor or Target Definition Editor). The editor also allows directly importing the artifacts in a PSF file.

You can find the project at Eclipse Labs: http://code.google.com/a/eclipselabs.org/p/psfeditor/

Doors are open for testers and committers.

 

Tags: , ,

2 Fast thrice Furious

August 3, 2011 1 comment

Preparing to make the initial code contribution for RMF, we ran our RIF/ReqIF metamodels through several performance tests. To start with, we tested the load and save times of RIF files based on some industry samples. To get some comparison data, we generated XMI files using the same data held in RIF XML files and tested the load/save time against it. The results are quite promising.

Before we go into the details of the tests, its better to define two components involved in our test comparisons.

  • The customized RIF XML loader (a.k.a RMF Loader) and serializer (a.k.a RMF Serializer) for loading/saving OMG RIF XML files into RIF Ecore metamodel (read more on the metamodel implementation here).
  • The default RIF XMI loader and serializer for  loading/saving RIF XMI files into RIF Ecore model (this is not in the scope of RMF. We use this only to get some comparison).

Here are some highlights from our tests.

  • A 32MB RIF XML file is loaded in 14.4 seconds by RMF loader where as the same data in XMI format is loaded by the default EMF XMI loader in 22.2 seconds (and 70 mins(!!) without any optimizations to the XMI loader)
  • The average time taken to load per MB of data from RIF XML is 0.5 seconds, whereas RIF XMI takes 1.63 seconds per MB. For save, average time taken per MB of data to RIF XML is 0.09 seconds, whereas RIF XMI takes 1.22 seconds per MB
  • The load and save time for RIF XML files by RMF loader/serializer increases linearly with size

Tags: , , , ,

Dissecting RIF/ReqIF metamodel

July 29, 2011 9 comments


RIF/ReqIF is the new OMG standard for requirements interchange. RMF (currently in proposal phase) provides an EMF Ecore based metamodel implementation for the RIF/ReqIF XML format. The metamodel is a clean implementation of the format without any “XML noise”. The Ecore metamodel also conforms to the CMOF metamodel delivered by OMG (as it has been derived from it). The metamodel reads/writes RIF/ReqIF data in conformance with the RIF/ReqIF XML Schema.

The challenge in the Ecore based RIF/ReqIF implementation was the customization of loaders and serializers to make them RIF/ReqIF XML Schema conformant. EMF provides different ways of customizing the XML output.

1. Using ExtendedMetadata annotations.

2. Implementing new XMLLoad, XMLSave and XMLHelper.

Both approaches are quite tricky to implement when the expected XML output has structural differences compared to the Ecore metamodel. For example, the XML output has wrapper elements for lists (ELists) in the Ecore metamodel.

We went in for a third approach.

We imported RIF/ReqIF XML schema using EMF importer to create a RIF/ReqIF XML Ecore model (Anyone who has done this, knows it’s an “ugly” metamodel that EMF generates here). The next step was to create the real RIF/ReqIF metamodel, by importing RIF/ReqIF CMOF file. We then wrote a generic (of course reusable) Ecore XML to Ecore converter to do a model to model transformation in both directions. The whole processing is cleanly hidden in a new EMF Resource implementation such that the user hardly knows anything about these.

The following are the advantages we saw in the approach.

1. You don’t do customizations at a XML level, but at a higher EMF model API level. That is, you don’t hack some XML SAX events, but work with familiar EMF APIs.

2. The generic Ecore converter has enough hooks to plugin in the transformations.

3. Easy maintenance as the customizations are available in one place.

The drawback of this approach could be the processing involved in the model to model transformation. However, the highly optimized model to model transformation we implemented doesn’t make it all that slow. Our performance tests proves this (which would be the topic of my next blog post). It is infact upto 300 times faster than having the same data in the default XMI format (Yes I meant 300! Ed Merks is going to get back to me on this I hope ;) )

Edit:

Ed did get back to me. With the performance optimizations applied to XMIResource loader to use cache for Intrinsic Ids and URIs, the performance improved dramatically. The XMI resource loader now takes only 22,2s to load a 32MB sample, compared to the earlier 70mins. I am glad that our RIF XMLResource however takes only 14,4s for the same contents.

Tags: , , , , ,
Follow

Get every new post delivered to your Inbox.