Release 2.3.0
The next minor release of KLighD is here as the first release with accompanying Maven artifacts on Maven Central!
Find the updatesite at https://kieler.github.io/KLighD/v2.2.0/ or in a single zip file below.
Find the Maven artifacts at the Apache repository or the Sonatype repository.
New Features
General
Removals
Diagram Server
- Estimate clip shape bounds to allow the clip shape feature in the web version #158
Changes/Bugfixes
General
- Updated many build dependencies and Java versions #97 #150 #155
- Minor improvements #153
- fixed inset calculation. #25 #154
Eclipse-based
- Replace deprecated WidgetProperties #148 Thanks to @HannesWell
- simplify klighd.ui.printing.dialog #148 Thanks to @HannesWell
- Minor improvements #153
Diagram Server
- Fixed a possible deadlock in diagram generation #157
- added binding to language server to avoid an error in derived language servers, stemming from a newer Xtext 2.28 release #162 #144
- Maven artifacts surrounding the diagram server now use mock SWT dependencies, see more below #63 kieler/SWT-Mock#2
as well as more small fixes for Eclipse and Diagram server behavior.
The new Maven artifacts
The newly published Maven artifacts have the goal to make builds using the diagram server and KLighD's offscreen exporters in a more natural way, by using simple Maven/Gradle dependencies instead of previously used hacky workarounds. Currently the artifacts are mainly built for these two use cases, other use cases might work as well, but you might have to beware of dependency management yourself:
First of all, most of the packages except de.cau.cs.kieler.klighd.standalone and de.cau.cs.kieler.klighd.lsp do not list their dependencies, therefore requiring dependency management by the dependent applications using only the other packages. E.g., some application just creating some KGraphs and use none of the other features will have to include more dependencies. We think this will not be a problem, as non-Eclipse applications always should use either one of the standalone/lsp packages.
Currently the de.cau.cs.kieler.klighd.standalone package works as an entry point for offscreen exporter applications with all dependencies as a bill of materials (BOM) contained in this package.
NOTE: If you only have a dependency on the standalone package, you might need to manually resolve the SWT dependencies if you want to use e.g. some diagram exporter using SWT, see #164. Otherwise if you do not need SWT you may exclude it as shown below and add a dependency to de.cau.cs.kieler.swt.mock:org.eclipse.swt and alike.
For diagram servers, the de.cau.cs.kieler.klighd.lsp package works as another BOM for language server-based applications. Here, the occurrences of org.eclipse.swt, org.eclipse.jface and some occurrences of org.eclipse.ui are being replaced by mock code only providing required API but no functionality. Because of legacy reasons SWT usually is deeply integrated into KLighD's core, but its code is never used in the language server case. As SWT usually introduces platform-dependent packages, this replacement with the mock code makes language servers platform-independent and more leightweight.
If you explicitly use some other KLighD packages in your diagram server application, you therefore might need to also exclude the "real" SWT etc. packages in favor of the mock. An example exclusion in a Maven pom.xml build might look like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>de.cau.cs.kieler.klighd</groupId>
<artifactId>de.cau.cs.kieler.klighd</artifactId>
<version>${klighd-version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.swt</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.ui.workbench</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.jface</artifactId>
</exclusion>
</exclusions>
</dependency>
[...]
</dependencies>
</dependencyManagement>
