Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-14449] Include platform-specific dependency information underneath Mobile SDK platform subfolder

GitHub Issuen/a
TypeStory
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2016-08-30T17:27:51.000+0000
Affected Version/sn/a
Fix Version/sRelease 3.0.0
ComponentsTooling
Labelsn/a
ReporterChristopher Williams
AssigneeChris Barber
Created2013-07-01T14:02:39.000+0000
Updated2017-03-27T17:39:55.000+0000

Description

Titanium/Appcelerator Studio has a file named sdk_info.json that we grab from a server and use to determine extra dependencies for specific platforms. An example is that we have entries that point the range of Tizen SDKs we support, XCode versions, Android addons/api levels, etc. This information is not something Studio should be maintaining, and it does not take into context the current project's Mobile SDK - so we apply the dependencies globally, regardless of whether the user is using 1.7.5 or 3.2.0 - which can mean the dependencies are not correct (older versions of the SDK supported older ranges of XCode and Tizen, e.g.). This knowledge and maintenance of dependencies should be pushed to the individual platforms, ideally in some relatively standard dependency.json file that is effectively just the segment of the sdk_info.json for that platform. Here's the current sdk_info.json file. This is a good starting point, but there are deficencies I will point out after:
{
  "android":{
    "linux":{"requiredAddOns":["addon.+google.+apis.+10"],"requiredSDKTools":"14","requiredPlatformTools":"10","requiredPlatforms":["Android\\s*2\\.3.*"],"sdkURL":"http://dl.google.com/android/android-sdk_r21.1-linux.tgz"},
    "macosx":{"requiredAddOns":["addon.+google.+apis.+10"],"requiredSDKTools":"14","requiredPlatformTools":"10","requiredPlatforms":["Android\\s*2\\.3.*"],"sdkURL":"http://dl.google.com/android/android-sdk_r21.1-macosx.zip"},
    "win32":{"requiredAddOns":["addon.+google.+apis.+10"],"requiredSDKTools":"14","requiredPlatformTools":"10","requiredPlatforms":["Android\\s*2\\.3.*"],"sdkURL":"http://dl.google.com/android/android-sdk_r21.1-windows.zip", "jdkURL":"http://titanium-studio.s3.amazonaws.com/jdk/jdk-6u25-windows-i586.exe"}
  },
  "ios":{
   "macosx":{"requiredPlatforms":["[5.0, 6.2)"],"sdkURL":"http://itunes.apple.com/us/app/xcode/id497799835?ls=1&mt=12"}
  },
  "blackberry":{
  "linux":{"requiredPlatforms":["10.0"],"sdkURL":"http://developer.blackberry.com/native/downloads","simulatorURL":"http://developer.blackberry.com/native/downloads"},
    "macosx":{"requiredPlatforms":["10.0"],"sdkURL":"http://developer.blackberry.com/native/downloads","simulatorURL":"http://developer.blackberry.com/native/downloads"},
    "win32":{"requiredPlatforms":["10.0"],"sdkURL":"http://developer.blackberry.com/native/downloads","simulatorURL":"http://developer.blackberry.com/native/downloads"}
  },
  "mobileweb": {
    "win32": {"Firefox": ["[10.0, 30.0)"], "InternetExplorer": ["[9.0, 30.0)"], "Chrome": ["[10.0, 30.0)"], "Safari": ["[5.0, 10.0)"]},
    "macosx": {"Firefox": ["[10.0, 30.0)"], "Chrome": ["[10.0, 30.0)"], "Safari": ["[5.0, 10.0)"]},
    "linux": {"Firefox": ["[10.0, 20.0)"], "Chrome": ["[10.0, 20.0)"]}
  },
  "tizen":{
    "linux":{"requiredPlatforms":["2.1"],"sdkURL":"https://developer.tizen.org/downloads/sdk"},
    "macosx":{"requiredPlatforms":["2.1"],"sdkURL":"https://developer.tizen.org/downloads/sdk"},
    "win32":{"requiredPlatforms":["2.1"],"sdkURL":"https://developer.tizen.org/downloads/sdk"}
  }
}
In particular for Android the regular expressions used are brittle and difficult to reconstruct since they match against the expected installed directory/filenames, while we need to compare against an xml file with the segments broke out into "fields". i.e. "addon-google_apis-google-10" is the directory on disk, but in xml the "google_apis" is the "name-id" value, "google" is the vendor_id" value and "10" is the api level. Ideally we'd break that out more explicitly: Here's a suggestion for how the android platforms' file would look:
"android": {
	"mobile": {
		"addons": [],
		"tools": ">=14",
		"platform-tools": ">=10",
		"platforms": ["2.3.3"]
	}
	"module": {
		"addons": [
			"google_apis-google": {
				"apiLevel": ">=10"
			}
		],
		"java": ">=1.6.0_25",
		"plugins": [
			"jdt": {
				"name": "Java Development Tools",
				"id": "org.eclipse.jdt.feature.group",
				"url": "http://download.eclipse.org/releases/kepler",
				"version": ">= 3.0"
			}
		]
	}	
}
In general my suggestions are to use Node/npm semantic versioning strings rather than our haphazard version, range or regex approach. Additionally, explicitly state the addon unique id as a key (here I'm assuming the unique id is a combination of name_id and vendor_id). Lastly, break out the dependencies required by mobile versus module development. As for the URLs we have here, I'm not sure if we should be including them here or not.

Comments

  1. Christopher Williams 2013-07-01

    I should note that we've already asked the same question internally in our group a few times regarding how to handle maximum versions. Generally we want to specify some maximum version that we know it should work against, but not limit the user to only that version range. I think it makes sense to have a specific maximum version that is treated as "soft" in that the CLI/Studio can warn a user that they're using Titanium on an untested version of the underlying platform but still allow the user to try it out (whereas with a minimum we may make it a "hard" requirement and error out).
  2. Ingo Muschenetz 2013-07-01

    I very much like the idea of a "soft" maximum. [~ayeung], [~blainhamon] and [~cbarber], thoughts?
  3. Ingo Muschenetz 2013-07-01

    One note about the google addons regex. That's partially because Google _will_ switch between using - and _ in their names. I mean, "google_apis-google", "google_apis_google", "google-apis-google" and "google-apis_google". You might ask why? I don't know. But they have.
  4. Chris Barber 2013-07-01

    I've already started adding this to each platform's package.json. I don't have quite as much info, but it would be easy to add and expose in the "titanium info" command. As an example, check out the *pending* iOS package.json here: https://github.com/cb1kenobi/titanium_mobile/blob/timob-11869/iphone/package.json. Here's the Android version: https://github.com/cb1kenobi/titanium_mobile/blob/timob-11869/android/package.json. The platform specific package.json files are the best place to put this info. 1) the package.json files are platform specific 2) they are is easy to parse 3) they are shipped with the SDK 4) I've already started integrating it in the CLI
  5. Christopher Williams 2013-07-26

    http://studio.appcelerator.com/sdk_info.json
  6. Chris Barber 2016-08-30

    We've done a decent job putting supported versions in each platform's package.json. It's been there since about Titanium SDK 3.0.0, so I'm calling this fixed.
  7. Lee Morris 2017-03-27

    Closing ticket as fixed with reference to the above comments.

JSON Source