Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modules, Dependencies and Versioning #336

mgarin opened this issue Sep 16, 2015 · 4 comments

Modules, Dependencies and Versioning #336

mgarin opened this issue Sep 16, 2015 · 4 comments


Copy link

@mgarin mgarin commented Sep 16, 2015

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 #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 #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.


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 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.

@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 WebLaF modules, dependencies and versioning improvements WebLaF modules, dependencies and versioning Sep 16, 2015
Copy link
Owner Author

@mgarin 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

Copy link

@iamchathu iamchathu commented Sep 16, 2015


@mgarin mgarin mentioned this issue Sep 30, 2015
3 of 7 tasks complete
@mgarin mgarin changed the title WebLaF modules, dependencies and versioning Modules, Dependencies and Versioning Jun 10, 2016
@mgarin mgarin added major and removed enhancement labels Sep 16, 2016
mgarin added a commit that referenced this issue Dec 6, 2016
- 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
Copy link
Owner Author

@mgarin mgarin commented Dec 6, 2016

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.

Copy link
Owner Author

@mgarin mgarin commented Aug 6, 2019

NinePatchEditor have been moved to separate ninepatch-editor module and will now have its own weblaf-ninepatch-editor-xxx.jar artifact.

@mgarin mgarin pinned this issue Apr 22, 2020
@mgarin mgarin removed this from the v1.9.0 milestone Apr 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.