MantisBT

View Issue Details Jump to Notes ] Wiki ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011063mantisbtapi soappublic2009-10-21 12:222013-01-04 17:04
Reporteroberger 
Assigned To 
PrioritynoneSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0011063: Support OSLC-CM API to ease integration with ALM platforms
DescriptionOSLC-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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0011219acknowledged Provide OAuth inter-application authentication "tokens" mechanism 
has duplicate 0015345closed Is there support for OSLC CM support 

-  Notes
User avatar (0023415)
rombert (developer)
2009-10-27 13:04

@oberger: do you happen to know a list of client platforms planning to integrate the API? Just curious about the potential impact.
User avatar (0023420)
vboctor (administrator)
2009-10-27 19:52

Changing status to feedback since we are waiting on response from reporter.
User avatar (0023544)
oberger (reporter)
2009-11-02 12:14

(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.
User avatar (0023545)
oberger (reporter)
2009-11-02 12:18

Maybe this can provide first hints about the Mylyn OSLC-CM support : http://www.youtube.com/watch?v=6jMBZS4gN74 [^]
User avatar (0023554)
oberger (reporter)
2009-11-03 05:25

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 [^]
User avatar (0023741)
mdhar (reporter)
2009-11-17 10:21

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?
User avatar (0023754)
rombert (developer)
2009-11-18 15:30

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.
User avatar (0023765)
oberger (reporter)
2009-11-19 14:08
edited on: 2009-11-19 14:12

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.

User avatar (0023766)
rombert (developer)
2009-11-19 14:43

Sounds great. Looking forward to seeing your test server.
User avatar (0023769)
oberger (reporter)
2009-11-20 03:53

I think maybe this could provide some useful reusable code too ? : http://code.google.com/p/mantis-rest/ [^]
User avatar (0023813)
oberger (reporter)
2009-11-26 17:22

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.
User avatar (0023814)
oberger (reporter)
2009-11-26 17:23

0011219 may help in supporting OSLC-CM, also
User avatar (0023933)
oberger (reporter)
2009-12-18 03:53

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.

More details in https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/MantisOslcServer [^]

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.
User avatar (0024182)
oberger (reporter)
2010-01-17 12:48

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 ;).
User avatar (0024189)
dhx (developer)
2010-01-17 19:52

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.

Some examples:

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?
User avatar (0024190)
oberger (reporter)
2010-01-18 03:19

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, the protocol defines the REST protocol elements, in particular on how to retrieve / filter bugs, or how to create bugs with delegated AJAX interfaces, which is very interesting, and supposed to be generic enough to adapt to all tools.

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.
User avatar (0024244)
oberger (reporter)
2010-01-25 11:00

Note that the SVN repository has changed : Helios project is uploading its deliverables on SF.net.

More details at : http://heliosplatform.svn.sourceforge.net/viewvc/heliosplatform/mantis-oslc/trunk/ [^]
User avatar (0025623)
oberger (reporter)
2010-05-29 10:18

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 :
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/MantisOslcCmServerRoadmap [^]
User avatar (0027528)
oberger (reporter)
2010-12-01 04:59

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.

- Issue History
Date Modified Username Field Change
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


MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.1225 seconds.
memory usage: 3,065 KB
Powered by Mantis Bugtracker