I am evaluating the creation of an IntelliJ IDEA plugin which would ship OS-specific binaries, for macOS, Linux and Windows.
The binaries are fairly large, so I don't want to ship binaries for the 3 OS in the same plugin archive. Is it possible to create OS-specific zip archives for an IntelliJ plugin?
It's not possible to make 3 different binaries for the one plugin.
Different approaches you can take:
3 different plugins. Shared code can be put in a different code module
The plugin downloads the binary upon startup from a private server (ftp / nexus)
Install the binaries separately, and have the plugin find the binaries via an environment variable
Good luck!
Related
What is the difference between a normal executable jar vs building jar using izpack ?
a) Does it have pre-build configurable wizards?
b) Advantages over the traditional executable jars?
I have build executable jars via eclipse, intellij and it works perfectly in any OS and it is platform independent as well.
Thanks.
As the first line on their official site says...
Easily make installers that work seamlessly on Microsoft Windows™, Linux™, Solaris™ and Mac OS X™.
http://izpack.org/
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.
I have an Eclipse Feature that I'm building that contains a few plugins. One of the plugins uses the import package statement to declare a dependency on another plugin.
The other plugin has platform specific code and exists in another feature that I'm building. I have two plugins in this feature that have the platform specific code. One for os=win32 arch=x86 and the other for os=win32 arch=x86_64
Both features are being built and using Tycho and they both have p2 repositories that are successfully available.
So, I made a composite repository that points to both of these repositories, and then I use the "Install New Software..." command in my RCP app and point to the composite repository to install the first feature I mentioned.
The issue is that when the installation is done, the plugin that has the platform specific code has failed to install correctly. Specifically, the plugin for the x86 system shows up on my 64bit machine.
In your feature.xml, choose the plugin with platform specific code and add a platform filter. the filters are available on the right side (once you select the plugin). You can choose filters such as:
OS
WS
Language
Architecture
When your feature is published, p2 will generate the appropriate filters.
I found the answer.
I needed a p2.inf file sitting next to my feature.xml file in the first feature I mentioned in the question.
And in that p2.inf file, I needed this text...
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86))
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86_64
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86_64))
I added this file to the build.properties as well to make sure it was included in the deployed feature
Then when I deployed the p2 repository and performed the install into my RCP application, the correct plugin was placed onto my 64 bit machine.
UPDATE: I was wrong here. This is NOT the correct answer. The incorrect plugin still gets installed on some machines.
i go to eclipse download website
i find Eclipse CDT - a version of eclipse that is standalone
in my standard Eclipse SDK(not cdt)
i can do this:
Help->install new software-> then i get a window popup and ask me to give the url
it looks like this:
so then you can install it
this is a separate standalone Eclipse CDT :
this is a standalone Eclipse SDK:
my question is:
1.what is the difference between separate Eclipse CDT and installing CDT plugin onto Eclipse SDK OR are they same thing?
2. what is better? is it better to use a separate Eclipse CDT or just install a plugin inside my Eclipse SDK?
thanks in advance!
Short answer: there is no important difference[1] between the two.
Longer answer: The Eclipse IDE is nothing more than a bunch of plugins that work together to create the functionality for code editing (and other things).
When you go to http://eclipse.org/downloads, you'll see a bunch of different packages. Each package provides a certain set of features, but this is no more than a convenience so that you don't have to install the vanilla SDK and then install the stuff that you really need on top of that. The php dev will not need the C++ compiler and vice-versa. But, you can install it if you want. At it's core, the same small set of plugins are re-used between all distributions.
You can compare the different distributions here: http://www.eclipse.org/downloads/compare.php
[1]: Actually, the difference is that the SDK includes source code for all features as well as the Java compiler and plugin development tools. The C++ tools do not include these.
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.