From Persistency Questions To EMF … Part 2

Today I had to add one attribute to my persistent filters describe in this previous post.

Thanks to EMF I just added a new getter method in my filter interface with the “@model” tag in the method comment and regenerated all needed stuff and this new attribute was persisted for free.

Using modeling here avoided me to have to update and maintain several classes when I added this new attribute !!!! An other noticable advantage of using EMF.

Manu

From Persistency Questions To EMF …

This week I finally decided to step in EMF. 2 years after starting Eclipse development …. French people will say here “Mieux vaut tard que jamais“

Here is the story …

In a custom view built on top of Draw2D  providing embedded C profiling informations to the user we decided to add filtering capabilities. Thus we added a filtering button opening a dialog letting the user choose the elements he wants to filter.

Quickly we got the following interfaces and associated implementation:

public interface Filter {

public String getName();

public boolean isFiltered(Object element);
}

public interface TypeFilter extends Filter {

public void addType(String type);

public boolean removeType(String type);
}

We easily implemented filtering management using these interfaces . Then came the need to save user defined filters across Eclipse launches.

Saving these filters in our plugin directory inside the workspace (/workspace/.metadata/plugins/my.plugin.id) came immediately in our minds but HOW …. ????

1. Using Eclipse preferences store ?? Impossible our filters are composed of a name attribute (type String) and a liste of types attribute (type List<String>)  and preferences store can only stor informations of type “key=value”.
2. Using XML ?? Nice solution but …. needs to reinvent the wheel in order to convert our filter data structure into XML and to get back our data structure from this XML.
3. Using EMF ?? Yes of course, among a lot features it’s here for that !!!!

I took up my sleeves and less than 1 hour after our filters was persisted across Eclipse instances !!!!

Here is the way I proceeded (mainly following EMF book) :

1. Annotation of previously described Java interfaces
2. Generation of model classes
3. Persistence of these generated classes using EMF API (Ressource)
4. Well done EMF !!!

This experience introduced me smoothly to EMF and avoided me to waste time on XML parsing/writing with in Java. I certainly should have used EMF before … I’ll try to use it more in the future in order to really understand all the benefits it can bring.

Eclipse Headless Build Facts

Thanks to Andrew Niefer my previous Eclipse Headless Build Thoughts are now facts.

Because I didn’t find documentation anywhere on the subject (may be I missed it ?? ) I am putting here the solution to easily (just by changing the map file content) replace the fetching of sources to build from CVS by a local copy:

” PDE/Build has an extension point where different map file entry format can be contributed. (This is where the support for SVN comes from).Build provides a “COPY” extension.

Your map file entry would look like:
plugin@org.eclipse.foo=COPY, ,
which results in a copy from root/element, if element is not specified, then you end up with copy from root/org.eclipse.foo”

Thanks Andrew !

Eclipse Headless Build Thought

I have been working recently on the build automation of our Eclipse’s project. Manually generating pacakages was boring, not safe and time consuming !!!!

Starting from web resources I quickly front of the part of the build related to the fetching of sources from a remote repository. In our case, we are not using CVS/SVN but Clearcase UCM.

Of course I can’t use ant GET target to fetch my sources from Clearcase but that is not a problem because I want to build the current version I have locally on my hard drive (== my working copy).

Eclipse’s help says here that I can manually retrieve my source within the customTargets.xml script (in the postSetup target). Fine !!! All I need to do is to use COPY ant tasks to “fetch from my lcoal hard drive” my sources into the directory that will host the build.

I decided to start to automate the build of my SDK feature. Starting from here I modified the postSetup target to copy my SDK feature and my feature (included by the SDK one) into the build directory. Then I had also to copy all the feature’s plugins. After long time  and several launch of my build script to see step by step which plugins where missing I finally was able to build my feature.

All this boring work (developers are lazy guys ) ) made me think that it would be nice to have the eclipse.fetch target able to fetch plugin from a local directory. This way, as in the case of fetching from CVS, what we have to do is just says where to find locally plugins and features through a map file containing local paths. Eclipse will be responsible to get required elements to build the feature according to the feautre.xml file.

What do you think about that, anyone already reached this problem ? May be this feature is already existsing … ??? I guess the map file is read by Java code, I’ll try to step in Eclipse code to see if it’ll be possible to implement such feature …

I was wondering how Eclipse’s projects developers can build a feature using sources not commited yet to a CVS repository … In fact I guess they/you face the same problem I described … ???

Manu