Bug 32143 - Create openide-loaders.jar
Create openide-loaders.jar
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Data Systems
3.x
All All
: P2 (vote)
: 3.x
Assigned To: Jaroslav Tulach
issues@platform
:
Depends on: 36616
Blocks: 19443
  Show dependency treegraph
 
Reported: 2003-03-19 14:46 UTC by Jaroslav Tulach
Modified: 2008-12-22 20:45 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
:


Attachments
The necessary changes in in openide.jar (34.40 KB, patch)
2003-03-19 14:55 UTC, Jaroslav Tulach
Details | Diff
Backport of changes from trunk (till BLD200304010100) (12.49 KB, patch)
2003-04-01 05:46 UTC, Jaroslav Tulach
Details | Diff
Commit log with versions of changed files (59.64 KB, text/plain)
2003-04-02 12:29 UTC, Jaroslav Tulach
Details
Mistakes during moving of loader files to new location (3.82 KB, patch)
2003-04-07 13:10 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2003-03-19 14:46:56 UTC
Separate org.openide.loaders.* package and
necessary content around into its own JAR file and
make the rest of openide.jar independent from it.
Comment 1 Jaroslav Tulach 2003-03-19 14:55:22 UTC
Created attachment 9463 [details]
The necessary changes in in openide.jar
Comment 2 Jaroslav Tulach 2003-03-19 15:12:27 UTC
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 ;-)
Comment 3 Jesse Glick 2003-03-19 15:43:15 UTC
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.
Comment 4 Jaroslav Tulach 2003-03-20 10:30:52 UTC
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
Comment 5 Jaroslav Tulach 2003-03-25 16:53:38 UTC
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.

Comment 6 Jesse Glick 2003-03-25 16:58:52 UTC
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).
Comment 7 Jaroslav Tulach 2003-03-28 12:46:13 UTC
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
Comment 8 Jaroslav Tulach 2003-04-01 05:46:11 UTC
Created attachment 9615 [details]
Backport of changes from trunk (till BLD200304010100)
Comment 9 Jaroslav Tulach 2003-04-02 12:29:06 UTC
Created attachment 9658 [details]
Commit log with versions of changed files
Comment 10 Jaroslav Tulach 2003-04-02 12:29:30 UTC
Integrated.
Comment 11 Jaroslav Tulach 2003-04-07 13:10:07 UTC
Created attachment 9738 [details]
Mistakes during moving of loader files to new location
Comment 12 Jaroslav Tulach 2003-04-07 15:36:49 UTC
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



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