I use the 2.0.x version in my project, but recently I've started to see more and more bundles that support only the master branch
Should I migrate to the master branch?
It's not stable and may contain unfinished code. Also, there are a lot of break changes that haven't been documented yet. If you're starting a new project, then go for master, if you have already written some code, I'd better wait for the next 2.1 release (all bundles should support it).
Most popular bundles work with 2.0 too, but you must often use the branch for your symfony version, not a bundle's master branch.
Related
I would like to know where can i find or whats the official process to consider when you have to update both the modules and the core in a Drupal 7 site at same time.
I mean, what do i have to update first?
Modules then Core, Core then modules or it doesn't matter at all or it depends of each module documentation?
Also i would like to know if this process changed in Drupal 8.
I have found the process to update each one but not together.
I always do modules then core, but if you have a good reference or any article with a justification for this will be better to understand why.
Thanks in advance
Firstly I would suggest you to use drush commands to upgrade core version. It will take care of the rest. But if you want to do manually then you can continue reading below answer.
In my opinion you have to update the core first ( if there is latest core and the core required modules available ) and then you can update other modules i.e contrib modules. At the end custom modules based on compatibility.
After placing the latest code you can use drush updb or {your domain}/update.php to update your database.
Or else you can do it in the following way:
Download latest drupal code, place your custom code inside it and use the old database and then run update. This is not the correct way but sometimes it works.
Note: Before doing any of the steps above always work in local environment and keep a backup. Never try it on production.
Thanks
When I create an app using composer, or install another app created using composer, there is a vendor/symfony folder included.
For example, I installed Laravel using composer. The folder vendor/symfony is present. I am not specifically referencing this in my Laravel app at all.
What is this folder, and it needed? Does the app use it, or composer use it? So if I am using an app created using Composer and dont use composer myself, can it safely be deleted and the app still run? Or could the app be using it?
Thanks
Answer is quite simple: Laravel uses Symfony components.
Check this article: http://www.sitepoint.com/build-php-framework-symfony-components/
Improved Routing Engine
Laravel 4.1 features a totally re-written routing layer. The API is
the same; however, registering routes is a full 100% faster compared
to 4.0. The entire engine has been greatly simplified, and the
dependency on Symfony Routing has been minimized to the compiling of
route expressions.
http://laravel.com/docs/master/releases
The "vendor" folder is a standard in every application / framework that uses composer to manage dependencies. In the "vendor" folder you will find all dependencies (read: libraries) that your applicatication requires.
But you will also find all libraries that your libraries require. In order to minimize code duplication, and thanks to the composer system, most open source projects now reuse parts from other open source projects.
BTW, this is great.
Symfony components are excellent and well documented, so they are currently used by many other frameworks and applications.
Inside the "vendor" you may find other libraries that you did not specifically require yourself, but as long as your correctly use composer, that's not something you should worry about.
We have a web application and occasionally a bug will creep up that needs to be taken care of and fixed. We are using subversion as our code repository. What I am wrestling with is at what point do you create a new branch or tag. We were thinking that if the application needed to be rebuilt or the MSI needed to be rebuilt then we would create a branch. In the case of something simple like a typo, we would just distribute out the offending .aspx page.
What are some of your strategies for branching and building strategies?
Currently, ours looks like this. We have a class library, and Web application. We make our corrections, copy over the changed pages/DLLs to the MSI Creator (Advanced Installer) then rebuild our MSI. We are debating on whether or not to use a web deployment project/MSbuild or something similar. We need it to be reproducible, reliable and simple.
When you release your code, you would "tag" it. Let's say you tag it with "ReleaseVersion_1.2.3.4"
The "trunk" would be your main branch. And you continue to develop there.
If a bug comes along for a customer who has the released code, you would branch from the "tag" ( "ReleaseVersion_1.2.3.4" ), and would hotfix something there.
Then you would most likely merge code from this HotFix back to "trunk".
That's the simplest way.
There are many options for branch strategies.
But if your code hotfixes are occasional, this one will work.
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
I have just mavenized the Apache Flex 4.9 SDK. Now, how can I build my application with maven?
Does anybody have an example pom-File for this?
Is there a flex-mojos version out yet, which is working with this flex version? Or are there any alternatives?
Btw.: My application is running, when I build it with Flash Builder 4.7.
I'm the guy currently in charge of continuing the development of Flexmojos.
I have to say, that RIAstars comment is not correct. I created the Mavenizer for usage with an updated version of Flexmojos and it is reported to work quite nicely together with it. Unfortunately I haven't released FM6 yet as I wanted to have it stable first. Because of this you have to fetch my github fork from https://github.com/chrisdutz/flexmojos ... I was planning on merging my changes back to the public repo as soon as Atlassian finally sets up our GIT repo at https://flexmojos.atlassian.net
I am currently working on making FM6 a parity release to the FM5 but with the difference that it works with the fdks generated by the mavenizer. What is true, is that I will not add any new features to FM, such as native Air bundling for mobile devices and support for falcon.
This is because we have already started the development of a purely Apache maven plugin that should replace FM one day. The main reason is the enormous effort you have to invest in maintaining a plugin that builds all FDKs starting with Flex 2.x and eliminating some design problems that were causing a lot of support traffic on the mailinglist.
So I would say: Yes you can use the Mavenizer to mavenize your FDKs and then you use FM6 to build your apps with it because that's what I created them for :-)
FlexMojos as it is will no longer be developed for future versions of Flex. As such I don't think you'll be able to use it with your mavenized version of Flex (but I might be wrong; I'm not exactly certain how it all works).
However the current maintainer of FlexMojos (Christofer Dutz) is working on a brand new Flex/Maven plugin. So for future versions you should be able to use that. Unfortunately to my knowledge this projects is far from finished.
As an alternative there is GradleFx which is a plugin for Gradle. You can set up an Apache Flex SDK dependency simply like this:
dependencies {
flexSDK group: 'org.apache', name: 'apache-flex-sdk', version: '4.9.0', ext: 'zip'
}
repositories {
add(new org.apache.ivy.plugins.resolver.URLResolver()) {
name = 'Apache'
addArtifactPattern 'http://apache.cu.be/flex/4.9.0/binaries/[module]-[revision]-bin.[ext]'
}
}
Personally I find Gradle much easier to work with than Maven. (Disclaimer: I am a contributor to the GradleFx project, but I only became one because I loved it so much).