Category: Projects

COCLICO project’s efforts towards better forges interoperability (long)

Abstract

I’ve given a talk in the recent Open Forges Think Tank track of Open World Forum, which was organized by Christian Rémy from Bull, also a partner in the COCLICO project (btw, thanks Christian, this was a great track, with several interesting presentations and a great panel).

I’ve had the privilege to speak on behalf of the whole COCLICO project, in the afternoon session which was focused on forges interoperability.

This article will somehow be a transcript of what I’ve said (or intended to say), with the accompanying slides available here.

In this quite long piece, I’ll first recap some of the context elements about the COCLICO project. Then I will describe the interoperability issues that I’ve tried and focused on in my presentation, including the issues of project lock-in in the forges. I’ve tried also to describe the current ideas we’ve elaborated in the project to address these issues of interoperability (including our plans for open standards elaboration for forges interoperability). I finally conclude with a proposal to join the PlanetForge community for all interested parties.

Unfortunately, not all of these ideas are currently yet properly documented on the COCLICO website, so I hope this article will serve as a useful reference for what COCLICO is doing, still being a subjective piece of my own views, not necessarily representing those of other COCLICO participants, nor a precise description of what we’ll manage to achieve in COCLICO or PlanetForge.

Continue reading “COCLICO project’s efforts towards better forges interoperability (long)”

New OAuth plugin for Mantis

I’ve been working on implementing a (my first) plugin for Mantis to provide OAuth support in Mantis.

I now have a first 0.5 version that may be tested. More details here.

Nest step will be to try and use it for the OSLC-CM REST server add-on for Mantis, to allow clients to connect to the REST API using OAuth Access Tokens.

LD2SD, Helios and Linked Data / SemWeb extracted from development forges

We have received a visitor from DERI last week (PhD student Aftab Iqbal) who’s researching integration of facts about software development tools into Linked Data in order to provide interesting “semantic mashups” of data into IDEs like Eclipse (see his slides). Quite interesting is the choice of ontologies and the results integrated in an Eclipse plugin made available to developers.

This approach is quite similar to the one we practice in the core of the Helios platform (still under development) to integrate data coming from different FLOSS ALM tools in order to create dashboards offering a consolidated view of software (maintenance) process.
Maybe the difference is that Helios does this internally inside a “self-contained” platform whereas the potential of LD2SD presented by Aftab is to do the same on the Web of Linked Data.

Also, in Helios, there are other contributions made for the Mandriva distribution (with links with projects like Scribo and Nepomuk to which Mandriva is also participating) in the form of the doc4.mandriva.org, in order to aggregate, this time, not facts at the “project” level, but for a meta-project (a GNU/Linux distribution) that are quite interesting. See Stéphane Laurière’s slides for details.

We’re also experimenting in the frame of the COCLICO project on producing RDFa data about software development projects hosted in FusionForge instances. (see our progress tracked through this FusionForge feature request). First candidates are project’s DOAP profiles and developer’s FOAF ones, and lots of SIOC to glue it all, and of course other informations relating to a Forge ontology that we’re proposing in COCLICO.

With recent announcements that Mylyn is investing a lot in OSLC, and OSLC being based on RDF, and the advent of the Semantic Desktop starting to emerge (in KDE mainly) on top of Nepomuk, this brings great promises for a great Semantic future.

New SF.net project for HELIOS

The Helios project is gradually going more open, as we start releasing and committing in the open into a SF.net project (heliosplatform).

Among the tools offered by SF.net we will use a blog (wordpress), the wiki (mediawiki) and the SVN, for a start.

The project’s SVN repo will be populated with all components we have developed, as we progressively switch our SVN hosting. The first piece we have committed is the Mantis OSLC REST server module.

Some news of our efforts around OSLC-CM and future plans

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we’ve been very interested in it.

OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we’ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that’s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools.

At the same time we’ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions 🙂

Now that this works, we’ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn… hmmm… well, we’ll see.

Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link.

Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually.

Lots of interesting developments ahead. Stay tuned.