What do I use as the autoload file for my PHP Unit configuration file for my contributed bundle?
I'm writing unit tests for my first contributed Symfony 2 bundle. I'm not sure how to handle the XML configuration file phpunit.xml.dist for PHP Unit. I know I should write my own config file(instead of relying on the one provided by Symfony Framework), but I've seen a few different ways people handle the bootstrap file that the config uses.
Symfony framework apps have a PHP Unit config file in the app/ folder and it uses bootstrap.php.cache as the autoloader, which really just defers to the composer autoloader in the vendor directory.
Several bundles I've looked at have their own bootstrap file but try and locate some other autoload file on the filesystem, making assumptions about where it may be. That doesn't seem right to me, but perhaps it is?
The best practices don't get into specifics here.
Best practices for unit testing is to test a small unit of functionality at a time, this unit should not rely on external influences and doesn't make sense to use bootstrap.php.cache as that is intended to bootstrap the entire symfony framework.
Your tests within a bundle should be able to execute on their own if someone were to checkout your bundle and contribute to it, they should be able to run tests there with only your code and dependencies. An ideal scenario would be that no bootstrap is necessary to set up the test suite, all you need is the autoloader. This is why many bundles have a bootstrap script that loads the autoloader.
There are two scenarios on the autoloader location relative to the bundle, either your bundle is installed standalone and it will be in vendor/autoload.php or your bundle is installed as a dependency, which in a standard configuration would you would fall back to a project autoloader if that exists.
This is variable depending on your setup and usage of target dir... You would need to traverse upward at least two levels to account for vendor name and package name, then if you have a target directory configuration you would need to traverse upwards the number of directories in your target path.
Related
In a Karaf features file if I include certain bundles then Karaf stops working correctly.
How can I know what bundles I should not include in a features file? for example, if I added these bundles in the features file in Karaf on Windows, Karaf is not happy and acts strange. I assume its because Karaf already provides Java interfaces for these bundles.
<bundle>mvn:org.osgi/org.osgi.core/4.3.1</bundle>
<bundle>mvn:org.osgi/org.osgi.compendium/5.0.0</bundle>
Also is there a programmatic way to determine this?
Is there a list of bundles which I should not include?
I understand that Karaf uses pax-logging rather than those slf4j.
In more detail, my SBT project compiles a list of dependent bundles for my bundle, in my list that I get back from my code I get the org.osgi.core and org.osgi.compendium. They are dependents of my osgi bundle which is my main project. Now, the problem is, how can I know that Karaf does not want this installed as part of my features?
Thou' shall not install other framework packages besides the framework ;)
This is an absolut NOGO!
As Karaf already provides everything you need, in that case the Framework.
So don't even think about adding the std. framework packages to your OSGi env, they are already all there.
If you want to have certain compendium packages.
Make sure you Install the implementing bundle, as you already pointed out, the pax-logging bundles already provide everything needed for the osgi logging compendium services.
Same is true for Pax-Web and the OSGi HttpService packages.
You'll find a lot of already pre-registered OSGi compendium services with Karaf,
if you need more, install the implementation, not the spec bundle.
edit
nop programmatic or Karaf internal way can tell you about to not include those bundles. It's just something commonly known.
An implementing bundle always also will bring you the needed osgi packages.
I was planning to use Sass with my Spring-MVC application. From Sass-lang website I got this Maven LibSass Plugin. I have put it in my pom.xml
But I am really confused with what next?
The major doubts I have are:
Which directory I should keep my Sass files in?
How do I include them in my HTML files?
What should be the target dir?
As of now, if I keep directories as suggested by my plug-in, it crashes either eclipse or stalls maven clean and install goal execution. I very new to this concept. Do let me know if you need any other info.
Actually these are all up to you.
You can choose an arbitrary directory. Most probably you would not want to serve Sass files. Thus this directory should not be deployed. libsass examples use src/main/sass directory.
You should include the .css files created at the target directory manually. libsass does not handle this part. There is no automatic inclusion of the compiled .css files as in Ruby on Rails platform.
Target directory is arbitrary again. Remember the choice of directory depends on how you will refer to these files at views. For example if you will be manually referring them, most probably you'll want to specify a target directory that is actually deployed to application server, such as src/main/resources/css.
I'm a bit new to Symfony and I'm don't know what to use for my static file management. I have read about Assets component and the Assetics bundle.
I know that Assets just includes the files and Assetics is a bit smarter as it can combine files and compress images. But I already use compass to minify and combine the css files so therefore Assetics is not really required.
Version control so the url of the static files change to by pass browser cache, is done by both.
Assetics is removed from 2.8 or higher, does this mean it is not best practice anymore?
I need to generate urls on three places:
Twig -> Easy to do with both
Controller -> Found only a way to do this with Assets
In css files -> Believe it is with both not possible
Wat would be the best to use in my case, any advise?
Assetic can be seen as a way to easily apply filters and compile your assets. The asset component basically is used to manage URL generation. As you said, both nicely are integrated in Twig via extensions, and controllers via the services.
Our application uses compass too, but Assetic makes sure that the compiling happens at the right moment without the need of compass watch at the commandline.
Think most of your questions are answered on:
http://symfony.com/doc/current/cookbook/assetic/asset_management.html
and
http://symfony.com/doc/current/components/asset/introduction.html
I've been using the RjFrontendBundle to run the front-end CSS/JS build, and also copy other static content into place from Bower/NPM/local sources. It provides a VersionStrategyInterface for the Assets component that creates, and uses unique filenames in production (renaming the files with an embedded hash, via the GulpJS rev-all package). In dev, it uses the normal filename.
Within CSS files, you can still reference CSS/JS, via a url() function, and the pipeline will rename them appropriately in dev and live.
The GulpJS build tool is used to minify and otherwise prepare the plain files. It comes with a setup console command to build the initial gulpfile.js and can also watch and rebuild files, updating the browser as they are changed, which helps with front-end development workflow.
The trend is to use standalone front end tools such as gulp/grunt/sass instead of assetic. The reasons are (probably) as follows:
gulp / grunt are independent from the framework, providing the same workflow for the front end guy no matter what underlying framework is used for the backend.
assetic has a different workflow than most of the modern tools. It assumes that you will write your script/css includes in the templates. Migrating from assetic to gulp could be a pain for large project.
as your project grows, assetic can become kind of slowish... As that happens, you will stop pulling your assets from the controller and start generating them the way gulp or grunt does. In this scenario, gulp and grunt are just better tools.
assetic lacks some important features, such as including processed assets into HTML code (inline). Because of the way assetic works (twig tags), it might be difficult to overcome this.
As for generating the URLs: assets are just files in the filesystem. Write a function or twig extension to generate URLs to those files.
I have a web application made with Symfony2 and I want to add my license choice in the repository. The thing is that the default Symfony2 project has a LICENSE file in the root directory and I don't know where I am supposed to put my LICENSE file and if I should delete the Symfony2's one. Also happens with README file.
I guess that you Symfony2 programmers sure know how to handle this.
Your own application code should be located mostly in the src folder. If you take a look at some Bundles or other components of Symfony2 you can see that they all have a separate LICENSE file in their bundle root directory. So the correct choice for your file would be:
src/.../.../LICENSE
In this case your LICENSE file would also be included if you install your bundle via composer on a different project. In that case it would be at:
vendor/.../.../LICENSE
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.