I am trying to use this plugin to setup scheduled notifications. But it doesn't works at all.
https://github.com/katzer/cordova-plugin-local-notifications
I have installed plugin both through npm and cli(for 0.9-beta version).
I am copying same code from repository only.
Calling it after deviceready event.
But nothing works.
Related
I have a deprecated Jenkins plugin installed (WMI Windows Agents Plugin, v1.8.1), and I'm trying to uninstall it.
Problem
When I uninstall the plugin from the Jenkins web UI, it gets stuck at "Uninstallation pending" no matter how long I wait.
What I Tried
When I do a safe restart after a long wait, the UI shows that the plugin is still installed, as if I had not attempted an uninstall. I also tried disabling the plugin before attempting another uninstall—still stuck at pending uninstallation. Doing a yet another safe-restart after a long wait doesn't work either.
After you click uninstall, while the status is "Uninstallation pending",
click on Available Plugins and without selecting any plugins click on Download now and Install after Restart.
For some reason this completes the uninstallation
I initially couldn't uninstall the WMI Windows Agents Plugin on Jenkins 2.375.2 either.
This comment on JENKINS-70454 suggested that upgrading to Jenkins 2.375.3 might help, and indeed:
I could uninstall the plugin as expected after upgrading.
FWIW: I assume that hudson.PluginManager#considerDetachedPlugin was somehow responsible for keeping that plugin, as
journalctl -ujenkins | grep windows
showed me
hudson.PluginManager#considerDetachedPlugin: Loading a detached plugin as a dependency: /var/lib/jenkins/plugins/windows-slaves.jpi
after every reboot (but to be honest, I don't know much about detached plugins).
I am using Jenkins websphere deployer plugin to deploy application to IBM WAS 8.5.5.
The ear deployment is successful but the start up is not successful though Jenkins shows success message.
I assume the ear (around 90MB) takes time for expansion in the remote server, and Jenkins success message is before the complete expansion. Is there a way to delay the process of startup after deployment is done.
Can anyone suggest?
You cannot work around this issue since it requires a modification to the websphere deployer plugin. There is a known synchronization issue for large EAR files. I believe there was a pull request that fixes this issue and was merged into the codebase for v1.3 of the plugin. This version is not yet released but can be viewed on github if you wish to compile and try it out for yourself.
You will need to use maven and to manual imports into your .m2 repository to compile and test this code in jenkins.
Reference: https://github.com/jenkinsci/websphere-deployer-plugin
When building an Hybrid iOS Cordova application (relying on Cordova CLI) I stumbled the need to build a custom plugin.
My workflow was the following:
I scaffolded my Cordova plugin outside my Hybrid Application
directory.
Code it blindly (in Vim) and push to GitHub.
Use cordova plugin rm and cordova plugin add to reinstall the plugin.
Test.
Repeat from step 2.
I deployed the plugin successfully in the product, however this process of coding Objective C blindly with Vim and doing a whole push to GitHub just to test it in my project feels awkward, however I couldn't find any information on the internet about a better workflow.
Ideally, this is the workflow I'd expect:
Scaffold my plugin inside my application directory (maybe in plugins/ or in my custom src/) and publish when I'm ready to do so (or not publish closed-source plugins at all).
Code the plugin using XCode.
Reinstall the plugin from the local filesystem, this totally avoiding a separate repo/push.
Test and iterate from step 2.
Is this workflow achievable?
You could try the following workflow:
have the plugin in a specific directory within the project
have a grunt task that watches for changes in the above directory that copies the relevant files to the plugins directory and runs cordova prepare right after the copy step is complete
edite and test...
Personally, I've used the same approach, with a twist:
Step 1:
I've coded the boilerplate part of the plugin using Sublime Text (vim works as well :) )
Step 2:
cordova plugin add --link ../path_to_my_plugin
Step 3:
I can add the platforms/android to Android Studio (you should be able to do the same with platforms/ios)
Step 4:
Any changes to the native part are reflected in the original sources (because of the --link parameter), any changes needed to the js part of the plugin I can edit directly in the app directory itself
Step 5:
Commit and push the files in your original plugin directory
If you need to reconfigure some part of the boilerplate (plugin.xml configurations), I've just:
cordova plugin remove <plugin-name>
And then resumed from step 2
I'm using Unity3D, Jenkins and Bitbucket private repository. Jenkins is installed in cloud service. I want to automate buildings and probably run some tests in Jenkins before pushing to repository.
I have configured Jenkins properly to such step that it works when pushing some changes to repository, but this configuration doesn't contain configuration of Unity3D Build Plugin. In order to get Unity3D Build Plugin working properly you must configure it by providing the directory of your Unity3D Editor. Problem here is that Jenkins is installed in cloud service and Unity3D Editor on my computer. If you want to configure Unity3D Build Plugin you must provide it's .exe file location. So my question is that is it possible to tell Jenkins that is installed in cloud service that Unity3D installation directory is located at my computer? If yes how it is done?
right now it's a limitation on the plugin. I hope to fix this. Open a bug in the issue tracker (https://issues.jenkins-ci.org/browse/JENKINS) and let's move the conversation there!
I am using some plugins which depend on snapshot versions of other plugins.
As I understand, Ivy tries to fetch the newest version of these plugins every time you start grails. If Ivy does not succeed, grails will not start :-(
As I like to develop offline, I am now looking for a way which lets me avoid this behaviour...
You could pull them down and store them on your machine using a local repository and comment out any remote repositories. Here is some documentation. Scroll down to "local resolvers"