Separate org.openide.loaders.* package and
necessary content around into its own JAR file and
make the rest of openide.jar independent from it.
Created attachment 9463 [details]
The necessary changes in in openide.jar
Guys, I am attaching the first version of the diff of the separation
of loaders from the openide. I have moved whole org.openide.loaders.*
to openide/loaders/ subtree (not visible in the diff) plus following
places not yet clear to me in the diff are marked with PENDING-JST
comment and I would like some comments about them. Especially:
1. sometimes there are places when a search for DataObject was used as
some kind of special behaviour. Do we have to keep it and if so, try
2. I have moved InstanceSupport.findHelp into HelpCtx.findHelp
(Object), but I am bit unclear about what it does, as the
functionality is a bit duplicated with findHelp (Component). Will need
to be cleared by author (Jesse?). But can wait till I put it into CVS.
3. WeakListener problems - I have create a factory for
OperationListener in DataLoaderPool and removed the old method. I
guess the same should be done for NodeListener and File*Listeners move
them to NodeOp and FileUtil and deprecated the versions in
WeakListener. Sounds right?
4. Backward incompatible changes in TopComponent - we knew about it.
5. Problems with org.openide.text.* - most incompatible changes are
there - the Line used DataObject and there are two possibilities.
Either move the whole text package out of openide and make it depend
on loaders module, but that removes other useful stuff - Annotations,
Line, *Supports, etc. Or replace the DataObject in Line with something
else - incompatible. In diff you can find the second approach - usage
of Lookup instead of DataObject.
Please give some general comments and prepare patches for the branch ;-)
BTW where is this branch?
Comments to the diff:
Re. SaveCookie & message - low priority. I guess
we could ask for FileObject in lookup of a node
instead of asking for DataObject? That would
handle this and many other cases OK, probably.
Same for ExplorerActions.
Re. InstanceSupport.findHelp (e.g. from TMUtil) -
its advantage is that it does not necessarily call
instanceCreate. Also it knows about
WizardDescriptor.Panel. But I think it is not so
important; probably this method will not be used
often anyway, since most nodes will not be
representing some entirely unknown object,
especially if we redesign the Options window.
Don't worry about getting it exactly right. I
suggest findHelp(Object) *not* be added - it is a
sort of strange use case, never widely needed -
intended really for BeanNode, but we do not plan
to continue using that as a UI device.
Re. CloneableEditor deser w/ EditorSupport etc. -
I suggest we forget about deser compat for top
components, especially editors. Who really cares?
Make the upgrade wizard discard them all. We will
probably want to start with a clean slate for the
window system anyway. Certainly no one is going to
give a damn whether their open editor windows are
restored exactly as they were after a major
version upgrade. Much better to just clean up
CloneableEditor and CloneableEditorSupport to not
mention EditorSupport at all - it has been
deprecated for a long time anyway, we could just
delete it if necessary.
Re. use of DataObject from Line & DocumentLine -
Lookup looks very unnatural here, do not like
this... suggest s/DataObject/FileObject/g and make
sure file object move notification works properly.
Re. WeakListener - fine, we will probably need to
do the same for other listener factory methods
later too. Incompatible but easy enough to replace
in sources when upgrading.
The branch has been created. It is rooted at BLD200303191853 tag and
named loaders_32143 To get source for branched modules use
cvs upd -r loaders_32143
I think I have reached a state when the branch is mergeable: NetBeans
builds and runs, XTest runs, internal repository compiles, I'll send
info to nbdev@.
Re. HelpCtx: I have removed the ugly code inside, but kept the method.
Checks only for HelpCtx.Provider. Ok?
Re. Line & Lookup. I have added method
DataEditorSupport.findDataObject (Line) and I am using it in all
places where somebody was using getDataObject. I can implement in in
various ways - now it extracts the DataObject from Lookup, but I can
change the Line to have Object source constructor and just cast it in
the DES.fDO method. Decide what is better, but the ability to have
Lookup there might be interesting for Projects as well. Btw. I do not
want to put there FileObject as it is not mentined in the whole
package at all and I do not want to introduce new interpackage
dependency when I get rid of one.
Re. merging - cool, look forward to it. Don't forget to try
Re. HelpCtx.findHelp - if it only checks instanceof HelpCtx.Provider,
I guess I would just delete it, simpler to write that directly.
Re. Line constructor - I think Lookup does make sense here, it just
needs to be clearly documented what its intended use is (brief code
I have provided (temporary) support for backward compatibility as we
are not sure whether it is the right time to break it or not. It uses
preprocessor and shall be removed as soon as people adopt to new
replacement methods. Base tag for the affected classes is
Created attachment 9615 [details]
Backport of changes from trunk (till BLD200304010100)
Created attachment 9658 [details]
Commit log with versions of changed files
Created attachment 9738 [details]
Mistakes during moving of loader files to new location
Seems like I did at least one mistake when moving files from the src/
to loaders/src and that is removal of addNotify from
NewObjectName.java. So I tried to check how many others mistakes I did by:
cvs upd -p -r BLD200303191853 >Before.commit
cvs upd -p -r 188.8.131.52 >After.commit
then I did diff showing problems in add notify and in findHelp. Jesse,
is the findHelp implementation ok, or should I try to mimic the
original behavour as much as possible?
Btw. I've also lost one commit in the
org.openide.actions.NewTemplateAction, that has been just readded:
new revision: 1.3