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.
Related
i am using idea ultimate 2020.3
i created a maven web project.
when i changed java or jsp files and choose update class and resources, they can be hot deploy.
however, if i changed files under src/main/resources, e.g. mybatis xml file under src/main/resouces/config/mapper, they cannot be hot deploy.
how can i fix it?
Make sure you are deploying an exploded artifact, see Update applications on application servers
Also make sure the module has configured Web resources (has the Web facet with Web Resource Directories and Source Roots configured:
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/
Can you use standalone + JRebel remote?
I have my IDE on Box A
I have my App on Box B
I want to be able to make gradle build on Box A and automatically have B hot deploy that.
If Possible I'd like all this needs to work without The intelliJ plugin because it's broken and produces the wrong paths to lib locations in our complex gradle project.
No.
Synchronization with remote servers can only done via JRebel IDE plugin.
If you have any troubles with the IDE plugin or the Gradle plugin, please contact support at support#zeroturnaround.com
It's not possible to use JRebel remoting without the IDE plugin as the remote server does licensing checks during a sync transaction and classes simply copied to the remote .cache folder will be rejected otherwise.
However you can still setup a manual remoting setup. For example you can create a "virtual" workspace on BoxB where classes/jars/wars are copied after the build. In this scenario disable the remoting plugin and use standard rebel.xml-s which map to the workspace on BoxB.
When doing changes, simply copy the files from BoxA to BoxB e.g. using rsync and they will be reloaded as usual. However note that in this setup you must provide the server on BoxB with a valid license.
With CloudBees now supporting deployment of Java applications, is it possible to use the post-build action in Jenkins "Deploy to CloudBees" to deploy your app? Furthermore, I'd like to use the Maven assembly plugin's jar-with-dependencies goal so that I can simply and automatically deploy my entire app to CloudBees right through Jenkins.
While the current CloudBees deployer Jenkins plugin appears to not support this, in fact it does. Here are the steps that after much trial and error worked for me:
Include the jar-with-dependencies maven plugin in your pom.xml. I used the <goal>single</goal> and <descriptorRef>jar-with-dependencies</descriptorRef> described here. That will put an additional jar file in your target folder {artifactId}-{version}-jar-with-dependencies.jar
Deploy that jar via the CloudBees API. The last line of this page explains how to do that. Specify your runnable jar, make sure the runtimeContainer=java, and the jar file to be uploaded, and it should deploy. Even though CloudBees says to use a zip file, a jar file works just fine.
Once that has been deployed once via the command line, your app ID now "remembers" those settings so that it can be done via Jenkins so long as you're doing the CloudBees Deploy to that same app. In your Jenkins job, add the "Deploy to CloudBees" Post-build action to your configuration. Click "Add Web Application" (strange, I know, since it's not a web-app! CloudBees says they will work to change that...), select First Match (even if it's a Maven project, use First Match), enter your application ID that you deployed your app to in step 2, and then enter the full name of your jar file and try your build again. It should upload your jar file and activate the instance in your CloudBees PaaS. Note that this still hard-codes the version in the jar file - I am working to see how to setup a variable for the version of the jar file so that it corresponds to the Maven build version.
Once you have it setup correctly and deployed initially with the bees sdk, it should just deploy from the deployer plugin on Jenkins as a war normally would.
Once set up, the settings that define where your main class is persist between deploys.
I have a project that's using the Play framework, and the corporate standard is that all projects should be built by Hudson. However, I cannot find out how to do this, as Hudson does not follow any Java standards, and requires the framework installed at the computer it runs on. I have tried to build the project with Maven (if I had managed this, adding it to Hudson should be quite simple), but I have failed to make it work. I tried the Play Maven module, but Maven claims it does not find the external repo that is listed (http://nexus.infin-it.fr/content/groups/public). This might be because I am behind a firewall. I also tried the recipe listed here, but the local maven build fails because it is unable to find org.playframework:play:1.1:jar.
Has anyone done this and can provide a howto?
It can be done without installing the Play framework on the Hudson server, but it is quite complicated:
Put the play libraries (play.jar and its dependencies) in a Maven repository
Create a pom.xml for your project, configured with:
theses libraries as dependencies
your project specific dependencies (project lib directory)
the java sources folder of your project (in the maven-compiler-plugin): "app"
If your project is simple (no module dependencies), this pom allows you to build the play project java sources using Maven.
If your project has module dependencies, you will have to add the dependencies jar in your pom dependencies.
To do that, you will have to create jar files from the modules if they don't have packaged jars (to get the "CRUD" class of the CRUD module for example).
You can find some help on this page I wrote :
http://blog.infin-it.fr/2010/12/15/play-framework-integration-continue-retour-dexperience/
Even if it's in French, I put my Ant stuff and the Play's pom I wrote.
At work we managed to integrate our Play applications with Bamboo.
It should not be difficult with my files.
Just looked at the repository, that you linked (http://nexus.infin-it.fr/content/groups/public). And guess what, I found the play-1.1.jar. However, the artifact ID is: org.play:play:1.1:jar and not org.playframework
In theory, you could put the full Play zip on your build or in in your repository, and then use Hudson to kick off an Ant script to download Play to the Hudson agent, unzip it, and then run commands on it. It's a little clunky, but it should work.