NetTasks is an extendable plugin for IDEA, that allows to manage issues.
It has an open architecture, so everybody should be able to add new types of issues.
The project is hosted at Sourceforge. Feel free to take a look at the nightly cvs-build. 
Since some eap-builds, IDEA now has a built-in ToDo?-List. This is a very nice feature, but it is not powerful enough.
We try to write a manager, where different types of issues may be managed.
One part of it will be the ToDo?-List, but other points may be tasks, that are synchronized over the LAN or the Internet with your colleagues, or issues that synchronize with your preferred Web-based BugTracker?.
This is possible, because the manager only works with Interfaces, that may be implemented in their own way.
To be flexible and easily extendable, we have chosen a hierarchic structure of issues.
The centre of the hole plugin is the IssueManager?, that knows all the important classes. It is designed as a "Project-Singleton" (a new DesignPattern? ).
Over the IssueManager? you can get the Gui-components (IssuesToolWindow?, IssuesTable?, IssuesTableModel?...) and the logical containers of the issues: the IssueHolder?. Those IssueHolder? are organized hierarchically.
An issues represents one entry in the list. An issue has some defined properties that may be manipulated by the user.
An issue has the functionallity to work transaction-based, even if it doesn´t have to use it. Every time before an issue is manipulated by a user the method perepareForEdit is called.
In this function the transaction has to be started, logs for multi-user-issues must be applyed...
After editing the method commit() is called. The transaction is completed and the logs may be released...
The Interface IssueHolder?
The IssueManager? includes one IssueHolder? - the RootIssueHolder. The RootIssueHolder may contain several [IssueHolder]s, those may contain several ...
The organisation of an IssueHolder? is for his parent fully transparent. He can ask his child for all his issues or give him other instructions, like creating a new Issue of a certain type. But it is not necessary for him to know the internal structure (even it is possible to find it out).
Those IssueHolder? may be configured over an XML-file. So everybody can add IssueHolder? and issues with a specific source. Over a unified configuration screen the user can change his specific configuration (change paths...).
Question: Could an IssueHolder? also provide an interface to an external Issue-Tracking system (like bugzilla?).
As IssueHolder? and Issue are interfaces, you can implement them how you want to.
It is of course possible to create an Issue and IssueHolder? that are based on a external Issue-Tracking system like bugzilla.
IssueFrame?
At the moment the issueFrame has "hard coded" textfields to manipulate the properties of an issue.
What do u think about a mechanism, that allows a specific Component, that represents one Issue.
It would be possible to add additional features and properties (links, files...).
There are several steps that have to be done.
If you want to help, we will be very happy Just email at shake@webNOSPAM321.de.
- IssueFrame?
- saving an issue
- Prototyp of the Configuration has to be made
- Icons
- Icons for the different actions.
- IssueHolder? - DefaultImpl?: AbstractIssueHolder?
- need some thougths about Sorting
- need some thoughts about Filtering
- AbstractIssue?
- complete the default implementation
- XmlIssueHolder? (an examlpe of an issue holder. Saves his issues to Xml)
- New IssueHolder?s:
- Synchronizes over TCP/IP
- ...
- New Feature: Synchronizing over TCP/IP
This project is hosted on:
|
|
