there are 2 modules "User Tasks" and "Task List Editor Support" that together
let you record your own planning tasks. You can add tasks using "Add Task"
in the editor margin context menu. Tasks have priority, description, date
created, last modification date, etc properties. You can choose which
properties are visible in the tasklist, and sort by any column. The task list
is stored in a standard format (iCal) which can be read by other calendar
applications, such as Evolution, Korganizer, and others.You can also export
the tasklist to HTML.
Neither module provides a public API.
Both modules are *beta* and will be soon available from the 5.0 beta AUC (you
can download them now from
This review is a request to add both modules to the standard NB distribution
See also the discussion on nbusers/nbdev:
and the list of open issues:
target := 5.5
reassigning to email@example.com
I think it is API_REVIEW_FAST
adding Jaroslav.Tulach@Sun.COM to cc
I am changing the API_REVIEW_FAST to API_REVIEW as this is unlikely to be that
There should be four reviewers for standard review. I can volunteer to be one,
we still need to find some others, but that can wait until you provide some
Usually the documentation is in form of arch.xml document answering some
questions. Just select your module and choose "Generate Arch Description" to
get empty skeleton with answers. I know that you module does not export any
javadoc API, but I am also pretty sure that it exports things that influence
other parts of the system: does it reads files? does it registers something in
lookup? what modules it depends on? Any reflection? Runtime type information
checks? What files your module(s) consist of? All of these questions shall be
asked in the arch.xml, so please try to provide answers to them (warning: do
not try to answer all of them during one day!). If you think some question
does not apply to your module, you can leave it empty. The purpose of these
questions is to provoke answers that would use <api/> tag, so please get
Should there be any problem or question, feel free to ask me. Btw. you are
going to be the first one outside of Prague to fill these question, as far as
I know, so good luck!
Created attachment 28684 [details]
Architecture description for "User Tasks"
Added firstname.lastname@example.org to CC for review
added email@example.com to cc for review
Created attachment 28754 [details]
Architecture description for "Task List Editor Support"
Here are my comments for user tasks module:
Y01 I believe your document should use <api /> tag more often, I'll add a
patch with some improvements, but I expect most of my other comments to result
in a addition of <api type="export" group="java.io.File|etc."
category="stable|private|etc." name="whatisthis" url="maybeurl">but sure some
description</api> into the arch.xml somewhere. See
http://openide.netbeans.org/tutorial/api.html#write for tips how to write the
Y02 arch-usecases: I am missing a description of import/export feature, I am
missing description of default location where the set of tasks is stored
Y03 I am missing description of what format they are in, the link to ref2445
is wrong, should be www.faqs.org/rfcs/rfc2445.html probably.
Y04 perf-wakeup says the module wake ups every 15s. This could prevent the
application from being swapped off (which is not too polite). Can this be
removed or can this be restricted to update only if a piece of the user task
Y05 Why: org.netbeans.api.javahelp.Help.showHelp is called through reflection
when this class is part of public API?
Y06: Imho this class
org-netbeans-modules-tasklist-usertasks-UserTaskTransfer.instance should be
registered in META-INF/services, such a change would speedup startup (~1ms,
Y07: Who reads this piece of layer? Please mark it as imported <api>
somewhere. Possibly split the <api group="layer"/> into multiple parts, at
least depending on stability of the APIs - especially if not all APIs are
<file name="filters.settings" url="filter/usertasks_filters.xml">
Created attachment 28866 [details]
use the <api> tag more so a summary page is generated in top of arch.html for user task module
to Y01 I have applied your patch and used <api> in some more places. Thank You.
to Y02: added a description for the export. The code can only import .ics.
to Y03: corrected
to Y04: is probably possible but would mean a lot of work. Is it a "must have"
to Y05: it is the only place with a dependency on this class. It just reduces
the number of module dependencies.
to Y06: The class is no more in the trunk.
to Y07: Filters are handled by tasklist/core. I have added an <api> for this.
Created attachment 28930 [details]
User Tasks arch.xml diff v1-v2
Created attachment 28931 [details]
User Tasks arch.html v2
I have several UI issues:
H01: Table inside the User Tasks window is small - it does not change its size
when I am resizing User Tasks window.
H02: Mouse right click does not work on the User Tasks background.
H03: There is support for more task owners. Thats great. But on the other hand
you can start only one task at one time. It means that two persons can not work
on two different tasks in parallel.
H04: There is possibility to define dependencies between tasks. But its not
clear, what does it mean. dependencies are not checked as I have tested it. I
mean if task2 depends on task1, I can start task2 even if task 1 is not
finished. And there is not column reserved for dependencies. So it looks like
this functionality is not very usefull in the current version.
H05: There are Move Up and Move Done isons in User Tasks toolbar. But its not
clear what they are good for. Is it somehow connected to dependencies?
H06: Editor - Gutter - Popup menu: I see two tasklist submenus here: "User
Tasks" and "Tasks" here. Both do the same thing, I think.
And one general observation. User Tasks module does not contain user tasks
support only. It has some planning features, and some work monitoring features
too. I am not expert on that area, but It seems to me that support for this
extra features is not complete yet. I would suggest to focus on user tasks
functionality only (and fix bugs, simplify UI on that area). Or we should
provide some more complete support for that features (planning, monitoring)
to H01: it is as designed
to H02: I filed an enhancement for it: #72857. I think it should not block this
to H03: There is no support for multiple task owners. You probably mean the
combobox in the "Show Task" dialog where you can choose from all possible owners
found in the current task list.
to H04: I will remove the tab with dependencies.
to H05: These actions move tasks up and down in the tree.
to H06: This is due to a bug in tasklist/core.
> And one general observation. User Tasks module does not contain user tasks
> support only. It has some planning features, and some work monitoring features
> too. I am not expert on that area, but It seems to me that support for this
> extra features is not complete yet. I would suggest to focus on user tasks
> functionality only (and fix bugs, simplify UI on that area). Or we should
> provide some more complete support for that features (planning, monitoring)
I have just implemented features I was interested in or other people asked for.
Please name the things you would like to see in the module/removed from it.
I'd also like to ask some questions:
- If the module will be included, what NB version will it be? 5.5 or 6.0?
- What is NB 5.5? Is it 5.0 with J2EE.next features? What about changes I have
made in the trunk? I have to synchronize
somehow release cycles of NB and User Tasks and there is almost no information
about the next NB version.
- Why "Y0X" and "H0X" (H-Hanz?)
NB 5.5 is the next release of netbeans after 5.0. It will be equal to release
5.0 except for:
1) J2EE functionality where we are adding support for Java EE 5.
2) Maybe some high priority bugfixes in other areas.
NB 55 is developed in "release55" branch, not in trunk. When we finish NB 5.5 we
will merge the new J2EE features from release55 into trunk (we may merge sooner
if time permits, but this is not guaranteed). Until then we do not plan to do
any development of J2EE features in trunk.
Unless you work on Java EE 5 support (I do not think so) please work in trunk
and do not merge anything into release55 branch!
What you do in trunk in will be part of NB 6.0.
Ok to Y01, Y03, Y06, Y07. For the rest I've sent email to nbdev@
Please do not use LocaleSupport if possible - it's deprecated. Although there
are still some legitimate usages regarding editor options localization if you
use it e.g. for action names localization then please eliminate its use - see
actions definitions in o.n.editor.BaseKit extending LocalBaseAction.
Created attachment 28992 [details]
User Tasks arch.xml diff v2-v3
Created attachment 28993 [details]
User Tasks arch.html v3
see my answers on nbdev.
I have started the opinion document:
Guys, if you have comments, send them at least to nbdev@, do not be shy!
LocalBaseAction is not public. How can it be used?
as far as I understand the next task would be to
write the document with opinions to the end.
When do you plan to complete it?
I have just updated the document at
It still needs approval of other reviewers, so let's do a 168 hours countdown.
If nobody objects, I'll close this round of review.
could you please start UI review of the modules?
6.0 beta is planned in 2 or 3 months so I'd like to see some progress on this
issue. What about UI and code reviews? What should be done next?
I would also like to know what the future for the Tasklist Suggestions Framework
is next to netbeans new editor.
I'm currently using the tasklist modules, mainly the suggestions framework with
copyright and checkstyle, and the bugs module, against netbeans trunk. (I have
uncommitted code to make it work).
I've also migrated the tasklist-checkstyle module over to NbPreferences.
But I'm been hesitant to do too much because the editor is providing new ways to
do things and new features making some in tasklist redundant.
It would also be nice to merge the user tasks and the bugs list together, since
they are essentially the "jobs" for the user. It would also be nice to be able
to /associate/ both tasks and bugs to lines of code in the editor. And/Or to be
able to transform todo/fixme/xxx suggestions into bugs. (The tasklist bugs
module currently does not have any write to issue-tracking system ability).
Anyway i hope that along with the review for the Tasklist User Tasks, there can
be a description on how the Tasklist Suggestions Framework should be implemented
on the new model.
[I hope it is OK that I repost Jiri's e-Mail here as it only contains
information related to the User Tasks module]
I am writing you in regard to your request to get your "User Tasks" and "Task
List Editor Support" modules into the standard NetBeans distribution. We are
very sorry to inform you that our decision is to not include your modules in the
standard distribution of the NetBeans IDE.
Please accept our apologies for the long lasting uncertainty but your request
was the first of a kind and we were obviously not prepared for such a situation.
Your case however initiated a deep internal discussion that will help us react
in a timely manner to similar requests in the future.
We highly value your effort and enthusiasm but consider both modules to be a
perfect fit for our Stable Update Center. While there are no doubts about high
quality of the features we don't think we can provide the level of services
guaranteed for the standard distribution produced by Sun. These services include
future maintenance, bug fixing, quality assurance, localization, paid customer
I am sure you understand our reasoning. We will be happy to continue to host
your module on the NetBeans Update Center, include mentions of updates in weekly
newsletters, or provide other kinds of advertisement. Finally, let me thank you
very much for all your dedication and support of NetBeans project! We hope you
will continue to be a passionate NetBeans user and provider of the most popular
community developed modules.
Technical Community Manager
Looks like forgotten API review request. That request is done. May I close this issue or should the API_REVIEW keyword
Sun (in person of Jan Chalupa) delayed the inclusion of User Tasks in the distribution without an answer to a point
where already 6.0 is out.
This issue should be probably closed as "WONTFIX"...