Bug 37316 - Remove tasklist APIs proposal
Remove tasklist APIs proposal
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Action Items
3.x
All All
: P2 (vote)
: 4.x
Assigned To: tasklist-issues@contrib
tasklist-issues@contrib
11-28-2003
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-18 16:02 UTC by _ pkuzel
Modified: 2004-08-13 12:11 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2003-11-18 16:02:21 UTC
It's request for (almost) reverse process. I need
to remove beta API from stable release. 

Please judge if this sort of problems should
undergo a kind of ARCH process.

If so then please review
<http://tasklist.netbeans.org/proposals/barracuda/api-stability.txt>
(the proposal) and approve or disapprove the
proposed solution.

Thank you
Comment 1 Pavel Buzek 2003-11-19 17:22:24 UTC
Petr, is there any summary of what the APIs do and what other modules
use them or will have to use them? That would be helpful for thinking
about your proposal. Thanks.
Comment 2 _ pkuzel 2003-11-20 08:37:13 UTC
In short the framework is built around Suggestion (and
SuggestionManager) class. Modules can create suggestions as side
effect of their computations and push them to the manager or register
themself (as providers) with the framework to get pull suggestion
retrieval queries.

All modules can provide suggestions. The pull approach sometimes
overlaps with currently used check&fix actions/wizards. The difference
is in workflow (assuming current implementation).

Right now it's used by all tasklist submodules. There is also one
known fork attempt by external developer.
Comment 3 Pavel Buzek 2003-11-21 19:14:22 UTC
Sound like the change is not too controversial and we can go for fast
track review. Petre, please announce it to nbdev to double check if
anybody was using the current API.

My opinion is that the proposed solution (option B) is the best we can do.
Comment 4 Jaroslav Tulach 2003-11-24 09:37:43 UTC
Drawback of B is that we will not have good answer to any 3rd party
contributor trying to plug into the tasklist. Answer "there is no api"
is not too satisfying, answer "you have to have impl dependency" is a
bit better, but still, we should support an attempt to write nonstable
API module and publish it on autoupdate. If used by other
only-autoupdate tasklist modules (I understand that there are few not
going to be stable), the quality would be guaranteed (e.g. it would be
useful) and would probably have a better chance to become the real api
(at least it would be in the right packages). 
Comment 5 _ pkuzel 2003-11-24 10:29:50 UTC
I really do not want to support both internal API accessed using
implementation dependencies and unstable API. I do not see any real
advantage.

Non-stable modules can use implementation dependency. Such modules are
under development so they can accomodate to both new API or
implementation change without loosing any mayor investments.

From stable modules point of view API matters but they need only
stable API (I guess author will favour implementation dependency on
stable implementation version over dependning on unstable API).

Comment 6 Pavel Buzek 2003-11-24 17:39:18 UTC
I think that if Petr does not have time to create good and stable API
(option A) it's better not to create any API. IMO rushing with APIs
will not be any useful. The usefulness of unstable API can be tested
just as well with implementation dependency. Having the correct
packages is worse, not better, since it blurs the boundary between
stable API and nonstable implementation code.
Comment 7 _ pkuzel 2003-12-11 16:46:41 UTC
Removed, module renamed to org.netbeans.tasklistapi.
Comment 8 Jaroslav Tulach 2003-12-12 09:53:53 UTC
I read "B) Remove the API completely" as "B) Do not attempt to have
stable API" as inside this task is written: 

- repackage api to org.netbeans.modules.tasklist.clients
- repackage spi to org.netbeans.modules.tasklist.providers
- rename the module (there are the beta versions living around)
- set Public-Packages attribute to '-'
- force maintainers to establish tasklist-barracuda impl dependency

which indicates that there is an API. Then I think: Its stability
should be specified, and probably javadoc released which people should
treat as a stable as the stability category says. Imho, if want to
make the API stable someday, you have to advertise it. And release
under less than stable category seems to be the right option.

Comment 9 Jaroslav Tulach 2004-05-14 08:19:00 UTC
What is wrong with this issue? It is still listed as open fast track
request. Turning into something that is being tracked (p2 defect) so
the module owner has to act.
Comment 10 Ondrej Rypacek 2004-05-26 11:21:11 UTC
I believe that B) (i.e. what Peter has already done) is the right
solution for the time being. The current "api" is not only unstable,
but far from complete. 
Unfortunatelly, we don't currently have time to redesign the apis. The
only feasible solution thus is hiding the current "api" for the time
being and publishing stable and complete api later, when there's time
and demand for it.

Closing as fixed, as the APIs are removed as requested by this issue.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo