My plugin has some dependencies and it automatically install these dependencies (other third party plugins) when I install my plugin.
When I uninstall my plugin, its dependencies are uninstalled as well.
As these other plugins may be useful to the user, is there any way to uninstall my plugin but leave these dependencies installed?
As far as I could investigate, if I install these other plugins before installing my plugin then they will remain there, but if I install them as dependencies they get ripped off.
If you installed the dependencies explicitly before installing your main plugin, then P2 treats them as installed by the user. In the dependency case, it treats them as installed by the system.
All plugins, which were installed by the system (not by the user), are automatically removed during an uninstallation, if there are no dependent plugins. At least that is what I remember from an EclipseCon presentation by the P2 guys.
That said, it is simply not your job to decide for the user. The user installes features. If those features are uninstalled, their plugins are gone. If the user still wants that functionality, he should install the features containing those plugins.
I'd suggest you disable the plugin instead of uninstalling it, if possible. The answer swimmingfisher provides to Temporarily Disable Eclipse Plugin tells you how to do it.
Related
I've installed this plugin to WebStorm, but I can't seem to find a way to actually launch it.
How do I do that?
That plugin is available for IntelliJ IDEA only and not compatible with any other products like WebStorm/PhpStorm etc (possibly because it may require Java-specific functionality that other IDEs do not provide).
You can see all WebStorm-compatible plugins if you switch to WebStorm tab (e.g. https://plugins.jetbrains.com/?webStorm).
You can also see (and install) such plugins directly in WebStorm -- Settings/Preferences | Plugins --> Browse repositories...
Recently I deployed some projects like trntv/yii2-starter-kit and so on.but all applications are publishing assets on '#vendor/bower' instead of'#vendor/bower/bower-asset'. I have read the question Yii2 Composer manage package in bower and bower-vendor and solved it . but I still feel confused about the directory vendor/bower/bower-asset.
What's the part does bower/bower-asset play in php application? it is not a composer package but many theme store in there. Furthermore, bower is a dependency management for javascript just like Composer for PHP , but how does it solve dependency for js package by PHP on this occasion that I have not install node.js environment?
The idea of Composer Asset Plugin is to download Bower / NPM packages and manage their dependencies without having Node JS, Bower and NPM installed (through PHP / Composer). Also it adds possibility to add JavaScript dependencies for PHP packages that use JavaScript libraries.
See for example yii2-bootstrap Yii2 extension (PHP) has a dependency on Bootstrap (JS + CSS):
"bower-asset/bootstrap": "3.3.* | 3.2.* | 3.1.*"
When you run composer install or composer update, all JS dependencies will be installed to vendor/bower folder.
This is built into the core, but very ambiguous, receives a lot of criticism and there are plans to remove it in 2.1.0 (as far as I remember, it was included before release of 2.0 even it was unstable). Unfortunately this is required and there is no normal way to disable it.
You can read more info on the extension's Github page.
As for folder name, it should be named bower, not bower-asset, if you installed everything correctly.
It's named like so automatically, make sure you have the latest version of plugin:
composer global require "fxp/composer-asset-plugin:~1.1.1"
I'd recommend to even switch to:
composer global require "fxp/composer-asset-plugin:*"
If you have problems or errors, execute:
composer global remove "fxp/composer-asset-plugin"
Then reinstall it again, delete vendor and composer.lock in your application folder and run:
composer install
I am trying to install M2release plugin in Hudson.
I cannot install plugin using Hudson plugin update page due to lack of proxy settings. So i downloaded hpi file and used upload plugin option to deploy it.
Now Hudson home[directory] is showing the plugin inside plugin directory but i can't see the plugin in list of installed plugins on Hudson UI also plugin is not available on job configuration page. I hvae already bounced hudson server twice.
What am i missing here? Any additional steps are needed to install plugin manually?
Your steps seem fine.Since M2release plugin has moved to Jenkins now, so make sure you downloaded the compatible version with Hudson.
I have a few plugins in my Jenkins installation which I no longer need. I've already disabled the plugins (and my build still work), and I'd like to remove the plugins completely. What is the right process for completely removing a Jenkins (Hudson) plugin?
As mentioned by Jesse Glick in his answer, if you are using Jenkins 1.487 or higher, then there is a native way to uninstall plugins in the Jenkins UI. See JENKINS-3070 for details.
If you are using a version of Jenkins earlier than 1.487, then you can try manually uninstalling the plugin. As some people point out in the comments, this may not work on some platforms (in those cases, upgrade to at least 1.487 so that you can use the official uninstall feature).
To manually uninstall a plugin, stop Hudson/Jenkins, go to your HUDSON_HOME/plugins directory and remove both the .hpi file and the folder with the same name. So, if you were going to remove the CVS plugin, you would remove both the cvs.hpi file and the cvs directory.
After that, restart Hudson/Jenkins and the plugin won't be there anymore.
Jenkins 1.487 adds a UI for uninstalling plugins: JENKINS-3070
Deleting the <plugin>.hpi file and corresponding <plugin>-plugin directory will effectively remove the plugin.
However, if you have configured parameters that belong to the plugin within your jobs your Hudson or tomcat logs may contain *CannotResolveClassException: hudson.plugins ... * exceptions because it attempts to load the plugin. This can result in build failures even if build is successful.
To fix that,
go to the job configuration and save it again. This should get rid of the plugin reference
if not, go into the hudson home jobs directory and open the config.xml found under the folder named after the job and remove the reference to the plugin
restart hudson
Hudson Plugins explains that some core plugins ("Tier 1" plugins, as they are called) are shipped with Hudson itself, and I assume cannot be deleted therefore.
You can disable it using the Jenkins ยป Plugin Manager. Go to Installed tab and untick the plugins you want to uninstall and restart Jenkins. Though it does not unintall, at least keeps it away from appearing from configuration pages..
I was wondering which steps are the best to upgrade hudson and the plugins.
I'm running 1.347 at the moment. I once tried to update which resulted into a mess because some plugins were incompatible.
Also i want to delete some plugins is it appropriate to just delete the hpi file? It would be nice to know how other people do this step and in which order.
Should i first upgrade hudson and then plugin by plugin?
And if a plugin breaks something downgrade it again? It seems to be a lot of work.
Or is there any easy way?
Also is it enough to save all the xml configuration files in case something breaks that i can recover?
Thanks in advance.
My solution is overkill, but I was burned twice (once by a Hudson bug and once by plugin incompatibilities) and learned my lesson.
I have Hudson installed on a VM with the same plugins as my production instance and a couple of simple builds. When I feel it's time to upgrade, or want to check out the latest release, I upgrade Hudson on the VM and verify that it starts up and can do builds. I only upgrade the production system that all of our developers use after I've upgraded my test system. I generally don't do exhaustive tests on my test system; it's enough to make sure the combination of upgraded Hudson and plugins starts up properly.
When upgrading either the VM or the main system, I upgrade all the plugins, then upgrade Hudson itself and restart. (Since I have a test system, I'm not particularly worried about doing things step by step.)
I came up with my process before Hudson introduced downgrade support. I still use this process because it's important to me to have confidence that an upgrade is not going to break the system that other developers use. This setup also allows me to have an experimental setup that's separate from the main Hudson system, which I find useful.
I usually update Hudson first, then the plugins.
The recent versions of Hudson have some support for this process:
the Hudson 1.376 added downgrade support for the core and plugins.
That means after upgrading a plugin, you have a button which allows you to downgrade to the previous installed version if needed.
the Hudson 1.369 Avoid error with invalid or null primary view, such as in upgrade from older Hudson
And the upcoming Hudson 1.387 will avoid littering HUDSON_HOME with atomic *.xml files, which should make the backup process of critical config files that much easier.
(Currently, with an Hudson 1.386, I see under HUDSON_HOME:
com.mtvi.plateng.hudson.ldap.LdapMailAddressResolver.xml
config.xml hudson.scm.SubversionSCM.xml
de.fspengler.hudson.pview.PViewProjectProperty.xml hudson.tasks.Ant.xml
hudson.maven.MavenModuleSet.xml hudson.tasks.Mailer.xml
hudson.model.UpdateCenter.xml hudson.tasks.Maven.xml
hudson.plugins.clearcase.ClearCaseInstallation.xml hudson.tasks.Shell.xml
hudson.plugins.clearcase.ClearCaseSCM.xml hudson.triggers.SCMTrigger.xml
hudson.plugins.git.GitTool.xml nodeMonitors.xml
hudson.plugins.sonar.SonarPublisher.xml proxy.xml
hudson.scm.CVSSCM.xml
)