Together with my team I'm developing multiple native plugins based on Trigger.io. Since the recent changes I'm not completely sure on the workflow and cannot find anything about it in the documentation either. Some questions that arise:
1) Should one set of inspector projects be used for all the plugins or should each plugin has its own set?
2) Which parts of the inspector projects should be maintained via version control, which should remain local? (fyi: we use SVN)
3) (Android) When using one inspector project for each plugin, whats the best way to import them all as Java projects in Eclipse? Note: each inspector project has 3 sub projects which have the same name across different plugins, so they'd have to renamed? Assuming I have 5 plugins in development, that'd mean that I have to import 15 Java projects into Eclipse. Is this really how it's meant to be?
The most effective way to develop plugins is still something we're working on, how things are right now is probably not as good as it could be (especially for developing multiple plugins), but as things are right now:
1) Each plugin should have its own set of inspector projects.
2) The majority of what the Toolkit puts in the plugins folder is probably best in version control. Things you can safely ignore are the .trigger folder and any bin, gen, or build folders in the inspector projects. If you are trying to keep less files in version control the things you definitely need are the assets/src folder in the ForgeInspector, and any of your own source in ForgeModule, the rest of the inspector project should be regenerated by the Toolkit.
3) I'd recommend using an eclipse workspace per plugin, as the Toolkit regenerates a lot of the code when you update the inspector I don't think it is currently possible to rename the projects.
I thought I'd include a quick overview of what the 3 projects are and why there are 3:
ForgeCore - This is the pre-build core library for Trigger.io apps, its used by both ForgeInspector and ForgeModule so it needs to be a separate project that can be referenced by both
ForgeInspector - This is meant to replicate as closely as possible how your plugin will actually be used, so is basically a stripped down Trigger.io app, its separate to ForgeModule so that you can see what code is in your plugin and what code needs to be put into build_steps.json so it will also be applied to a real Trigger.io app at build time.
ForgeModule - This contains your plugin code
Related
I have a NetBeans javascript project with several included paths for plugins. I do not want to include the plugins in my core repository, so I have created separate, external folders for each and am including them via an include path. Because I test across many devices, I need my changes to upload on save and this works fine for the main code base, however, I would like to be able to edit a plugin via the include path and see those changes auto uploaded as well. Is this possible?
As of right now, the only alternative I see is to create separate projects for each plugin, which I am willing to do if this is the only option. The single project workflow is very preferable to me and I might be willing to switch IDE's if this is possible in another environment.
I would be happy to elaborate if my intentions are unclear.
I don't think it's possible. What about creating one single "umbrella" project for all plugins and simply manage it the same way you do the main project?
Personal note: What you have is basically several projects and the uploading is focused always on single project. So what you want is like "I want to treat them as projects but not to at the same time" :) Btw, how do you edit a plugin? I guess open it as a project in NetBeans or use some text editor. So again you basically treat it as a project.
I have a set of plug-ins which need to support different Eclipse products. There is a core plug-in, which is product-independent, and an adaptation plug-in each for Product X, Product Y, etc.
Deployment-wise, I'm thinking one feature for the core plug-in and one for each product, containing the adaptation plug-in and having a dependency to the core feature, so the core plug-in gets installed without the user having to select it.
1) Is there a better way of structuring the features?
On the development side, I would like to be able to work with both the core and adaptation plug-ins within the same workspace, which as I understand it gives me two main options: a) working within each product using their respective installations as target platforms, or b) working in raw Eclipse with an explicitly defined target platform for each product.
2) What would be the best way to set up the development environment?
If option a), can I use the same workspace for different products or would I need to set up separate workspaces? In other words, are different Eclipse products able to share a workspace as long as they're all based on the same (say) major version, eg 3.x?
If option b), can Eclipse manage multiple simultaneous target platforms? In other words, can different plug-in projects within the same workspace be compiled against different target platforms during the same build? And if not, how could I automate switching between them so I wouldn't have to do that manually during a workspace build?
Or indeed, am I missing something fundamental and is there a much better way of doing all this?
The short answer is you can do it either way.
You can have 1 workspace per product, and each workspace has the target platform of that product. At the moment, eclipse supports one target platform active per workspace, not per project though.
Or you can have eclipse and the 3rd party plugins you need as your target platform, and simply work on all 3 products and the common plugin in one workspace. If your total source plugins is <20, this would probably be fine. For >20, eclipse supports Working Set which would hide the plugin you are not working on at the moment.
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.
I've developed a static library that I'd like to share between XCode projects. I did some reading to learn exactly how to include this library as a binary dependency so that it runs on both the device and the simulator and that lead to a couple of manual steps which I'd now like to automate. Overall I'd like to be able to release new versions of my library and have a simple upgrade process for any project using the older version. Currently that process consists of deleting and/or copying the new binary files over the original location, deleting copying over new header files. The initial install consists of the same two steps along with additional project/target level configuration to set conditional linker flags based on the target SDK. Is there a way this could be automated? I mean I know I could do something like write an Applescript to do the heavy lifting but how? Has anyone ever automated xcode build settings via applescript? How would I call into XCode via Applescript? Are there any other alternatives? Is there a better way to maintain binary level dependencies?
Update
I'm looking to maintain a binary level dependency where project A depends on a static library created by project B. Something similar to a framework that can be included into an XCode iPhone project easily. After building "B" I want something that can practically be dropped into and project including A. While I am becoming aware of all the procedures around leveraging such a dependency I am looking for some solutions to soften up all of the rough edges.
Add a custom build script through Xcode:
select your target under the Targets group on the left
select Add -> New Build Phase -> New Run Script Build Phase
double click on the new Run Script item underneath your target
this allows you to write a shell script, accessing most of the Xcode environment variables related to the current build, e.g. $BUILT_PRODUCTS_DIR
if you check the "Show environment variables in build log" and view the detailed build output you can see all the variables available.
Have a Google search and you'll find lots of examples, e.g. section 20.3 here etc.
If you are using Subversion I believe you can use SVN externals to specify which particular version of your library to use.
You just have to drag & drop your library project in your project. xCode will dot the rest...
Regards,
Thierry
I have an iPhone app, and I'm taking a few features of the app and creating a new app.
What's the appropriate way to build two apps from a common code base?
One more option nobody seems to have mentioned yet - you can create a new target in the original project file. I do this for "free" and "paid" versions of the same app, but it'd be useful for any two apps that share most of the same code.
I got this from an Xcode expert:
Xcode has two affordances to do the right thing here:
1) For files outside your project tree that your project requires, set up a source tree. Xcode > Preferences > Source Trees, define a symbolic path (e.g. EXTRA_SOURCES) with the actual path on your disk to where they're checked out. Then when you add those files to your project, add them Relative to Source Tree to that source tree.
(N.B. Quit and restart Xcode after defining the source tree in Prefs.)
2) In Xcode 3.2, define the Project Roots to include the Source Tree. Project > Edit Project Settings > General tab, "Configure Roots & SCM" button. Add the source tree to the Project Roots and set up its repository, which can be a separate repository from your main project files.
That's it. You have one file tree, from one repository, but many projects can share it, and if you perform an SCM operation on the source in one project it's reflected in others.
Ideally you would be able to make a dynamically linked shared library (or "framework" in Apple parlance) from the common code, but the iPhone platform does not support this. In addition to the approaches already suggested here, you can link against your own static libraries.
Building static libraries with the iPhone SDK
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
Keep the common code in a common repository. Then you can easily use it in as many projects as you want.