10-30-2013 03:08 AM
That line is why you get that error code 821, yes, but the cause is upstream somewhere.
The blackberry-airpackager command creates your bar file; there's a call to it in the Run.bat file of the template.
You could modify the Run.bat to echo out the exact commandline that's being executed and see if anything looks wrong there.
10-30-2013 03:22 AM - edited 10-30-2013 10:16 AM
Also, try adding the -version option to the blackberry-airpackager calls in Run.bat.
Note that the FlashDevelop template instructs you to add your SDK path to your Windows PATH and the blackberry-airpackager calls in Run.bat just call whatever your Windows PATH resolves to. Unless you edited your PATH variable you may not be calling the version of blackberry-airpackager that you think you are.
PlayBook 2.1 SDK blackberry-airpackager is version 1.4.2 and BB10 10.2 blackberry-airpackager is version 1.9.
Now I don't know that it makes any sense for the version of blackberry-airpackager that you run to override what is in your bar-descriptor.xml but it would be good to know which blackberry-airpackager is being run, again for the sake of narrowing things down.
BTW the above PATH caveats are why I explicitly set a BBSDKPATH environment variable in my commandline build flow, instead of relying on what is in my Windows PATH, to insure I always know which SDK version was used to build any bar file.
10-30-2013 03:28 AM
Oh and also you might want to temporarily add the -listManifest option to the blackberry-airpackager calls in Run.bat, as a temporary diagnostic, so you don't have to unzip your bar and inspect the manifest manually each time.
10-30-2013 03:40 AM - edited 10-30-2013 03:44 AM
Thank you so much! You spotted it! It was the windows environment variable, it was still pointing to the SDK 3.2.1.
Do you know of any tutorial that explains how to set your own custom build flow? I think it will help me a lot to nail these kind of issues if I'd known what is happening when I click the "Build" button.
10-30-2013 04:11 AM - edited 10-30-2013 04:12 AM
I don't know of any tutorial offhand.
My build flow could use some more factoring and tweaking, or I'd just post it up on github, but basically it comes down to shell programming concepts - being comfortable with the commandline, environment variables, how the command shell works, etc. From there it's a matter of writing well factored batch file code and making sure you know exactly what version of what is being run, where it is getting its inputs, writing DRY code, keeping a Single Source of Truth, etc. - something that should come out of you writing & refining your own flow.
As a simple obvious example of factoring your batch file code, I set a BBSDKPATH environment variable in one and only one place in my flow, and every single call to the SDK tools in all the other batch files has that environment variable prepended to it.
So, I have a "SetBBSDKPathEnvVar.bat" file, with one line:
(side note - I have a CommandLine directory because I have SDK integrations for trial versions of Adobe tools and FDB in other directories; the CommandLine directory has an SDK install with no IDE integrations)
and then in my "BuildDebugBar.bat" file, I have commands like:
call %BBSDKBINPATH%\blackberry-airpackager -target bar-debug -debugHost %DEVICEDEBUGHOSTIP% -devMode -connect 127.0.0.1 -debugToken %DEBUGTOKENPATH% -package %PROJROOTRELPATH%\bin\%APPBAR% -C %PROJROOTRELPATH%\src %PROJROOTRELPATH%\src\%APPXML% %PROJROOTRELPATH%\src\bar-descriptor.xml -C %PROJROOTRELPATH%\bin %PROJROOTRELPATH%\bin\%APPSWF% -ane %BBSDKPATH%\frameworks\libs\qnx\ane\QNXSkins.ane -ane %BBSDKPATH%\frameworks\libs\qnx\ane\QNXDevice.ane -C %PROJROOTRELPATH% %PROJROOTRELPATH%\assets
where the other env vars are getting set elsewhere in other batch files. Nothing more elaborate than what the Run.bat file in the FlashDevelop template is doing. I just wrote my own so I know it top to bottom, but there's nothing wrong w/using someone else's template and just studying it thoroughly, thinking about what could go wrong with it, and tweaking it yourself.
I think I mentioned it before in this or another thread or two but it's good to know exactly what you used to build something that is out in the wild and that customers expect you to support. You can and should have a local archive of the bar files that folks are downloading from BlackBerry World, but what happens if they report a bug with version x.y.z? Sure you have that bar locally on your computer but can you tweak your code to test a bug fix, and then faithfully rebuild it with the exact build flow that built what your customers are using, in order to make sure you are changing the minimum number of variables when you test your bug fix?
Not trying to be preachy, but totally worth it, in my opinion.
10-30-2013 04:24 AM
I think it will help me a lot to nail these kind of issues if I'd known what is happening when I click the "Build" button.
In general, the only way to know exactly what is happening when we press the shiny happy Build button in an IDE is to know where the IDE has buried all the bodies.
10-30-2013 04:45 AM
Honestly, I have never used much the command-line, it kinda scares me but you have motivated me to give it a go.
I guess I will attempt to tweak the template between projects in order to have more control over it and understand how it works.
That code you posted and the best practices you mentioned will surely help too