This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 53921 - Public org.netbeans.modules.refactoring.ui package
Summary: Public org.netbeans.modules.refactoring.ui package
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 4.x
Hardware: PC All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on: 52016
Blocks:
  Show dependency tree
 
Reported: 2005-01-24 23:55 UTC by Peter Zavadsky
Modified: 2007-04-03 18:02 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2005-01-24 23:55:01 UTC
Please, could you public
"org.netbeans.modules.refactoring.ui" package. We
reuse the RefactoringFilterFactory (etc.), to add
there some our specifics to the default funtionality.
Comment 1 Jan Becicka 2005-01-25 07:52:30 UTC
Final review of Refactoring API takes place today. Your requirement
came little bit late :) Anyway we will discuss it there.
We will definitely not add o.n.m.refactoring.ui to public packages.
Please specify your requirement more precisely. Is
RefactoringFilterFactory the only class you need? This factory just
adds menu items to existing nodes... it's not an API class IMO
Comment 2 Peter Zavadsky 2005-01-25 19:17:05 UTC
I am sorry, I am trying to be as fast as possible, but there is too
much of the stuff here.

We are providing our SourceNodeFactory which extends the default one.
The currently the default one which is used in NB is the
RefactoringFilterFactory.

I believe that the RefactoringFilterFactory is service SPI, and should
be make public, so it is possible to extend and replace.

I think you cannot claim that it has to be private. It would mean,
that refactoting module is allowed to extend and replace the orginal
(coming from java), but nobody else can do that with the refactoring  one?

The RefactoringFilterFactory is to our module the same like it is
FilterSourceNodeFactory coming from java to RefactoringFilterNodeFactory.
There is the original FilterSourceNodeFactory which is public in java,
and is extended by the RefactoringFilterFactory.

The same way should be exposed the RefactoringFilterFactory to others.
Comment 3 Jan Becicka 2005-01-26 06:32:47 UTC
> I think you cannot claim that it has to be private. It would mean,
> that refactoting module is allowed to extend and replace the orginal
> (coming from java), but nobody else can do that with the refactoring  
> one?

You can hide RefactoringFilterFactory and provide your own
SourceNodeFactory. Or am I wrong? Your SourceNodeFactory can provide
refactoring actions - see o.n.m.refactoring.api.ui package.

Jardo, do you think, that we can (or even should) make
RefactoringFilterFactory public?

Comment 4 Peter Zavadsky 2005-01-26 18:33:58 UTC
Yes, we can hide it. But that is not the problem.
The problem is we need to reuse the refactoring impl and extend it,
therefore we need to have it public.

What we demand is exactly the same what provides java to refactoring.
Refactoring impl not only hides, but also reuses/extends the impl from
java module which is made public.

Between the java and refactoring is exactly the same kind of
relatioship we require to be possible between refactoring and our
module. I.e. our module has also the chance to extend the impl
provided by refactoring.
Comment 5 Martin Matula 2005-01-26 20:03:48 UTC
You don't need the RefactoringFilterFactory. All you need is to create
your own subclass of FilterSourceNodeFactory and register it in the
layer. Your factory should delegate to the super class and wrap the
nodes returned from it by your nodes that will filter/add actions to
the set of actions in the original nodes.
Comment 6 Peter Zavadsky 2005-01-26 21:56:27 UTC
OK, thanks.