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.
Summary: | Create openide-loaders.jar | ||
---|---|---|---|
Product: | platform | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dkonecny, jglick, ttran, vstejskal |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | 36616 | ||
Bug Blocks: | 19443 | ||
Attachments: |
The necessary changes in in openide.jar
Backport of changes from trunk (till BLD200304010100) Commit log with versions of changed files Mistakes during moving of loader files to new location |
Description
Jaroslav Tulach
2003-03-19 14:46:56 UTC
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 classes: src/org/openide/actions/CustomizeBeanAction.java src/org/openide/actions/FileSystemAction.java src/org/openide/actions/InstantiateAction.java src/org/openide/actions/NewTemplateAction.java src/org/openide/actions/SaveAllAction.java src/org/openide/actions/SaveAsTemplateAction.java src/org/openide/awt/ExecBridge.java src/org/openide/awt/MenuBar.java src/org/openide/awt/Toolbar.java src/org/openide/awt/ToolbarPool.java src/org/openide/filesystems/RefreshAction.java src/org/openide/text/DataEditorSupport.java src/org/openide/text/EditorSupport.java 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 some advice. 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. Enough. 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 qa-functional tests. 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 samples). 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 loaders_32143_compat_start Created attachment 9615 [details]
Backport of changes from trunk (till BLD200304010100)
Created attachment 9658 [details]
Commit log with versions of changed files
Integrated. 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: cd src/org/openide/loaders cvs upd -p -r BLD200303191853 >Before.commit cd loaders/src/org/openide/loaders cvs upd -p -r 1.1.2.1 >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: NewTemplateAction.java new revision: 1.3 |