I'm guessing that it needs to be done differently since it is dependent on the package, and the directions after I install it (doesn't tell me how to) are to add it as a service provider like so:
'Rocketeer\Plugins\RocketeerDatabaseServiceProvider',
And there's a 'Plugins' directory within the Rocketeer package.
Has anyone installed a plugin for a package before? I would greatly appreciate the tip
In theory you should get the plugin via Composer, add the provider to app.php (or local/app.php depending on whether you're requiring Rocketeer as a dev dependency or not) and that should be good. That being said, what Rocketeer version do you use? Because that particular plugin may just not be compatible with Rocketeer 2
Related
I have scoured the web for hours but I can not seem to wrap my head around this. I am developing a Laravel project where I am using the dependency UniSharp/laravel-settings. However, I have noticed that after upgrading my Laravel version to 6.0, the package breaks. I have figured out what I need to do to make the package work with Laravel 6.0 and now I wish to make the required changes and then use the modified package.
So far, I have cloned the original repository into my own (i.e realnsleo/laravel-settings) and I have cloned it onto my development machine. The trouble is, I don't know how to test whether my changes work. Do I need to setup a fresh Laravel installation to test the package? I noticed the package has it's own composer.json file, should I install those dependencies separate from the installed Laravel project? I am highly confused.
Can someone assist me with a step by step on what I need to do to achieve this? I will highly appreciate it. Thank you.
I'm installing Drupal 8.x via composer downloading any dependencies from the Internet and all works fine.
In this way however there is no guarantee that the same versions of dependencies will be available every time I install. One server might have an updated version of a module than another Drupal server if I install in different time. I would like to prevent against this by using a local mirror.
Is it possible to provide a local mirror to composer and how?
Any example / reference / suggestions?
If you are worried about the versions, then the best way would be to define the exact versions you want in your composer.json if need. But apart from that, after you install your dependencies, you have a composer.lock file that has the exact versions in it. This file is committed to your version control and used as the base to install: this way you always get the same versions (until you update of course).
A separate problem might be that there is no internet, or the specific versions are not available for some reason. This shouldn't happen (often), but in that case you should pick this up before you 'release'.
The best practice would be to build (finding out if you have all packages available) and then release. You could even create a separate build server that creates your project including the vendor dir, and push from there. The fact that your vendor dir is not in your version control does not mean you have to get all dependencies on your production server each time
This means you have a local copy of your vendor, which is not a local mirror of composer per se, but close enough for comfort.
I've got a hello world opendaylight app (created following the tutorials) which compiles using a mvn clean install, and appears when I run the karaf package that is also generated.
However I am unable to get it to run in another ODL install (downloaded the binary with all the other packages from the website), and even using a
bundle:install mvn:org.andrew.test
results in unable to install bundle (tried copying to deploy and system/org/andrew....)
How do you get a bundle which can be used in another install?
Why do you want to bundle:install instead of feature:install ?
What most existing ODL projects do for you, and what the example generated by the archetype should also show you how to do for your custom org.andrew.test one (have you used the archetype? try it..) is that there is a local karaf/ artifact which correctly depends on the features/odl-something feature of your example, and lets you install it, which will install your bundle/s.
In theory and if you really know what you are doing, you can also get it to work for what you call "in another install" in your question, but you have to use repo-app and what not - most people do not use it like that AFAIK (at least in ODL development); so I wouldn't bother, if I were you.
If you want to learn more about this in general outside of OpenDaylight, the general Karaf documentation manual is not bad. Beware that in ODL we've tweaked a few things though; for example, we have (intentionally) disabled the direct installation from ~/.m2/repository (for better isolation).
Is there any utility or service that allows to know what packages have released new versions given a custom composer.json file?
It would be very useful in order to plan packages upgrades.
You can run composer show --outdated to get the list of outdated packages.
Outdated are all packages, which have a newer version available or are abandoned/replaced by another package.
In case you want a full overview including outdated and up-to-date ones, then you can use composer show --latest.
For more: composer show --help.
Referencing: https://getcomposer.org/doc/03-cli.md#show
Some repositories use external services like VersionEye to track, whether their dependencies are up to date. The status is often indicated by a "dependency up-to-date" badge, which is added to the readme of the project. You can find that for instance in the Readme of the Yii2 Framework.
Ive been reading a few articles on the net about package development but cant quite wrap my head around the basic setup. Ive written jQuery plugins with releases and published to Bower in the passed so maybe im just not understanding the difference with Laravel.
With jQuery plugin dev I would just exclude my dev required dependancies through bower.json to prevent a person pulling in my dependancies. It seems that with Laravel u create an un-tracked Laravel framework folder and put your package into the vendor folder and track only that with Git? So basically the Laravel project sitting outside of my vendor package is just some files on my PC? Surely I would want to track which version of Laravel the package was developed on?
OR should I create a "base" Laravel repository and create another repository inside the vendor folder so make sure I know which Laravel the package was built on?
Documentation and tutorials are very vague...
Your question looks a little bit confuse. I develop packages for Laravel and the following is a regular way:
Laravel manage its dependencias via composer, take a look into composer.json to get a clue how similiar is with bower.
In order to get yout package compatible with laravel's core you need to implement some interfaces in your package. This package also can manage dependencies via composer.
A package can be created as a repository in different version controls, like Github, BitBucket, Packagist, Cartalyst, private packages repositories, etc. By default laravel pull packages from Packagist, but into composer.json file you can specify another reposository as needed.
When you trigger composer update (this is an equivalent as bower update), this dependencies manager will pull all the packages and download them automatically in vendor/ directory.
How to code your package while testing with laravel? some people do the following, including me:
Install a laravel instance just for package development purpose.
Create a new project (your package project) inside of vendor/project-name following lavavel's package requirements.
Keep working your package from this project location. By this way the changes are reflecting instantly in laravel installation.
Don't forget to commit and push