Final result!

GSoC 2008 is officially over (evaluations are submitted, etc)!

Since the last update I've been adding some minor features and doing some tests. Of course, I corrected every bugs we found!

The best way to see the updates is to check it out yourself by checking out the code of the plugin manager branch of SIP Communicator. I also posted a new screencast on youtube, but it's far from enough to show all the work I've put in the project for the summer.

Screencast!

My last "official" GSoC post will be next week! Don't miss it!

The project on SIP Communicator homepage!

As you can see on SIP Communicator website, the project I'm working on is featured! You can also see a screencast of the differenct features provided by the plug-in manager.

Now, for the project advancement. I'm happy to say it's almost completed! The features have been implemented. What's left to do is correct some minor bugs, refactor some variables/methods and such things. I'm anxious to present to my readers the final product :). Stay tuned!

What's new?

So, what has been done during the last 2 weeks of this project? Here's a brief list of the completed tasks:

• Added the resources strings (French and English)
• Removed the repositories tab and added +/- buttons at the bottom of the available tree
• Added KeyListeners to textfields in order to submit via the enter key
• Available plugins are now removed after being installed
• Corrected 2 bugs that were there before the project (1 in BrandingActivator, 1 in PluginManagerActivator)
• Tabs are now Enabled/Disabled when the repositories are loading
• Added validations on buttons for null pointers
• Fail-over in AddRepositoryDialog (if you add an XML file that doesn't exist and you close the dialog while it's searching, you won't get a timeout after closing it)

As you can see, it's getting more and more complete as the end of the summer approaches :)

Here are some screenshots of the updates:

Loading repositories and disabled components :

Adding a repository and +/- button :

Unknown remote repository in the tree :

That's it for this week! For next week, I'll do mostly "invisible" stuff, like refactoring variable names and applying the code format...

Mid-term update!

In this update I'm presenting the work done so far in the plugin management project. First of all, you can check out the source of the project if you want to try. It's in SIP Communicator's SVN under the pluginmgmt branch.

The project consists of making an advanced plugin management system. This system would allow users to add repositories in order to download/install/update the plugins. It would be similar to what you can find in Eclipse IDE / NetBeans and others.

You can see the GUI of what has been done so far in the plugins section (from the configuration window). The first thing you can notice is that it now has tabs! I'll describe what each tab does in the following paragraphs...

Installed tab

This tab represents what could be found in the plugin section before this project. It's basically a list of installed plugins, and a couple of buttons for the different functionalities.

Available tab

This is a brand new tab used to show the available plugins. They are displayed in a tree, with their repository as the parent node. When selecting a resource to download, it's full description will show in the right panel. Many plugins can be downloaded at the same time. The tree allows multiple selections. Once you've chosen your plugins, you click the download button and it's gonna do it in the background. There is a state label with a pretty interesting loading icon showing the status of the download.

Downloaded tab

Once you download plugins, they will be shown in the downloaded tab. From there, you can install one or more of them at the same time. This tab looks very much like the available tab, with the plugins shown as a tree and a panel for the resource description. You can also delete downloaded resources in this tab (downloading won't uninstall installed plugins). If the install is successful, the user will be noticed, and if it's not, the missing requirements will be shown too.

Updates tab

The updates tab shows the currently available or downloaded updates for installed plugins. Once again, it's shown in a tree structure with a panel for the resource information. The first level under the root isn't for the repositories this time, it's for the installed bundles. The leafs are the currently available versions. If an update is "available", clicking the button will download and install it. If the update is "downloaded", it will simply install it. Once again, if there's a problem (like a missing package), the user is noticed.

Repositories tab

This tab is a work in progress. It's used for managing the repositories. Currently, it only allows to add and delete repositories. The URL of an added repository has to point to an XML file with the Felix OBR repository.xml structure.

Search feature

In the Available, Downloaded and Updates tabs, you can see a "Filter" text field at the top. It is used to search within all the plugin shown. In the Available and Downloaded tabs, it searches within the resources names. In the Updates tabs, it searches within the bundles names.

Second part of the project

Many things are left to do for the end of the program. Some parts of the GUI are still very bogus and some functionalities are still missing (refresh buttons and things like this). The most important parts have been implemented, so what's left to do is add functionalities, correct bugs / performance / fail-over issues. The whole OBR service has been overidden in order to provide more functionnalities. That was the core of the project. The remaning features are related to USING those extra functionalities. I also have a bunch of TODOs in my code which I'll have to go through and finish them all. Most of them are for error handling, changing variable/method names, adding functionalities, code formatting. To make it short: expect more for the end of the program!

NOTE : If you want check-out and run the code, you'll need to add some repositories. One of them that is always up is:
http://oscar-osgi.sf.net/obr2/repository.xml
However, the resources on this OBR can't be installed because some requirements are missing.
You can also try my own repository. It's not always up so it won't always work:
http://74.59.129.185:8080/repository/repository.xml
The resources can all be installed. I modified the version numbers of those plugins in the manifest file. That way, you'll see those resources as updates in the tab of the same name. Isn't that great?

Update!

So...What happened since the last patch...Hmmm...Well, pretty much everything! I didn't have a lot of time to post since the last one, but it's going to change (I'm moving tomorrow so I was planning it and everything). So, here we go:

First of all, about the OBR. We decided to go for the initial idea of the Felix OBR. Plus, I'll provide an interface for the deployment packages (It's not yet in a felix release, but I'm sure I can play with a SNAPSHOT). So I'm hosting an OBR on a local machine. I won't write the IP address now, since I'm moving tomorrow (my IP is going to change).

About the plugin management system now. We chose to make a plugin management system similar to the Netbeans one (different tabs for updates, downloaded plugins, installed, etc). It's pretty advanced as of today. My personnal goals are achieved, even though I ran into some obstacles. I'm glad I had my mentor and SC/Felix communities to help me. The main features have been implemented. You can add/remove repositories, download resources, install them, delete them. I also started the GUI for it. Everything is now available in a branch of SC. You can see it there:

https://sip-communicator.dev.java.net/source/browse/sip-communicator/branches/pluginmgmt/

The code is in the plugin called pluginmanager. So, that's it for this week. Come back next week for further updates!

First week report!

Here it is, the first week is (almost) over. This week I was working on setting up an OBR (next week will be for that too). SIP Communicator recently got an interesting proposal by Luminis. They are ready to provide SC with a provisionning server. It will work as follows:

1. The developper will match the bundles with groups and groups with licenses via a special client that communicates with the provisioning server.
2. The user of SC will open an update UI, and will be proposed licenses (users don't want to see 25 bundles for the same feature. They want the whole feature in one package, which we call a license)
3. When downloading the licenses, the server will send deployment packages to the client associated with the licenses chosen.
4. The client application will install the deployment packages via a deployment admin.

Some things still have to be cleared up though. How will the client application communicate to retrieve the licenses? How will the server return the deployment packages (No OBR for deployment packages)?

What are the pros and cons of both approaches?

Provisioning server

Pros

• Users of SC can install features instead of bundles
• Easy to match bundles with groups/licenses
• Usage of deployment admin to install deployment pacakages
• Provided by Luminis :)

Cons

• No standards for communicating with the provisioning server. (Nothing like an OBR for deployment packages.
• The developper would have to create a service to talk to his repository)
• DeploymentAdmin isn't in the current release of Felix yet. From what I've seen, it will be in the next one.

OBR

Pros

• Easy for the developper
• Implementation already available in Felix

Cons

• Bundles aren't always significative for the user.
• A feature approach is much more interesting

Everything will be clarified during next week! We will most probably use Luminis server, but we could also use both solutions. To be continued... :)

Managed to make the Felix OBR work!

This week I was playing with Felix OBR (OSGi bundle repository). I had a couple of problems including inconsistency and inheritance. I'll explain my problems and the solutions here.

My goal was to use the Felix OBR in the SIP Communicator project. The first thing I did was to add the Felix OBR jar file to the class path, add the OSGi obr and Felix OBR packages to my bundle, and try the code in my start method. It didn't work. Everytime I was trying to use a class of the OSGi obr package, it would tell me another class of the same package was already loaded.

I found out that the OBR was already installed as a bundle in SC. I searched and found that it was loaded in the felix.auto.start system property. I then removed the Felix OBR package import in my manifest, as I only needed the OSGi obr package. Since it was already loaded as a bundle, I only had to get the reference to the service, using RepositoryAdmin.class.getName(). Everything worked afterwards! Thanks to SC developers mailing list and Felix users mailing list!

This week I also discussed the project schedule for the summer with my mentor Cristina. I'll post it as soon as it's confirmed!

TODO List:

• Continue playing with Felix OBR
• Think of the project functionnalities