Skip to main content

Maven boundaries

3 replies [Last post]
kschaefe
Offline
Joined: 2006-06-08
Points: 0

Part of the move to Maven was to be able to compartmentalize the pieces of SwingX.  So far we have only moved the Painter code into a painter module.  Here are some other modules that I think make sense and some issues surrounding them.

AutoComplete:
  - Place all of the autocomplete classes into a separate module
  - No issues

Actions:
  - Place all of the action code into a separate module
  - No issues

Graphics:
  - Place the geom, graphics, and image packages together.
  - The three utils classes in the Painters package probably belong here.  Would cause Painters to have dependency on Graphics.

Painters:
  - Currently contains some utils classes and beans clases that don't belong there

Beans:
  - Bean package is too small to really need its own module, but should definitely move from painters.
  - Add to a yet to be determined util module?

Plaf:
  - Separate the plaf support code, so that it is easier for third-parties to build custom widgets.
  - Would be an extremely small module; is it worth it?

Prompt:
  - Create a module for prompt support.
  - Currently, that is not a lot of code; is it worth it to make a separate module?  Perhaps when we support non-textcomponent prompts?

Looking for any ideas, feedback, or comments you might have on how we break up SwingX into reasonable chunks.

Karl

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11
Points: 0

dont ;-)
I think (and think I commented previously) that the only reason to separate modules out - which _is_ a problem for anybody not using maven as we have been told - is a strong idea of reason for living on its own.
Better concentrate on improving SwingX than on wasting (okay, certainly my opinion ;-) time on separating out packages nobody really would use on their own
Cheers
Jeanette

tbee
Offline
Joined: 2003-07-23
Points: 0

There are many reasons why code is split out into modules, but different view points to the code can have different reasons. Modularizing from a source code structural view point can be done to enforce a cleaner separation of concerns. From a security standpoint to allow different edit permissions on the modules in code base. From Maven's position it is about distribution size; can it be split, because certain parts (and their inherited dependencies) are often not needed by all users.
So; what is the reason for the split? Is it just for Maven or cleaner separation of concerns? (I read a lot of the latter in between the lines.)

kschaefe
Offline
Joined: 2006-06-08
Points: 0

I had a very nice (and long answer) that was swalloed by a server error last week. So, I'll try again....
I think the intent is two-fold and you are pointing out both branches. The best reason is to help us produce better code by understanding our interdependencies and breaking those which should not occur. JXBusyLabel and BusyPainter were inappropriately, bidirectionally linked. Creating and keeping clean separation is a difficult task that is eased when using the Maven modules.
What we get for free ;) when we do that is smaller downloads, by allowing users to grab only the pieces that they need. Working at a company where we are building a rich internet applet with Swing, download size is extremely important. Making SwingX friendlier for consumption in applets and Web-start applications by reducing its size makes it a better product.
Karl