Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-15411] CLI: 3.2.0 version doesn't take the arguments in account if the sdk in config is different from the one in tiapp.xml

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionFixed
Resolution Date2013-12-03T07:21:20.000+0000
Affected Version/sn/a
Fix Version/s2013 Sprint 21, 2013 Sprint 21 Core, Release 3.3.0
ComponentsCLI
Labelscli, module_cli, qe-testadded
ReporterDan Tamas
AssigneeChris Barber
Created2013-09-30T14:52:54.000+0000
Updated2014-07-31T18:27:37.000+0000

Description

Comments

  1. Chris Barber 2013-10-07

    I'm aware of the issue and have fixed it, but the PR is pending. You may want to wait on using the master 3.2 branch until it becomes more stable.
  2. Allen Yeung 2013-10-19

    PR: https://github.com/appcelerator/titanium_mobile/pull/4781
  3. Olga Romero 2013-11-11

  4. Neville Dastur 2013-11-12

    I am not sure why this is closed. Although the app launched on device the SDK used is not correct, IMO ~~~ tiapp.xml set to 3.1.3.GA, but current Titanium SDK set to 3.2.0.v20131110134044 [INFO] Forking correct SDK command: "/usr/local/bin/node" "/usr/local/bin/ti" "build" "--sdk" "3.1.3.GA" ~~~ surely the CLI argument i.e. --sdk "3.2.0 v20131110134044" should override the tiapp.xml value.
  5. Olga Romero 2013-11-12

    [~ndastur] did not mean to close it. keep watching :) 
        ti config
   
       app.sdk                    = "3.1.3.GA
   sdk.selected               = "3.2.0.v20131111174605"
   
       Installed SDKs:
      3.2.0.v20131111174605 [selected]  /Users/oromero/Library/Application Support/Titanium/mobilesdk/osx/3.2.0.v20131111174605
   
       ti build -p android --target device
   
       [INFO]  Packaging application: /Users/oromero/Documents/Android/android-sdk-macosx/build-tools/19.0.0/aapt "package" "-f" "-m" "-J" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/gen" "-M" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/AndroidManifest.xml" "-A" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/bin/assets" "-S" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/res" "-I" "/Users/oromero/Documents/Android/android-sdk-macosx/platforms/android-19/android.jar" "-I" "/Users/oromero/Library/Application Support/Titanium/mobilesdk/osx/3.2.0.v20131111174605/android/titanium.jar" "-F" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/bin/app.ap_"
   
       [INFO]  Signing apk: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/jarsigner "-sigalg" "MD5withRSA" "-digestalg" "SHA1" "-keystore" "/Users/oromero/Library/Application Support/Titanium/mobilesdk/osx/3.2.0.v20131111174605/android/dev_keystore" "-storepass" "*******" "-signedjar" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/bin/wils.apk" "/Users/oromero/Documents/Titanium_Studio_Workspace2/wils/build/android/bin/app-unsigned.apk" "tidev"
  6. Olga Romero 2013-11-27

    [~cbarber] let me know if any changes made. Thanks. CLI 3.2.0-alpha3 Same result as an original report.
  7. Chris Barber 2013-12-03

    Changing this back to fixed. --sdk does NOT override the tiapp.xml's . The --sdk specifies the Titanium SDK being used to bootstrap the build, not the actual build. The in the tiapp.xml ALWAYS wins. Maybe someday we'll add a --sdk-version command line option, but until then, this is working as designed.
  8. Neville Dastur 2013-12-03

    Chris, thanks for the clarification. But I think this might be "bad" design in that case. Maybe I don't understand the build process well enough. But what is the point of bootstrapping to a different SDK version. Also without the CLI override for the build SDK the user has to do a sed (or equivalent) on tiapp.xml in order to use different SDKs. Surely this makes testing with RCs etc all the more difficult and in the long run means Appcelerator lose out on valuable feedback because they have made the process difficult?
  9. Chris Barber 2013-12-03

    [~ndastur] It's not bad design. With Titanium 3, we introduced a central "titanium" entry point that didn't exist before. Pre-3.0, you would directly invoke the builder.py. Now that we have the Titanium CLI as the global entry point, it cannot be responsible for knowing how to build an app. So you must select a Titanium SDK that knows how to build an app as well as determine if it's the right version to be used to build the app. For example, if 3.2.0 is your selected SDK, then when you build a 3.1.3.GA app, the 3.2.0 build script will read the tiapp.xml and determine it doesn't know how to build it, so it subprocesses a 3.1.3 build. The second we expose a command line override of we will introduce potential issues. If you have a team working on an app written in 3.1.3, but one of the devs keeps building the app with 3.0.0, it's entirely possible they could encounter old bugs causing longer development times and less stable apps. The way things are right now, it's easy for a team to be on the same page and tie your product to a Titanium SDK version that it was designed to run on.
  10. Deepti Pandey 2014-05-06

    Verified as FIXED using : Mac :10.9.2 Appcelerator Studio, build: 3.3.0.201405011408 SDK - 3.3.0.v20140505115416 acs-1.0.14 alloy-1.4.0-dev npm-1.3.2 titanium-3.3.0-dev titanium-code-processor-1.1.1 Xcode :5.1.1 --sdk does NOT override the tiapp.xml's Hence closing this ticket as FIXED.

JSON Source