How do I add additional plugins to my already existing CKEditor? - ckeditor

This link https://docs.ckeditor.com/#!/guide/dev_example_setups strongly encourages use of the CKEditor builder in order to manage plugins, and strongly discourages installing plugins manually.
Manual Download and Installation of Additional Plugins (Not Recommended)
Although at a first glance it looks like the simplest way
of adding plugins to CKEditor, it is not only inefficient but also may
result in a headache when trying to add plugin A, that requires plugin
B, that requires plugin C (...and so on).
In a brief summary it involves the following steps:
Downloading the predefined package (Basic/Standard/Full) from the
Download page.
Downloading additional plugins manually from the
Add-ons Repository.
Downloading plugins required by additional plugins
manually.
Enabling additional plugins manually through
CKEDITOR.config.extraPlugins.
Then it tauts its Builder:
Using Builder (Recommended)
Using Builder to build a bundle with all required plugins is highly recommended in case of using customized
packages, especially those with additional third-party plugins.
Refer to the Installing Plugins – Online Builder Installation article
for information about building a custom editor package.
But in visiting the page for Builder, unless I'm missing something, it only builds a completely brand new CKEditor from scratch. I can't find any way to keep my current configuration and add plugins.
If there is literally no way to add existing plugins except by doing it manually, I find the language in the docs strongly discouraging this very strange (since 99.9% of the time I'll want to add plugins on the fly and not at the very beginning).
So is manually adding plugins the way to go if I already have other stuff set up?

Most crucial point to keep up with builder is to keep your CKEditor up-to-date. Imaging pain of updating all plugins manually.
Just build our base CKEditor - with ckeditor itself and plugins which 100% you will use in your project.
But no one stops you from adding your own or community plugins. You just need to configure and keep config.js in your ckeditor folder. so you will have your extra plugin configured on each ckeditor update.

Related

Remove host's source code from plugin to reduce file size

I'm currently experimenting with golang's plugin system. A problem which I experienced in my testings is that the file size of the plugins is relativly big.
The application loading the plugin will be referenced as "host".
The host application itself is ~50MiB big since it is a web application and should be extended with plugin functionality.
I've implemented a small plugin loader to start the plugins up.
The plugins may use the already existing APIs in the application for example to access the database.
I've prepared a example plugin for this question. The plugin .so file size is ~39MiB. This gives me the reasonable suspicion that the plugin also contains source code from the host application.
Command used to create main.so:
go build -ldflags="-s -w" --buildmode=plugin main.go
Is it possible to "remove" the duplicated source code from the application to reduce file size since it is already loaded on runtime when the plugin gets loaded?
Plugin loader: https://github.com/jonasfranz/gitea/blob/feature/plugin/modules/plugins/loader.go
Example plugin: https://git.jonasfranz.software/JonasFranzDEV/giteaplugin
Source code is not included in plugins. But what is included in them is their dependencies, recursively. This is so because there is no guarantee that the main app that loads the plugin also contains the dependencies, so to ensure the viability of the plugin, its dependencies must be self-contained.
This does not cause problems if the main app also include the same dependencies (with the same version), they will only be "instantiated" once in the go runtime, for details, see How do Go plugin dependencies work?
What to do in order to reduce plugins' sizes? Besides removing the debug information (what you did), you should minimize the dependencies.
This may require redesign and major changes both in the plugin or in the app you wish to create the plugin for. For example, plugins should not refer to "implementation" packages, plugins should only refer to "interface" packages. If interfaces and implementations are not separated, this may not be possible (hence may it be required to change the main app too).
You may also try utilities that try to compress binaries, for details see: Shrink your Go binaries with this one weird trick

What'll change about maven extensions according to this line in apache doc?

I found this note in the Maven's documentation:
You can add elements to this classloader by extensions. These are loaded into the same place as ${maven.home}/lib and hence are available to the Maven core and all plugins for the current project and subsequent projects (in future, we plan to remove it from subsequent projects).
I couldn't understand what they mean by "subsequent projects" here. As far as I understand, extensions are enhancements to lifecycle phases of Maven and are not project specific. So it makes sense to work for all the Maven projects.
Question: Can anyone explain what this statement means "in future, we plan to remove it from subsequent projects"
First an extensions can be extensions of a life cycle but not need to. You can implement an extensions also as an EventSpy for example.
This documentation is related to the Core Classloader which is available within such extensions and makes it also possible to enhance it via an extensions. This classloader contains those files from ${maven.home}/lib which is not a good idea and not necessary. It would be better having only the Maven Plugin API there and it's instances which are currently used and not more...
There existing some extensions like Wagon which are using to make a transport in special cases possible which could be project specific.
Starting with Maven 3.3.1 the core extensions mechanism has been improved to make loading project specific extensions more simpler which means they are located into ${maven.projectBasedir}/.mvn/extensions.xml file and also being loading from an repository. Before 3.3.1 you need to do that manually via mvn -Dmaven.ext.class.path=extension.jar.

Maven site in gradle

Is there a plugin in gradle which can generate maven site similar thing? It would be great if it was compatible with current maven site apt format file.
It seems that there are two plugins, this and this. The first one was committed four years ago, I know nothing about the second. So it seems that these plugins will not be helpful.
I just wrote one as part of Gradle Fury. The primary plugin(s) (it's really just a collection of scripts) for Gradle-Fury is to enhance/fix many of the gradle short comings on publishing, android stuff, pom stuff, etc. Since there's pretty much no standard way for most things in gradle, we jam most of those configurations in the gradle.properties file. That said, the site plugin does depend on those settings to correctly stylize the site.
In short, to apply to your project...
put this in your root build.gradle file
apply from 'https://raw.githubusercontent.com/gradle-fury/gradle-fury/master/gradle/site.gradle'
Next edit your gradle.properties file and use this link as a template for your pom settings....
https://github.com/gradle-fury/gradle-fury/blob/master/gradle.properties
Create a src/site/ directory.
Make a src/site/index.md file as your home page
Copy/clone following files/folders from https://github.com/gradle-fury/gradle-fury/tree/master/src/site
css
images
img
js
template.html
Finally, build the site with gradlew site. Default output is to rootDir/build/site
Don't like the way it looks? (it looks like the Apache Fluido theme from the maven site plugin). Just edit template.html to meet your needs.
I'm currently working on a mechanism to bootstrap the site plugin which will remove a few of these steps, but that's what it is right now. More info and complete feature list is at the wiki
One last note, should run gradlew site after all of your check tasks, but it's not wired up to depend on it. Basically, anything that produces reports for your modules should be ran before site since it's aggregated into the site package, including javadocs and much more. The rest of the fury scripts help automate much of the painful configuration steps. Worth checking out (see the quality and maven-support plugins)
Disclaimer: I'm one of the authors.
Edit: site preview: http://gradle-fury.github.io/gradle-fury/
Edit: We just cut an updated version that makes manual creation of src/site and all the copy/clone tasks from the master repo unnecessary. Just run gradlew site while internet connected and it'll do the rest for you.

How to analize/visualize OSGi, maven dependencies

I am trying to build Aptana studio using Maven/Tycho.
It has a lot of Eclipse plugins and I would like to exclude some of them from the build. However the excluded plugins may be required by other plugins.
How to see what plugins are dependent on the current plugin? Is the some tools to visualize dependencies in a directed graph?
The Plugin Dependencies View which comes with PDE has a button (two-to-one graph) to show plugins depending on the focused plugin.
If you want to see the full picture, then you will need to install the PDE Incubator Dependency Visualization (update site link included). Note this often gets quickly unreadable.
UPDATE by Paul
Update site http://download.eclipse.org/eclipse/pde/incubator/visualization/site
Need to uncheck "Group items by category" for item to appear.
It is version 0.5.0.20090415
So it is almost 5 years old and is unlikely to ever graduate from incubator.
Added Marketplace entry: https://marketplace.eclipse.org/content/pde-incubator-dependency-visualization

Is it possible to use wro4j to parse files and generate 'sass' versions of css without applying any bundling?

We are trying to run a SASS parser over our CSS files as part of our Maven build, but do not want them to be bundled together at the same time during this phase of the Maven life cycle.
However, I cannot see a simple way of using wro4J to do this without specifying each individual file as its own bundlem which just doesn't feel right. Have I missed some configurationm or is bundling so much at the core of the design of wro4J that it must be used like this?
This feature is not supported by wro4j yet, but it is planned to be added in future. In the meantime, you can use SassCssProcessor with a custom maven plugin which just applies the processor on each resource from a configured folder. The link to the issue describing the feature you need: https://github.com/wro4j/wro4j/issues/583

Resources