Jasonette Extension Workflow and Maintenance

[seletz]

Now that people contribute and start to develop extensions for actions and other things in Jasonette, we begin to see problems w.r.t. the extension development workflow.

This issue intends to kick off a discussion on the following and other related topics.

XCode Project Issues

As soon as more than one developer works in the main repository, changes in the XCode project files start to become an issue. While these files are text files in principle, merging them is a PITA.

Also it's not immediately clear what changes should be merged.

• How do we manage XCode project files and work spaces?
• Do we need to git-manage them at all?
• How do other successful projects in the same area solve this problem?

Extension Maintenance

While the current practice of adding code to the main line of Jasonette is probably OK for now, not all extensions people come up with are useful or generic enough to warrant a inclusion in the main line of Jasonette.

• How can we support out-of-repository sharing of extensions?
• Do we need to add special code to Jasonette to support a plugin-like system?
• Are binary frameworks "good enough" and can we use cocoapods?

[thedumbtechguy]

Extension Maintenance

This application is already a very complicated beast with many difficult to understand parts.

I propose that

1. We move the core components into a "core" package. This will include anything not actually layout or action related; the Network stack, state machine, parser, layout engine etc.
2. Move each layout and action component into their own projects.

This should increase maintainability of the core as well each component. If a bug was fixed in say, the "Image" layout component, you would only need to update that dependency and redeploy. This would also allow and encourage contributors to add more third-party components as well as submit bug fixes and improvements to first party components.

The "core" would obviously reference a list of first party components that are core to Jasonette e.g. Image, Util etc so it can be used out of the box. But users who want to would be able to swap out and replace core components if they wanted by simply importing or writing their own replacements.

For mapping components, there are two options.

1. If we move each component into it's own package, the we can keep the current system and simply use the naming system to resolve components
2. A dictionary

Below is pseudo code, but I want to emphasize that it be strongly typed and not be in json. :)
{
    "image": JasonImageComponent.class,
     "map": JasonMapComponent.class,
     "label": JasonLabelComponent.class,
     "abracadabra": MyMagicPerformingJasonComponent.class
}

I believe I've addressed

• How can we support out-of-repository sharing of extensions?
• Do we need to add special code to Jasonette to support a plugin-like system?

Now for

• Are binary frameworks "good enough" and can we use cocoapods?

I'm not sure what works best in the ios ecosystem, but it seems cocoapods are already used by jasonette. However, I believe we have to evaluate the current ecosystem and find out if there is a better alternative. We want to make component imports as seamless as possible.

For Android, it's easier. Gradle allows the use of jar, aar etc. For first party packages, I believe aar packages on jcenter is a no brainer here.

[gliechtenstein]

As a side note, I do think we need a short term solution.

For example, I am looking at @seletz 's AzureMobileAction and think it's awesome. I think a lot of people would appreciate it. Here's the problem we have at hand:

I am not sure what impact it will have to merge this AzureMobileAction code, even though it's clearly useful. I had a discussion with @seletz on slack yesterday but I can see this becoming a more generic push notification action that handles not only Azure but also Amazon SNS or UrbanAirship or whatever. But, then again, the current version I am looking at looks like it's becoming a full fledged Azure API powered by Jasonette, which is also a good direction. It's hard to decide immediately. I think this needs some brewing period among the community.

More specifically, we want these extensions to be more visible to the entire community simultaneously (not just the people who look at pull requests), and I think there should be a much better (frictionless) solution than pull requests for sharing these code.

At the moment I can't dedicate my time to deconstruct the core engine into modules like @frostymarvelous suggested (although that's probably the direction we will head towards) because I need to work on things like Android and releasing JS code as their own open source repo. Unless someone steps up to take this task head on, I don't think I would be able to get to these for at least a month.

Maybe there's a quick and dirty fix for this situation until we can come up with a final solution and start working on it? Actually I think coming up with one of these adhoc solutions will help in coming up with the long term solution as well.

So.. Anyone have a suggestion?

I'll start with one: maybe create a highly visible page on the repo for extensions where people can link their code and install instructions to, and connect it to slack channel so people get notifications when there's a new extension, as well as tweet it out from the official twitter account.

[gliechtenstein]

Addition:

I did some research tonight and I think Cocoapods is the way to go.

As for some background on Cocoapods vs. Carthage (There are only these 2 dependency management tools in the iOS community), Cocoapods used to be the only way to manage dependency, but recently Github released Carthage and it's getting traction as well.

You can think of Cocoapods as a package manager meets centralized registry, sort of like NPM or RubyGems, or Gradle. (It was inspired by ruby gems).

Carthage is a different beast altogether. It's decentralized, meaning there is no central repository where you can discover these "packages". I think there's a reason why Github is pushing it (because while it's "decentralized", most libraries are hosted on Github, whose search functions as sort of a "centralized registry"). However it's inconvenient when it comes to discovery. It's supposed to be cleaner though, because unlike Cocoapods which takes over the whole project, the output of Carthage is a group of frameworks files you can just drag and drop into Xcode. This is why the people who like Carthage like Carthage.

Anyway, after a bit of research and thinking I think in our case it makes more sense to go Cocoapods route because modules are more discoverable and it's easier to install (User friendliness is top priority for Jasonette). Lastly the way Cocoapods works is similar to Gradle so I think this would be more compatible with the Android version as well.

I feel like This, and the approach I mentioned in above post would work well. But any other thoughts appreciated.

[thedumbtechguy]

it's easier to install

I'll take that over discovery any day. The problem with discovery can easily be solved with with a managed listing wiki page or even something like Android Arsenal.

But we want an easy process. Add a line to a file and voila! I see that Cocoapods does that very nicely.

Concerning the issue of how this would work, we could experiment using the Android version before back porting those changes to Ios. That should allow you to focus on fixing any issues with the current release rather than splitting time, unless someone can take up that task, which would be awesome!

[seletz]

Ok, cool -- so let's give cocoapods a spin.