Modules, Dependencies and Versioning #336

mgarin opened this Issue Sep 16, 2015 · 3 comments


Planned in v1.3.0

2 participants

mgarin commented Sep 16, 2015 edited

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 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 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 module
    As described in a separate issue here: #337

  • Move 9-patch editor into ninepatcheditor module with weblaf-ninepatcheditor-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.

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 )
  • ui ( dependencies: core language settings, image )
  • ext ( dependencies: core language settings, image, ui )

And two extra modules:

  • ninepatcheditor ( dependencies: core, language, settings, image, ui )
  • demo ( dependencies: core language settings, image, svg, ui )

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.


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.


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 convenient applications development
  • Library core and ui modules are becoming quite heavy and messy which 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.

@mgarin mgarin self-assigned this Sep 16, 2015
@mgarin mgarin added this to the v1.30 milestone Sep 16, 2015
@mgarin mgarin changed the title from WebLaF modules, dependencies and versioning improvements to WebLaF modules, dependencies and versioning Sep 16, 2015
mgarin commented Sep 16, 2015

Also, as a side note, WebLaF will be published into maven repository shortly after v1.29 release and I will keep releasing new updates there (and probably even some snapshots), so this wouldn't be a problem anymore.

For reference: #89



@mgarin mgarin changed the title from WebLaF modules, dependencies and versioning to Modules, Dependencies and Versioning Jun 10, 2016
@mgarin mgarin added major and removed enhancement labels Sep 16, 2016
@mgarin mgarin added a commit that referenced this issue Dec 6, 2016
@mgarin PluginManager
- Moved `PluginManager` into a separate library module [ #336 ]
-,, - Proper checks for headless environment

- - Added headless environment check method
- - Removed static icons initialization to avoid issues in headless environment

- build.xml, - Updated ANT build with new `weblaf-plugin-xxx.jar` artifact
- build.xml, - Slightly reworked the way classpaths are defined to make them more convenient
- pom.xml - Added for plugin module, slightly updated for other modules
mgarin commented Dec 6, 2016 edited

PluginManager is now placed within a separate plugin module and has its own new weblaf-plugin-xxx.jar artifact which have been added into ANT build script and maven project. From now on all styling branch based build will have that additional artifact containing PluginManager functionality.

It was separated before v1.3.0 update due to some changes in our internal projects. This change should not affect anything as PluginManager package and API is still exactly the same. But you might want to add the new artifact as a new dependency for your project unless you are using complete builds or maven repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment