It would have been cool to be able to also compile SWF files even in AIR mode.
I have SWF modules on an AIR app that i want to load/unload when necessary. Their code is in the same project than the global AIR app.
It seems i have no choice but using ant or creating a new (flash) project to be able to compile those SWF where a chained task of sub tasks would have done the job if i could compile SWF even in AIR mode.
Last option, build an AIR app for each module and only keep the SWF file... not the best.
Or am i missing something?
Two ways:
Referenced Project
Create a properties profile and launcher that doesn't start the .SWF
Referenced Project
Creating a Referenced Project and use that as a base to generate modules is the preferred way. Some have just use one referenced project to create modules, some use a unique project for each module. You can then move the .SWF to your base project with an Ant script.
Properties Profile And Don't Launch With ADL
Since the AIR workflow creates a .SWF, just do that and create different profiles and don't launch the generated .SWF with the ADL. To test the .SWF you can just use an ANT script to test it.
Related
My iOS project uses third-party dynamic library that needs to be code-signed and bundled into the application. In Xcode, this can be easily achieved by adding new Copy files build phases. The Xcode project is generated with CMake, however I can't find a way to define this copy files build phase. MACOSX_PACKAGE_LOCATION makes the library treated as bundle resource and doesn't do code signing.
There is surprisingly very little information on the topic on the web, so does anybody know if it is possible to define Copy files build phases in CMake? Or, alternatively, is there another way to code sign and bundle third-party dynamic library using CMake?
Why when I'm generating an artifact for a javafx application using Intellij IDEA, besides the .jar, it generates a .html and a .jnlp file?, are those two necessary for the application to work, if not is there a setting I can change in order to don't create those anymore?
Files Required for Various JavaFX Execution Modes
it generates a .html and a .jnlp file?, are those two necessary for the application to work
The files required for deployment depend on the execution mode of your application.
If your application is embedded in a browser (e.g. executes via the Java plugin like a traditional Java applet), then you require all of the .html, .jnlp and .jar files.
If your application is launched from a browser via Webstart using the Java deployment toolkit, then you require all of the .html, .jnlp and .jar files.
If your application is launched via Webstart from a web page via a direct href link to the jnlp file, then you only need the .jnlp and .jar file.
If your application is distributed as a "standalone program" (e.g. "Users launch it using a Java launcher, such as java -jar MyApp.jar, or by double-clicking the application JAR file."), then you only need the .jar file.
If your application is distributed as a "self-contained" application then you need none of the .jnlp, .html or .jar files, as everything required to run your application will be packaged into a native install package (e.g. .rpm, .msi, .deb, .dmg) that you will distribute.
Suggested Approach
As you will be using the "standalone program" form of distribution, you only require the .jar file for distribution and can ignore other files created by the Java packaging tools.
While you could have Idea package your application as a JAR by choosing Build | Build Artifacts | Edit... | + | JAR | From modules with dependencies..., I don't recommend that as you will also need to set a main class in the manifest and will lose some of the functionality of files which are packaged using Idea's "JavaFX Application" packaging type, such as in-built detection that the Java runtime used to launch the application meets minimum requirements to run JavaFX applications and transparent network proxy support.
So instead, just use, unchanged, the Idea artifact packaging configuration that you have already setup. Ignore the .html files and .jnlp files output. Just distribute the .jar file to your users along with instructions on how to launch it either via java -jar MyApp.jar or double-clicking the .jar after a Java runtime has been installed on their machine.
Portable Build Advice
If it is only you developing the project and you are unfamiliar with external build tools such as maven or gradle, then it is (probably) simpler to use the artifact packaging features built into your Idea IDE rather than to learn and use external tools.
If your project might potentially be worked on by other developers or builds are to be produced and tested within a continuous integration system such as Jenkins, I do not recommend relying on IDE specific build systems such as the artifact packager in Idea. Instead, use an external build tool such as maven or gradle. There is a maven plugin and a gradle plugin for JavaFX build.
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'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.
I've never worked in XCode before but I am designing a plugin (objective-c) for an open source radiology program called OsiriX. I can get the thing to compile and I can even get the plugin to run in OsiriX. But, I'm not sure how to run/debug it from XCode. Run/Debug is grayed out on my xcode. Is it because there's no main program?
(1) "Clean all" your projects so that there isn't detritus left around when you do this.
(2) Set Xcode to use a common build products directory (I stick mine in /tmp/ so that it periodically gets nuked). The preference is under the "Building" section.
(3) Re-build OsiriX (so that it'll be built in the shared location).
(4) Make sure the active configuration in your plug-in project has the exact same name as the configuration in OsiriX that you built in (3). (It should probably be "Debug" or "Release", depending on which you build). The configurations can be edited in the build settings editor.
(5) Build your plug-in.
(6) Add a custom executable to your plug-in project and set the path to OsiriX (Project -> New Custom Executable...).
You should now be able to build-and-run or build-and-debug your project. It will launch OsiriX from the build products directory. You might also want to set OsiriX to look for bundles in your build products directory, if it doesn't already. Or you could create a symbolic link from one of OsiriX's plug-in directories to the bundle in your build products directory.
cd /path/to/OsiriX's/bundle/directory
ln -s /path/to/build/products/YourPlugin.bundle
This is a very standard way of ocnfiguring Xcode for development of plug-ins. For example, preference pane developers will set up a custom executable for SystemPreferences.app (even in /Applications -- there is no need to point to a "debug" build of the application).
In order to debug your plugin, you have to be running Osirix in Xcode as well. Download the Osirix source code from Github and compile and run it. You'll have to add the plugin to its plugin list and then when you run in Xcode your NSLog statements from the plugin source will print out in the Xcode console screen for the main Osirix program. I believe breakpoints work as well.
My experience with Xcode is also somewhat limited, but I've found that using the latest version (6.1.1) I can debug my plugin simply by attaching to a running OsiriX process via the Debug -> Attach Process menu. This does not require you to build OsiriX from source - I'm currently using the standard (non-MD) version as downloaded from their website.
Note that you still need to restart OsiriX to pick up any changes to your plugin.