Hi, There are a couple of us (Jimisola Laursen, Tomasz Pik and Jason van Zyl) that been thinking/discussing an issue (management) API for Maven similar to the way that scm systems are handed by Maven SCM. While Jimisola was discussing this with Jason he revealed that he had a project (management) API for Maven in mind as well.
The idea with this post is to start a discussion around these two APIs and the goal the result of a specification for each the APIs. It would be nice if we could decide on a working name for the APIs. For issues/tasks: 1. Maven Issue API 2. Maven Issues API 3. Maven Task API 4. Maven Tasks API 5. Maven Issue Management API 6. Maven Issues Management API 7. Maven Task Management API 8. Maven Tasks Management API For projects: 1. Maven Project API 2. Maven Projects API 3. Maven Project Management API 4. Maven Projects Management API Are there other alternatives? Please come in with suggestions if so. We are not familiar with the voting procedure. Hence, how is the vote started and which persons are allowed to vote? May we propose a vote? -- Background Jimisola's idea is to create a issue report plugin that is independent of underlying issue tracker. It would provide static pages much like Jira's summary page (e.g. jira.codehaus.org/MDEP) with the intention to have additional information such as vote count. Tomasz Pik have an idea about an issue plugin. It would have e.g. the goal "mvn issues:attach-patch -Dissue=123456" which would will run scm:diff and attach a diff to issue with a note). Both my and Tomasz ideas would be much easier to implement with a common Maven issue/task (management) API. Up until now this would have been a quite a task if we had to create it from scratch. However, since Jimisola recently found Mylar (www.eclipse.org/Mylar) he started wondering if one wouldn't be able to use Mylar's Tasks API that has rich task repository connectors to e.g. Bugzilla and Jira. For more info see: http://wiki.eclipse.org/index.php/Mylar_Architecture http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference So, he made a post in Mylar usenet and got in contact with Mik Kersten (project lead for Mylar). After a short exchange the discussion moved to Mylar dev mailing list: http://www.nabble.com/forum/ViewPost.jtp?post=6009439&framed=y As you can see the Mylar Team are actually quite keen on helping us out (or at least joining efforts), e.g. see: * bugzilla.core should not depend on eclipse or Mylar (https://bugs.eclipse.org/bugs/show_bug.cgi?id=127293); * extract tasks framework from Mylar.tasklist (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149981); * Split search into headless and UI (https://bugs.eclipse.org/bugs/show_bug.cgi?id=155279). In fact, Mik Kersten explicitly asks for enhancement requests: "It's available now, but we still need to continue growing it to make it usable by headless applications. We don't currently have an internal need for that so we're happy to see the Maven integration act as a driver and looking forward to more bug reports." While Jimisola was in contact with Mylar Team he also tried to make contact with the Maven Team. After some discussions on irc it came to his attention that Jason van Zyl was thinking of using Mylar as well, but he wanted to wrap Mylar's API with a Maven API for use by the Maven community (more on this further down). Tomasz Pik had already started on an Issue Tracker API named ITAPI (http://sourceforge.net/projects/itapi) that we might be able to start of, but we assume that it depends on the API specification that we (read: the community) decide upon. This is basically where we are today. We have informed Jason we'd like to help out with the Maven Issues API. As mentioned before in addition to the API for tasks/issues Jason informed Jimisola that he had some ideas on a project management API as well. An API that would play along with issues/tasks API if Jimisola understood Jason correctly. Jason have had some exchange on this matter with Mik, but we leave it to Jason to comment on his exact ideas on the project management API (hopefully this will be within the next week as Jason is currently about to attend JavaZone in Oslo, Norway). Jimisola have his ideas on project management if it means time management is somewhat way. To start a discussion he made a post on Mylar Dev (http://www.nabble.com/Planning-tf2240654.html). His dream would be for a developer using Mylar to use its Planning and timing functionality like usual. It would then have a mechanism to "report back" to a "central time facility" (issue-tracker or project management tool or..). A project management tool (such as Gnome Planner, Microsoft Project etc) would constantly have update-to-date task status (including elapsed time of it), task dependencies (from the issue tracker) etc. This are just his initial thoughts. Jason most likely have other things to add or might even see it differently. -- API - what and how? Jimisola listed some functionality/features that he liked the Mylar API to have here: http://www.nabble.com/forum/ViewPost.jtp?post=6009439&framed=y These apply for the Maven Task API as well he believes. Tomasz Pik wrote that the design of the API should provide a layer over Mylar and consist of (at least) the following: - an API that defines a connector - a connector which acts as a proxy for Mylar connectors (if Mylar efforts are successfull then we'll be able to register this connector as connectors for all trackers supported by Mylar) - maybe other connectors for trackers that do not work under Mylar Having this maven-changes-plugin will be just a mojo calling Issues API in the same way as maven-scm-plugin using Maven SCM libraries. This approach will also satisfy issues like http://jira.codehaus.org/browse/MCHANGES-58. And provides a background for more sophisiticated integration like: - mvn issues:attach-patch -Dissue=123456 which will run scm:diff and attach it to issue with given key - dashboard in continuum So, we need (at least): - a name for each of the APIs - to decide whether these are good ideas, if we should prioritize one API over the other etc - an API specification of functionality/features and usage for each of the APIs Regards, Jimisola Laursen and Tomasz Pik PS. While on the API subject have a look at "How to Design a Good API and Why it Matters": http://lcsd05.cs.tamu.edu/slides/keynote.pdf -- View this message in context: http://www.nabble.com/API-proposal-for-discussion%3A-issue-management-API-and-project-management-tf2248367.html#a6235716 Sent from the Maven Developers forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
