[TIMOB-9037] CLI: Implement "export" command
| GitHub Issue | n/a |
|---|---|
| Type | New Feature |
| Priority | Medium |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | Release 3.0.0 |
| Fix Version/s | n/a |
| Components | CLI |
| Labels | core, ft, ios7, notable, planning-3.3.0 |
| Reporter | Chris Barber |
| Assignee | Unknown |
| Created | 2012-05-07T17:25:32.000+0000 |
| Updated | 2018-02-28T20:03:41.000+0000 |
Description
Exports a project to a standalone project without any dependencies on Titanium. The arguments will be similar to the build command.
Current suggested requirements. Feedback appreciated: 1. Start with implementing for iOS (to replace transport.py), but then implement Android afterwards. 2. -Project exported would need to be able to be modified. Thus, you can edit the JavaScript or other assets.- 3. The resulting project _cannot_ be directly re-imported, so exporting is a one-way street. You could manually copy the modified files back into the original project. 4. The recipient _should_ not need to install any software or tooling to use the resulting project in Xcode. Transport.py appears to have copied the build process (Python files) into a single Python file. Since Python comes pre-installed on OS X, not an issue. Our current process involves Node. I don't believe we can ask recipients to install Node, so we'd need to do something in Python or Bash or ? 5. The Project should be able to run in development or production modes. This means allowing the user to switch the deploy type. This currently is baked into an Objective-C file. We could do this as #defines and allow the user to switch between those using pre-defined targets in Xcode. However, we already have 3 targets in a project (iPhone, iPad , universal). Do we create 9 total targets (3 flavors x 3 deploy types)?
I think this covers it as I have seen the requirements from customers.
Regarding #2, I think we should NOT allow this. If you want to edit JavaScript files, then you need the original project and Titanium. Once you export, you should not be able to edit the JavaScript, nor can you debug it. There's too much tooling that would need to be packaged up in order to be able to build an app. We'd basically need to ship Node.js, the iOS build script (with changes), titanium_prep, all of the modules, Node dependencies such as Uglify, etc. Rewriting the iOS build process in Python is a really, really bad idea.
The primary purpose of this is enterprises often have a build master that controls all of the builds that are submitted tot the app store. They usually do not have titanium, so the developer needs to be able to send them an Xcode project they can sign and distribute.
{quote}2. Project exported would need to be able to be modified. Thus, you can edit the JavaScript or other assets.{quote} No, they don't need to be editing. Simply checking entitlements and signing.
Yeh I don't see why editing needs to be a requirement. My only experience with transport.py is so someone else that doesn't have Titanium can package and distribute.
Okay, removed item #2. Two questions: 1) When we discussed this feature, _another_ goal was to replace scripts like: https://github.com/billdawson/tidevtools/blob/master/ti_eclipsify.py. The issue being that internal developers needed to export the project to open it up in ADT. In this case, It's not clear to me if they need to edit JavaScript. 2) Deployment type. When we export the project--we have two choices: 2a) Do we export it for a specific deployment type, i.e. development (no encryption), test, or production (encryption) 2b) Or we export it encrypted (production) and allow the user to choose a deployment type via Xcode targets (or editing an Objective C file) 2c) Or something else?
We've decided that the concept of export will need to change based on the new platform structure. Closing this valiant PR, and we will revisit this in a subsequent reincarnation.