[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