I'm creating a OS X application that I intend to have a plug-in architecture. The plugins will be loaded dynamically. I wish to have a number of default bundles included in the application package contents but I am at an impasse with Xcode 4.x.
Is it the best approach to create another project in the Xcode workspace and deal with it that way or is creating different targets (schemes?) in the application project a better practice?
Any opinions, guidance, experience is thanked in advance
--Frank
I would create additional targets in your project for each of the plug-ins. Then, add a copy files build phase in your app the copies the plug-in into your apps's plug-ins folder.
Related
I am developing several little plugins for Eclipse. Each one having it's own name, view and icon.
I am now having them in separate projects and as I am reviewing my code, package structure etc. I asked myself: Is it possible to bundle them all in one project called (for example) Plugins or does each one has to have a separate project because of plugin.xml, manifest.mf etc.
I know, each plugin needs to have these files, but can there be more then one plugin in them?
Technically it is possible using bnd-tools way of plugin creation but not via PDE. But if you want you can migrate PDE plugins to bnd. If you are interested check http://bndtools.org/
I have an app that is dependent on a framework file that I wrote. They're independent xcode project and has their own Github repo. I want to create a fastlane to automatically add the framework to the app project and do a build whenever I commit to the app repo. Right now I have to manually add the framework into Embedded Binaries and Linked Frameworks and Libraries inside the app project. I can't find any actions in fastlane to update the project's framework section.
Thanks
If I understand your question correctly you are wanting to manage an API framework project which you main project uses.
Fast lane (IMHO) is about building and managing built artefacts. Managing dependencies within your project is a different thing. To that end there are two options which I am aware of:
Cocoapods - The only option for a long time. Ruby based tool. Manages dependencies by adding builds and XCConfigs to your project. Does this by re-writing your project files. Rebuilds all dependencies when you build. My opinion - I've never been a fan. I don't like that you really need to know Ruby to use it, the way it hacks into your project and enforces it's build ideas on you.
Carthage - Newer option. OS X native tool. Updates and builds dependencies only when you tell it to. Zero impact on your project, but you have to do a little work to include the framework files. Only works with frameworks. My opinion - feels more natural that Cocoapods and the best option.
I'm just starting to develop a new eclipse plugin where I want a web application server running in Eclipse. I found a nice blog, OSGi as a Web Application Server, that describes how to do this. The author suggests creating a target environment for my bundle requirements, and some of those bundles get pulled in from the Equinox Project SDK (now called Equinox Target Components in Juno). I notice that the tutorial project runs fine when my target platform is the platform I created in the tutorial, but fails to start when it is the default platform. So, now for my question...
If I need bundles that are not part of the default, how will my plugin project get access to those bundles? Will I need to deploy them along with my plugin? How would I know if the user's eclipse does or does not already have those required bundles?
You was not much clear about what kind of application you are developing. Running a web server in an Eclipse IDE as a plugin don't make any sense to me. This kind of server application is best just running on top of Equinox.
Anyway, the right path is to create a "Product Configuration" file and add categories that contains the needed bundles (go to File/Plug-in Development/Product Configuration).
With this file you can run an instance of the product (inside the IDE) and can export it (create a zip containing all needed bundles)
And if you want to able your user to install plugin inside his IDE you must create a P2 repository (using a Target Definition File) and expose the exported directory within a Http server. You could research about Tycho to build this kind of components in a maven style.
Well, I'm not sure if re-inventing the wheel again is really sufficient.
You might take a look at Pax-Web for inspiration on how to do it, or take a look Apache Karaf as a OSGi-Container (using Pax-Web). Or even better start contributing to one of the two :-)
Known is the command to create IntelliJ files needed for a Play application:
play idea with-sources=yes
This generates two folders:
.idea (containing libraries.xml)
.idea_modules
Most of tutorials or simple article on the net explain how to mount the app as an IntelliJ Project.
However, I want to mount it as a Module (as part of an existing project so), thus I've just used the .idea_modules file.
I can't imagine me setting ALL dependencies (more than 100...) manually...
How to deal with the libraries (dependencies)? Indeed, libraries.xml is used in .idea file and typically used when someone want to mount the app as an entire Project.
To put in a nutshell, is there an efficient way to set up a Play app in IntelliJ as a simple Module including automatically all needed dependencies?
It would be great if IntelliJ could implement an SBT feature like the one for Maven in order to import dependencies automatically.
I have a plugin for an RCP app that uses BIRT. I have a target for building my app which contains only the plugins/features that are required. I recently updated the BIRT plugin versions in my IDE, which created an incompatibility in the design files with previous versions of BIRT. I have the old version of BIRT in my target and need to update to the newer plugins.
In the past I have manually updated plugin jars in the target, but BIRT is a complicated platform with dependencies out the wazoo. Is there any utility or way of organizing my target differently that will make this easier to control in the future?
I would recommend to keep all components separately and not copy them into a single folder. You can use Target Definition editor (see File / New / Other... / Target Definition). So, after downloading all the pieces, you can unpack them locally and assemble your Target Platform using Target Definition editor.
You can also do the same using Window / Preferences / Plugin Development / Target Platform preference page. There you can select previously created target definition or specify base Eclipse install and then use "Add..." button to add additional components from local folders or remote sites.
Also, as far as I know the PDE team is currently working on expanding Target platform support in Eclipse 3.5. I think they are planning to allow to select Target Definition per-launch configuration and per-project.
Im not sure if i understand you right, so please let me know if not.
When i use third party libraries, i create a plugin for every single one.
Example:
xstream library:
Import the jars (also the source code)
Add the jars to the MANIFEST
Bundle-ClassPath
Add all xtream packages to the
MANIFEST Export-Package
When a plugin needs the code of the xstream library it has to depend on the xtream plugin. Because the packages are public, every plugin can use the source code of it.
When a new version of xtream is comming, you only have to update the jars and not the dependend plugins. Sometimes you have to update the export packages of the third party plugin.
All depended plugins you dont have to change.