This app was last modified by a newer version of Sencha Cmd - version mismatch - sencha-touch

I'm trying to add the sencha cmd production package into my build process. But the final step when I need to package the app fails with the above error.
What I don't understand is this is a newly built application fresh from the SVN repo. The sencha cmd is the latest as I've just upgraded. So my question is when it states that the app was last modified by a newer version of sencha cmd is it lying to me?
2 things which aren't correct:
The app can't have been modified by a newer version because I've
just upgraded the build machine version of sencha cmd to the newest
version.
The app has been created by Sencha cmd in the past, but
this would have been older than the current one on the build
machine.
So I'm left baffled how to resolve this. How does Sencha Cmd 'know' that the app was last modified by a different version anyway? Is there some file within my \app folder which can be fudged so that it thinks the version is the latest? And what has the Sencha Cmd got to do with my application code-base anyway?

You can run the new Cmd version in update mode. I think this is really intended to update the Sencha Touch version, but if you just point it at the current version (2.1) then it will just update itself.
So, for example, run the line below with the latest Cmd:
sencha app upgrade [directory where 2.1 is]
Make sure you take a copy of your app.js first though, as the new version mangles this - just put your old one back after update. Also be aware that it will update your "Touch" directory, so make sure this is backed up as well.
Once the update has been run and you've put the app.js file back, your project should now build with the latest cmd.

If you have created/build your app using Sencha Cmd you will have related information (workspace.cmd.version, app.cmd.version) in following files:
PROJECT_ROOT/touch/cmd/sencha.cfg // This is SDK requirements
PROJECT_ROOT/.sencha/workspace/sencha.cfg // This is workspace build config
PROJECT_ROOT/.sencha/app/sencha.cfg // This is app build config
You can try fudging Cmd version in these files and let us know if it works :)

After doing sencha app upgrade --noframework, make sure to also run "sencha app refresh" to update .sencha metadata.

This misleading error message refers to a version change of Sencha's Cmd tool on the machine you are using. You can upgrade the Cmd scaffolding with the following command:
sencha app upgrade --noframework
From: 'sencha help app upgrade'
Options
* --noframework, -no - Upgrade only the Sencha Cmd scaffolding and not the SDK
Definitely back up your app before upgrading. The upgrade command will warn you about conflicts that need to be resolved (such as custom changes to app.js). When you open those files the differences will be noted in a standard diff format:
<<<<<<< Generated
/*
This file is generated and updated by Sencha Cmd. You can edit this file as
needed for your application, but these edits will have to be merged by
Sencha Cmd when it performs code generation tasks such as generating new
models, controllers or views and when running "sencha app upgrade".
Ideally changes to this file would be limited and most work would be done
in other places (such as Controllers). If Sencha Cmd cannot merge your
changes and its generated code, it will produce a "merge conflict" that you
will need to resolve manually.
*/
...
>>>>>>> Custom
...
Resolve the conflicts (remove the >>>>>> X lines and make sure the right lines are included in your file) and you should be all set. The most likely file to have a conflict is app.js - it'd be a good idea to compare your backed up version of that file with your modified version to be confident of the changes.
This seems to mean that all developers working on the application need to run the same Cmd version, so keep that in mind as well.

Related

What exactly is react-native upgrade command doing? particularly to the gradle files?

