View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0011063||mantisbt||api soap||public||2009-10-21 12:22||2013-01-04 17:04|
|Target Version||Fixed in Version|
|Summary||0011063: Support OSLC-CM API to ease integration with ALM platforms|
OSLC-CM is a Change Management working group of the OSLC initiative (http://open-services.net/) that tries to establish a standard of interoperability for Lifecycle Management tools.
A first version of the specs have been defined, which should be implemented in Mylyn (among other tools) : http://open-services.net/bin/view/Main/CmRestApiV1
It would be great if Mantis was compatible with these APIs to facilitate its integration with other tools.
|Tags||No tags attached.|
@oberger: do you happen to know a list of client platforms planning to integrate the API? Just curious about the potential impact.
Changing status to feedback since we are waiting on response from reporter.
(Sorry for the late answer, I was in vacation)
@rombert : the main client that is involved in OSLC at the moment, from what I can see is Mylyn, through tasktop's involvement, but more details should be provided by them, I suppose.
I'll try and ask if they can commit on more details concerning Mylyn and OSLC-CM and will try and keep this ticket posted.
Maybe this can provide first hints about the Mylyn OSLC-CM support : http://www.youtube.com/watch?v=6jMBZS4gN74
FYI: See the discussion about Mantis on OSLC-CM mailing-list at : http://open-services.net/pipermail/oslc-cm_open-services.net/2009-November/000030.html
I am working with oberger on the project Helios http://dev.artenum.com/projects/helios In the frame of this project, we are working on developing plugins for mantis to facilitate automated/semi-automated bug reporting from tools like Hudson, etc
We are interested in developing a rest api for Mantis, based on the OSLC-CM specifications http://open-services.net/bin/view/Main/CmRestApiV1 There has been some discussion on the mantis mailing list about a possible move from nusoap to the Zend framework Soap functions. Perhaps there can be a common backend to mantis, which is then abstracted to soap, rest, etc?
One of the tentative objectives of the 1.3 release is an abstracted backend which can support multiple external APIs, like the current SOAP version/JSON/a new SOAP backend etc.
The OSLC-CM spec is of course of interest to us, so we can and should meet halfway on this. There is yet no work done on the internal part which should support multiple services, so we don't have the base to build the APIs on.
Perhaps by reviewing our current code you can suggest or come up with improvements/ use cases for the new (backend/internal) API.
We'll try and have a look at what's cooking, and in the meantime, we'll try and code a demonstrator of a stupid OSLC-CM V1 server (in PHP, probably trying to use zend_rest first to evaluate it) as first priority, which will hopefully provide some code that may be reused for Mantis later.
By stupid, I mean one that has no database nor real bugs, but which is just some kind of test server that provides responses to REST invications, simulating the expected behavious from an OSLC-CM V1 compatible bugtracker.
Sounds great. Looking forward to seeing your test server.
I think maybe this could provide some useful reusable code too ? : http://code.google.com/p/mantis-rest/
The test server will be developped around https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/
No code yet, but that will start to appear shortly I guess.
0011219 may help in supporting OSLC-CM, also
FYI, I have completed a first hackish prototype of an OSLC-CM REST API that connects to Mantis 1.2 internal APIs.
It's available in our public SVN should you want to test.
It's far from complete, but at least somehow retrieves lists of bugs an authenticated user has access to (HTTP Basic auth).
Tests and comments much welcome.
For those interested, we have a server somewhere on the net that's publicly accessible.
Just ask us for more details to be able to test (with curl ;).
I've just had a read of the resource definition at http://open-services.net/bin/view/Main/CmResourceDefinitionsV1 and I honestly can't see how any two products can integrate with each other.
dc:identifier - Is is a number or a string? Does it have to be unique? How do I tell clients that my software only accepts identifiers in a particular format?
dc:type - One school of thought is that enhancements ARE defects on the basis that the features are expected, but missing. If I have different types, how does different software understand that a "defect" type in MantisBT is the same as a "bug" type in some other software?
dc:creator - Real name? Email address? User ID? What exactly is meant to be placed in this field to uniquely identify each user? In terms of coupling, does software dealing with change requests have to be concerned with the concept of email addresses at all (seeing as the examples use mailto: links)? What if in my environment, change requests aren't filed by people with email addresses?
There are so many areas open for interpretation that I imagine most software implementing this standard just guess at the methods they use to implement the standard. Which in turn leads to multiple pieces of software that are all based on a standard - but still don't inter-operate with each other.
This is the main reason I don't bother with the XML/RDF hype. Even the most popular specifications such as FOAF (http://xmlns.com/foaf/spec/) are inherently vague and open to interpretation. FOAF used to just have a vague plain text foaf:name property but people complained about not being able to distinguish between given and family names. So now they have properties (under testing) for names in the Western "John Something Smith" format. The problem is that this format doesn't work for a huge portion of the world where names are generated differently (such as Arabic names, see http://en.wikipedia.org/wiki/Arabic_name).
The foaf:mbox property has the following note: "These are typically identified using the mailto: URI scheme (see RFC 2368)". I can't see how the word "typically" fits anywhere within a standard. Standards should be as explicit as possible so that developers can't interpret the standards differently from other developers.
So my question really is... how useful is OSLC-CM given all the vagueness? Will it have to change as frequently and dramatically as more popular standards such as FOAF as corrections are continually made?
I agree that in the current state, the properties are defined in a very vague way. But these are only the minimal attributes that are supposed to be common to all bugtrackers.
But other attributes can already be embedded in addition of the default DC ones, which would be encoded in a much more precise way, given that clients and servers would have agreed on how to interpret them.
In any case, only implementation will tell us how good it is, and of course we may improve the standard, should it show its shortcomings (btw, you're free to send yout comments to the OSLC-CM list ;).
Still, even though it may be minimal and not completely operational for all use cases, it's the only proposed standard so far that would allow to implement bugtracker clients (think Mylyn) once and allow interop with all servers.
On a more general remark : RDF IS about extensibility, so if FOAF is not precise enough for one application, you may add other ontologies to distinguish firstname and name, etc. but still keeping foaf:name for all the apps that can be satisfied with less details. I think this allows a very pragmatic approach : using general (even though vague) properties for most, and adding precise ones for the happy few that know what to do with them, all together in a single RDF document.
Note that the SVN repository has changed : Helios project is uploading its deliverables on SF.net.
Please note that we're approaching the time when it will become quite featurefull.
We have written a roadmap, so expect a mostly complete implementation of OSLC-CM V1 in september :
We have stabilized a 0.8.1 version, and hope someone will be interested.
Unfortunately our efforts on Mantis will be halted from now on (the Helios project is now over), and we'll instead work on the FusionForge and Codendi implementations, that reuse the same codebase.
Hopefully, the improvements made to FusionForge's will be backported easily to the Mantis version.
|2009-10-21 12:22||oberger||New Issue|
|2009-10-27 13:04||rombert||Note Added: 0023415|
|2009-10-27 19:52||vboctor||Note Added: 0023420|
|2009-10-27 19:52||vboctor||Status||new => feedback|
|2009-11-02 12:14||oberger||Note Added: 0023544|
|2009-11-02 12:14||oberger||Status||feedback => new|
|2009-11-02 12:18||oberger||Note Added: 0023545|
|2009-11-03 05:25||oberger||Note Added: 0023554|
|2009-11-17 10:21||mdhar||Note Added: 0023741|
|2009-11-18 15:30||rombert||Note Added: 0023754|
|2009-11-19 14:08||oberger||Note Added: 0023765|
|2009-11-19 14:12||oberger||Note Edited: 0023765||View Revisions|
|2009-11-19 14:43||rombert||Note Added: 0023766|
|2009-11-20 03:53||oberger||Note Added: 0023769|
|2009-11-26 17:22||oberger||Note Added: 0023813|
|2009-11-26 17:23||oberger||Note Added: 0023814|
|2009-12-18 03:53||oberger||Note Added: 0023933|
|2010-01-17 12:48||oberger||Note Added: 0024182|
|2010-01-17 19:52||dhx||Note Added: 0024189|
|2010-01-18 03:19||oberger||Note Added: 0024190|
|2010-01-24 01:56||vboctor||Relationship added||related to 0011219|
|2010-01-25 11:00||oberger||Note Added: 0024244|
|2010-05-29 10:18||oberger||Note Added: 0025623|
|2010-12-01 04:59||oberger||Note Added: 0027528|
|2013-01-04 17:00||rombert||Description Updated||View Revisions|
|2013-01-04 17:04||rombert||Relationship added||has duplicate 0015345|