Modules and dependencies

In the first wave of changes I have separated WebLaF into three base modules: core, ui and demo. Also core and ui have received their own artifacts to allow their agile usage. Those changes will be kept intact in v1.2.9 release to avoid delaying release date even more.

But with the next v1.3.0 update I want to make some further steps toward extracting some of big library parts which might not even be connected to the core or ui directly and would work just fine as a standalone functionality unrelated to L&F in its basic form.

I am not completely sure what those changes will include in the end, but here are some initial ideas:

• Move some dependencies from core module
  java-image-scaling-0.8.6.jar - Generally should not be required by the core as it is not used there
  jericho-html-3.3.jar - Also used only by ui on practice so should not be required in core
slf4j-simple-1.7.12.jar - Sample implementation that should not be required in core or ui
  Other dependencies (slf4j-api and xstream) are used across all modules including core so I doubt it will be possible to get rid of them at this point.

• Move PluginManager into plugin module with weblaf-plugin-x.x.x.jar artifact
  PluginManager has grown to be a powerful tool and have proven to be extremely useful on our several internal projects. Though it is not directly connected to WebLaF core or ui, not even demo actually. So it might be a good thing to move it into a separate module with its own artifact. Right now it is included into core module.

• Move LanguageManager intolanguage module withweblaf-language-x.x.x.jar artifact
  LanguageManager is a special tool which allows you to easily support multiple languages within your applications. Its core implementation is not tied to Swing as it only works with its own data. That means you can use its core for any kind of desktop or server Java applications. So it might be reasonable to separate it into its own module.

• Move SettingsManager into settings module with weblaf-settings-x.x.x.jar artifact
  Similar to LanguageManager - SettingsManager core implementation is not tied to Swing and can be used to store any kind of settings with ease and it will also be separated into its own module.

• Move all image-related features into image module with weblaf-image-x.x.x.jar artifact
  There are plenty options to process images within WebLaF and a lot of different utilities to work with them and use them within UI and various components. Including some options to work with 9-patch images. So all that stuff might actually be moved into separate image module as well as the java-image-scaling-0.8.6.jar dependency it would rely on.

• Additional SVG-related modules
  There should be three new modules - svg, svg-salamander and svg-batik. It is all described in SVG support based on SVG Salamander and Batik #337 separate issue in details.

• Move custom Swing components into ext module with weblaf-ext-x.x.x.jar artifact
  Extended components are a huge part of the library but currently they are heavily hardcoded into different existing systems so moving them out will also require adjusting various managers and behaviors to be more versatile. That will eventually simplify the process and reduce the time required to add new components into the library.

• Move various UI tools into tools module with weblaf-tools-x.x.x.jar artifact
  This would include tools like StyleEditor, InterfaceInspector and HeatMap which won't normally be needed in desktop applications and can mostly be useful for developers to adjust look and feel and look for UI issues like rendering bottlenecks, incorrect styles, messed up layouts etc.

• Move 9-patch editor into ninepatch-editor module with weblaf-ninepatch-editor-x.x.x.jar artifact
  9-patch resources editor might not be really useful in deployment so it is reasonable to move it into the separate module. It could also contain some additional useful resources then, like some example sets of 9-patch images which can be used/edited.

• Move StyleEditor into style-editor module with weblaf-style-editor-x.x.x.jar artifact
  StyleEditor is not needed for running and using L&F, so it's better if it would be moved into it's own module. First - it will not pollute the main codebase, second - it will not slow down basic L&F package loading due it's extra heavy styles, and third - it will be easier to support it as a somewhat standalone feature. Read Revamp for StyleEditor feature #540 for more details.

• Move skins into separate modules
  Since Skin implementations are not really needed for either of the core library modules they can be easily separated into standalone modules. For now there could be two possible modules: light-skin and dark-skin. There are also material-skin, flat-skin and modena-skin planned for the future.

• Move icon sets into separate modules
  Same case as for the Skin implementations - IconSet implementations are mostly resources and can be easily separated into standalone modules. That would allow simple exclusion of unused ones and core modules lighter.

So the final list of basic modules would look something like this:

• core
• plugin ( dependencies: core )
• language ( dependencies: core )
• settings ( dependencies: core )
• image ( dependencies: core )
• svg ( dependencies: core image )
• svg-salamander ( dependencies: core image svg )
• svg-batik ( dependencies: core image svg )
• ui ( dependencies: core language settings image )
• ext ( dependencies: core language settings image ui )
• tools ( dependencies: core language settings image ui ext )
• light-skin ( dependencies: ui )
• dark-skin ( dependencies: ui )
• light-icon-set ( dependencies: ui )
• dark-icon-set ( dependencies: ui )

And three extra modules:

• ninepatch-editor ( dependencies: core language settings image ui light-skin dark-skin light-icon-set dark-icon-set )
• style-editor ( dependencies: core language settings image ui light-skin dark-skin light-icon-set dark-icon-set )
• demo ( dependencies: core language settings image svg svg-salamander ui light-skin dark-skin light-icon-set dark-icon-set style-editor )

Core will become even lighter with those changes and as an example - you will be able to use features like PluginManager in any project by just including core and plugin. I might even think about extracting some sort of api which will include the most basic things which will be enough for other modules that currently depend on core.

I might also consider a few more general-purpose modules, for example file module which will contain a set of utilities to work with files and which will be used by modules like plugin or settings.

Note that some of these changes might end up not getting into final v1.3.0 release as this is just a sketch. If anyone has any thoughts on the case - I would love to hear your opinion.

Versioning

Current WebLaF versioning will take its first step towards semantic versioning system. Unfortunately till release of WebLaF v2.0.0 it will not be completely fair and updates might still contain some minor API breaks due to a huge number of outdated stuff within the library which I am trying to remove or replace and some other specific things. Starting with release of v2.0.0 it will be used as intended.

Also, as it was mentioned before - v2.0.0 will be modified to support only JDK 8+ which will allow me to remove a lot of workarounds cases from the code, improve it and its overall usability. At that point some minor changes and fixes will still be added into v1.x.x version, but all major features will only be included into v2.x.x.

Reasoning

There are multiple reasons why I decided to split up the library even further:

• Some existing features can easily function as standalone libraries without having any dependencies and a few of them were even designed to work and exist like that but there were no modules back then
• Some pieces of code and/or features are partially or completely unrelated to L&F and simply included as an "utility" part of WebLaF for convenience of applications development
• Library core and ui modules are becoming quite heavy and messy and have a lot of dependencies which were not intended to happen in the beginning, that generally leads to increased development time and sometimes causes unexpected internal issues

So I want to break down the library into smaller parts which will have transparent dependencies and will be much easier to maintain, modify and enhance.