I want to understand what the react-native upgrade command is doing, it sometimes changes the gradle files:
android/app/build.gradle
android/settings.gradle
Why does it asks if I want to Y/N to update does files? If I keep answering No is this gonna have bad impact on the application?
The upgrade command is intended to run after updating RN version in existing projects (and after running npm install so the new version is in your node_modules).
Essentially, the command copies all files from the app template which is used to initialize a new RN app. The template is what you get when you run the react-native init command. This is also the reason why it needs to run after the new RN version is installed, because the templates app comes with the react-native dependency itself.
The reason that it asks you if you want to replace each modified file is that it doesn't know why the content has changed. It's possible that you made changes to a file yourself after you initialized your RN app.
If you haven't made any changes - it is safe to replace the existing files; it would be as if you got the file after initializing a new RN app. If you did modify a file - I think that you'd still like to see what changes were made in the new version (they can sometimes be required), in this case you can approve the replace (assuming that you're using source control...) so you can review the changes and in the worst case you can reset them if they're not necessary.
Alternatively, you can use React Native Git Upgrade which can help you resolve conflicts more easily.

sencha generate app failing from INSIDE SDK FOLDER

I issued this command:
sencha generate app LaBucaDiSanMatteo c:\xampp\htdocs\LaBucaDiSanMatteo
from inside SDK folder (c:\touch-2.3.1).
I got:
[INF] Workspace does not have framework null at C:\xampp\htdocs\LaBucaDiSanMatteo ... copying
[ERR] Failed to determine framework name. Please ensure this command was issued from either a framework or application directory
I'm using Sencha Cmd v4.0.2.67
Solved by myself.
Sencha CMD works only with the GPL version. Not working with the free commercial version.
I downloaded the first by mistake. I discovered the problem comparing the 2.3 with the old 2.2.1 (luckily I kept a copy).

Worklight fails to install customization jar

I have three projects in my workspace, two deploy to the server correctly, the third has just begun to give this error:
Failed to install and start project customization from file <path>MyProj-customization.jar
I've seen this before on other projects and usually it's sufficient to start the server for another project and come back to the one with problems. When that doesn't work the next recipe (found on developer works) is
Exit Eclipse/Worklight Studio
Delete <workspace>/WorkLightServerHome
delete project bin
Start Studio, rebuild
That also doesn't work. Finally there's a further recipe on developer works
When Eclipse is not running, go to:
1. <path-to-your-Eclipse-folder>\configuration\org.eclipse.osgi
2. Delete the .bundle* files
3. Start Eclipse
4. Build and deploy
Again this does not clear the problem, assuming I've understood step 2 correctly, I found exactly one file whose name is of the form .bundle* and a bundles directory with several sub-directories. I deleted only the .bundlexxx file.
Any other suggestions?
I would have expected that creating a new workspace would fix it, but on this occasion no such luck.
No true solution on this occasion. Normally a new workspace as a method of last resot has always worked in the past. In this case I found no alternative to reinstallation of Worklight.
In addition to the attempts you have tried, also try creating a new workspace and import the 'offending' project to it.
If all fails, have a new instance of Eclipse (Java EE, 4.2.2 SR2), re-install Worklight Studio and import the project.

Worklight 5.0.6 wipes out native customizations in shell

I upgraded my environment to v5.0.6. Problem is that everytime i start Eclipse it does this:
[2013-04-19 18:38:41] FWLST1017I: [AppShell] upgraded to the latest
platform version.
When this upgrade takes place, it reverts my templates and adds class files to the iphone\native folder and removes the plugins I configured in the shell:
Removes all my custom plugins from components/AppShell/iphone/native/Classes
Resets project.pbxproj.wltemplate.wluser to stock removing includes for my classes
Resets config.xml.wluser removing all mappings to my plugins
It also always shows at the end of the upgrade process:
Failed to upgrade Worklight project 'AppMobile' to the latest platform
version. [null]
Is that why it keeps running the upgrade and reverting my changes?
According to your question, you have some .wluser files, which means that something is wrong with your project.
Can you please let me know whether the problem still exists and whether you still have those files in you project?

Building a Sencha Touch 2.1 project

I've built myself a small Sencha Touch 2 app, so now i'm trying to make it smaller/minify it
My app looks like
/touch
/app.js
/resources
/ux
/app
/app.json
/index.html
/build.xml
So I was trying to make it more efficient & faster to load so I loaded up Sencha Cmd and ran
sencha compile --classpath=app,touch/src,ux include -all
So it does what looks like compiling it, without giving any errors, it gives a few warnings but those are ok. So it finishes up and nothings changed. The directories are exactly as there were before.
How would I use this correctly to make my app smaller & load faster?
The command
sencha app build package
or
sencha app build production
Will minify/package your application. All of the javascript will be contained in a single app.js file, and the javascript+css will be minified. More information about these commands can be found here: http://docs.sencha.com/touch/2-1/#!/guide/command_app
See Also cmd tool doc for detailed info:
http://docs.sencha.com/cmd/3.1.2/#!/guide/command_app_touch-section-deploying-your-application
Deploying your application simply means editing source code and refreshing the browser. All source files are dynamically loaded on demand. There's no building process involved. When it comes to deployment, Sencha Cmd provides the following four build environment options:
testing - intended for QA prior to production. All JavaScript and CSS source files are bundled, but not minified, which makes it easier to debug.
package - creates a self-contained, redistributable production build that normally runs from the local file system without a web server.
production - creates a production build that is normally hosted on a web server and serves multiple clients (devices). The build is offline-capable using HTML 5 application cache, and is enabled to perform over-the-air updates.
native - first generates a package build, then packages it as a native application, ready to be deployed to native platforms.