I'm on Ubuntu 14.04 and I would like to create a build of CKEditor. I've read: http://docs.ckeditor.com/#!/guide/dev_build.
First issue: I don't have any "build.sh" in my CKEditor folder. Solution: download https://github.com/ckeditor/ckeditor-dev/blob/master/dev/builder/build.sh .
Second issue: the build.sh above is not totaly correct, I had to modify some locations (e.g. "../.." instead of "."). But I think it's now ok since I don't have messages like "file not found" anymore...
Third issue: I've several warnings like:
WARNING: it was impossible to update the lang property in /home/sebsheep/progs_div/albums_tests/ckeditor/release/ckeditor/plugins/youtube/plugin.js
Moreover, I've the impression that CKBuilder only copy my initial folder recursively, as we can see with "/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor" (thoses files actually are on my disc) on this message:
WARNING: it was impossible to update the lang property in /home/sebsheep/progs_div/albums_tests/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor/release/ckeditor/plugins/indent/plugin.js
Those warnings never stop, I have to C-c in order to stop the program.
What am I doing wrong?
I guess that you tried to build CKEditor using a built version which obviously does not contain necessary tools.
To build CKEditor from source:
Clone CKEditor development repository, or just download it if you don't know git.
Add 3rd party plugins to the plugins/ directory.
Modify dev/builder/build-config.js (edit the list of plugins).
Run dev/builder/build.sh
Related
I am using the primary GO extension.
I use VS code a lot, now I'm learning GO lang.
And when I open VS Code every time I'm getting this:
Error loading workspace: found module "main.go" twice in the workspace.
While running the code it's giving the right output.
I don't know how to fix this.
Anybody, help me with this error.
It would be better to open in VSCode only one folder with its own go.mod project.
A workspace with multiple go.mod/project should be supported with 1.18
The go command now supports a "Workspace" mode.
If a go.work file is found in the working directory or a parent directory, or one is specified using the -workfile flag, it will put the go command into workspace mode.
In workspace mode, the go.work file will be used to determine the set of main modules used as the roots for module resolution, instead of using the normally-found go.mod file to specify the single main module.
As described in "How to make VScode Go work in a Multi-Module Repo" from Varun Kumar, this used to work:
If you want to work with all the nested modules in a single workspace, there is an opt-in module feature that allows to work with multiple modules without creating workspace folders for each module. Set this in your settings -
"build.experimentalWorkspaceModule": true
But as per september 2022 is deprecated.
See more at gopls documentation "Setting up your workspace".
I have found and fixed a bug in a third-party Meteor package. When testing the fix, I ran into some unexpected difficulties, which I describe below.
What is the recommended method for testing a patched third-party package in Meteor?
On Mac, the command meteor add username:package-name copies files from Atmospherejs.com to the folder at ~/.meteor/packages/username_package-name/. I located the original file in this folder and edited it.
The issue was simple. The original script included the lines...
options.userCallback = function (error) {
if (error.error ...) {}
All I needed to do was to change this to:
options.userCallback = function (error) {
if (error && error.error ...) {}
However, I had now added 9 characters to file. When Meteor compiled my app, it cut off the last 9 characters of the script, and this caused a runtime error. Presumably, Meteor stores the expected length of the file somewhere. As a hack, I removed more that 9 inessential whitespace characters from the file. Now Meteor complained that it could not read the entire file. So I added too much whitespace at the end of the file, and Meteor was happy to trim off the characters that it didn't want.
I was now able to check that my fix was valid, and post an issue for the package on its GitHub page, so that the original developer can release a fix.
This particular package was included as part of a different package, so it was installed as the result of a meteor add otheruser:different-package-name command.
What is the accepted method for overriding the files stored in the default package location, so that a patched version can be used instead, without Meteor getting persnickety about the exact number of bytes in the script file?
You spent too much time to prevent meteor update your change to the original again. The simplest way is
Fork the original project
Pull your forked repo into folder packages in your meteor project
Change anything you want on the forked
Include it to the meteor packages file (.meteor/packages). Remember to remove the old package by triggering meteor remove <package-name>
Run project
By default, meteor will look at the packages folder first for the external package, if it cannot found, then it will look up on Atmosphere.
By that time, just notify the original developer by the pull request from your repo.
I already finished my project, it works and runs perfectly on the simulator or in my own device. When I select to Archive the project to upload de build to Itunes Connect, I get all these compile errors
"Use of undeclared type MBProgressHUD"
"Use of unresolved identifier MPProgressHUD"
And so on..
NOTE: I'm using CocoaPods for this library
What solved it for me was adding import MBProgressHUD in the classes where I use this library, not only in the Bridge-Header.h
Navigate to your project build settings and find the “Swift Compiler – Code Generation” section (You may find it faster to type in “Swift Compiler” into the search box to narrow down the results)
Next to “Objective-C Bridging Header” you will need to add the name/path of your header file. If your file resides in your project’s root folder simply put the name of the header file there. Examples: “ProjectName/ProjectName-Bridging-Header.h” or simply “ProjectName-Bridging-Header.h”.
Refer this link http://www.learnswiftonline.com/getting-started/adding-swift-bridging-header/
Welcome to Cocoapods Hell (a.k.a. : where the magic ends), where one must dive into his project build settings and make sense of what went wrong...
It's very hard to answer to you, as any number of reasons might be causing that.
Do you use the same target for Build / Run & Archive ? It might be because your libPods.a isn't copied into your Archive target
Have you installed Pods using pod install , have you tried playing that command again. (yes, faced with magic going wrong, one can sometimes rely on magic to save him again)
'Build' and 'Archive' product often differ in the build configuration they use (Build most of the time uses 'debug' configuration, while Archive uses 'release' configuration... ). Check your Pods configuration files (debug/release) and make sure they both include your MBProgressHud. Also, in your Project 'Info', check which pods Xcode configuration files are selected for 'debug' and 'release'
Good luck !
(PS : as MBProgressHud is a single file, and one you can often change, another solution is to get rid of Cocoapods and just copy/paste it)
I'm new to this repository, I already installed it and it is working fine on Ubuntu 14.04. Now I want to personalize it and I've found everywhere that to avoid losing your customizations, you should place them in [dspace-source]/dspace/modules/xmlui/src/main/webapp/themes (I'm choosing xmlui since that is the interface I'm using and themes because that is the only customizations I want to do for now) and then you should do a mvn package from [dspace-source]/dspace for it to apply the changes to the installation directory ([dspace]). I have done this but the new theme I created doesn't appear in the installation directory. Should I do an ant update after the mvn package? Am I missing something for the documentation?
Thanks for the help!
You are correct. mvn package will build the code in dspace-source/target. ant update will copy the code from dspace-source/target to your installation directory. The maven build is generic and does not know your configuration settings. The ant task will read your configuration settings (which contain the install path).
After running ant update, you should restart tomcat.
Because the maven/ant cycles can take some time, I will occasionally make changes to uncompiled files (xsl, js, css) on the source branch and then copy them directly to the install branch.
Beware of making changes directly in the install branch since it is easy to overwrite with the ant command.
The cocoon layer of XMLUI does cache some files. If you make a change and it does not seem to take effect, sign in with an admin login and go to Administrative->Java Console->Clear Cache to force a change to be reloaded.
I received a new version of a plugin of a project I work in collaboration with other people.I copied it over the old version in the /plugin directory. Eclispe (3.7.2 on Win7) ignored the plugin (don’t show up in the Help/About Eclipse/Installed Plugins). I put the old version back (I put an “_old” at the end of the .jar file) and it worked again but the plugin’s command in the menu appeared with a “%” character at the beginning. After some more copying of old/new version in the /plugin directory, even the old plugin won’t install. I put back an acient original version of the plugin, but still not working. It just stop suddenly working. I checked my permissions on the /plugin directory, started Eclipse as an administrator, but no success.
Thanks.
First of all you should put both versions in plugins directory only if they have different versions in plugin.xml definitions but even in this case only one of them probably will be active i.e. will add its contributions to Eclipse. You should use copy/paste actions to provide additionals to Eclipse carefully, plugins and features directories are not supposed for manual usage. To manage your plugins easily follow the dropins directory usage. For now the best you can do is to remove all versions of your custom plugin and run Eclipse to the clean workbench.