At what should I need to be careful when I migrate a project made in with Symfony 1.2.1 to Symfony 1.4.11 ?
You should follow the instructions here: http://www.symfony-project.org/tutorial/1_4/en/upgrade
There is a validator which you can run on your code that will tell you which files have code that needs to be changed. Also, remember since you want to go from 1.2.1 -> 1.4.11, you will first need to upgrade to 1.3. So you would run:
$ php symfony project:upgrade1.3
and then switch to 1.4.
Related
I want to use scratch files as a console replacement for prototyping in my Rails apps. The simplest solution I've found is requiring environment manually like this:
require '/project/path/config/environment.rb'
But it does not use Spring and is terribly slow because of that.
I've found two ways to do it, depending on your workflow one might fit you better than another. Assuming you're using IDEA 14 (it might be different for earlier versions) and Rails 4.1+.
Custom runner
In top menu Run -> Edit Configurations...;
Configuration tab:
2.1. Ruby script: <Path to your bin/rails file>;
2.2. Script arguments: runner <Path to your script>;
2.3. Working directory: <Your project dir>;
2.4. Environment variables: RAILS_ENV=development;
2.5. Ruby arguments: -e '$stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift)';
2.6. Ruby SDK: <Your project SDK>.
Bundler tab:
3.1. Run the script in context of the bundle (bundle exec): <check>.
The problem with this approach is that you would have to manually change path to scratch file each time you want to run the different one (please comment if you know workaround).
External tool
Assuming you have Spring installed:
In top menu IntelliJ IDEA -> Preferences;
Tools -> External Tools;
Hit + in the bottom of the menu:
3.1. Name: Rails Runner;
3.2. Program: $ProjectFileDir$/bin/spring;
3.3. Parameters: rails runner $FilePath$;
3.4. Working directory: $ProjectFileDir$.
Keymap:
4.1. Search for Rails Runner;
4.2. Double-click and add custom shortcut (Alt + S is convenient and available).
The only problem with this approach is that you have to have custom shortcut to make it convenient.
I tried looking for the answer for this here but couldn't find it. If this is documented somewhere, please send the link as a comment and I'll delete the question.
I can't figure out the proper order for using Grails Wrapper when upgrading an app version:
Do I run grails wrapper and then change application.properties to the new version of Grails, and then execute all future commands using grailsw?; or
Do I change application.properties to the new version, then run grails wrapper, and then run all future commands with grailsw?
Running grails wrapper will download the version of the wrapper specified in application.properties, so you should run it after changing the version.
I want to know the versions of the software used while developing the project, Suppose If there is an existing project In grails ,so I want to know the version of grails as well as version of Groovy for that project
Metadata regarding a project in Grails is kept in application.properties.
Within this file you will find the version of Grails used for the project under the key app.grails.version.
The version of Groovy used however is not kept in this file and is determined by the version of Grails being used. To determine the version of Groovy used by a specific version of Grails visit the introduction section of the Grails documentation.
edit
As pointed out in another answer, if you have target version of Grails already downloaded you can search for the version of Groovy being used by that version of Grails.
*nix
$ cd grails-X.X.X
$ find . -name "groovy*jar"
win32
> cd grails-x.x.x
> dir /s "groovy*.jar"
From controllers/services:
def appVersion=Metadata.current.'app.grails.version'
def appName=Metadata.current.'app.name'
From gsp:
App Version <g:meta name="app.version"/>
Built with Grails <g:meta name="app.grails.version"/>
Added extra information to figure out a grails application version from raw text files :
If you have a grails 3 application, you should find a build.gradle in the main root of your application folder:
version "0.1" According to this grails 3 project the version of this application is 0.1
Grails version is 3.1.1 according to gradle.properties
On a grails 2 project you will find application.properties in the main project root:
According to this grails 2 project
grails version is 2.4.4
App version is 0.1
If you already have a project and want to learn which grails version it uses. You can find it in gradle.properties file.
The content of the file is like the following
grailsVersion=4.0.1
gorm.version=7.0.2.RELEASE
As of Grails 3, this is:
Version <g:meta name="info.app.version"/>
Notice the info.
http://docs.grails.org/3.0.17/ref/Tags/meta.html
use application.properties in the root of the grails application
To find out which version of groovy is used with particular version of grails I always use simple find:
$ cd grails-X.X.X
$ find . -name "groovy*jar"
Maybe I'm just too lazy to dig into websites... ;-)
You can see application name,grails version,application version from application.properties file of grails project
I face the same issue, I found simplest way to find version by simple command.
run
grails clean
then it prints
Welcome to Grails 1.3.7 - http://grails.org/
I want to update symfony 1.0.11 to symfony 1.0.22. I am using php 5.1.6. Do I need to do any upgrades in my symfony code level as well? Or just upgrading the symfony library will do the trick for me?
You may have to change some symfony function depend on deprecated function and removed functions.
To be safe, backup your symfony project, just in case.
Is there a better way of determining which version of Propel that Symfony 1.4 is built upon? Right now I am having to do:
$ -> ack -i version /path/to/symfony/lib/plugins/sfPropelPlugin/lib/vendor/
And as of now I am seeing this:
/path/to/symfony/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator/default.properties
19:propel.version = 1.4.2
So I am assuming that Symfony v1.4.16 is using Propel version 1.4.2.
At this time, propel bundled with Symfony 1.x does not support the ability to determine the version, cleanly, via cli, however you can use the ack or fgrep command as I stated in OP. But if you use the sfPropelORMPlugin plugin, which allows you to use propel 1.6 with Symfony 1.x, they have opted to add this functionality, which I assume will be available soon. https://github.com/propelorm/sfPropelORMPlugin/pull/152