[jplugin & swingx] Refactoring project status
tn5250j <[email protected]> Thu, 27 Mar 2003 10:57:04 +0100
| Newsgroups | gmane.comp.krysalis.sandbox |
|---|---|
| Message-ID | <[email protected]> |
Hello all
Finally got some time to start refactoring the krysalis code for the
projects jplugin and swingx that Nicola introduced the other day.
Here is a status snapshot so far:
org.krysalis.dragonfly - not included
org.krysalis.imago - not included
org.krysalis.java - not included. There have been no references to
these objects in the code. Should they stay or should the go ?
org.krysalis.avalon - refactored to org.krysalis.jplugin.engine
org.krysalis.monarch - refactored to org.krysalis.jplugin.framework
org.krysalis.silk - refactored to org.krysalis.jplugin.components
org.krysalis.swallowtail - still exists at this time for testing but
only with a couple of the examples:
- still existing examples for testing framework
sheets.html
sheets.javahelp
sheets.text - also includes the NetBeans sheets.
org.krysalis.javax - refactored to org.krysalis.swingx
So far there are a few inter-dependencies that are posing some nice
opportunities for refactoring.
From the concerns directory from the jplugin package is still there.
- AntiAliasing.java
- Logginging.java
The concerns package modules now also exists in the
org.krysalis.swingx.concerns package. Should this really stay in the
jplugin framework?
So far for the gui component dependencies:
From the org.krysalis.swingx.swing.splitter package
- SplitterBar.java
- SplitterLayout.java
- SplitterSpace.java
These now reside also in jplugin.components.holders.splitter. This
takes the cross dependency from the swingx packages.
JVerticalComponentBar is a really cool holder but am not sure that it
really belongs in the jplugin infrastructure. It is being left for now
until feedback from you all. It also has dependencies on JOutlookBar
from the swingx package.
SingleSheetActivatingHolder contains quite a few dependencies on swingx
at this time so will remain. Have not gone deep enough to see what it
is used for yet. Any ideas? Am thinking at this time it is the main
sheet for the environment so probably should be moved to the swingx
package somewhere.
Actually now that this is being written it looks like all of the modules
in jplugin.components package really belong in the swingx package as
they are used to build the monarch gui interface and really have nothing
to do with a plugin per-sé. This will also take care of the
AntiAliasing concern stated above.
Any ideas here or am I off base?
The resources file for the avalon engine Boot module has been changed to
reflect the new module name references for the refactored items as
stated above.
Will be testing the build process a little later to make sure they all
build and run.
Well so far so good. Not ready for CVS yet IMO until it actually builds
unless any of you guys really have the time to take a look at the code.
Regards
Kenneth
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en