I've created a java program and I'm wanting to run it from the iSeries. I've been able to get it to run from the QSH so I know it compiled and runs fine, but I need to run it from the command line not QSH. The program requires the jsch-0.1.55.jar file for the program to work correctly and I'm not 100% sure how to to call the jar file with the program its referencing to.
I've tried
RUNJVA CLASS(ANL0106J) CLASSPATH('/JAVA/Jars/jsch-0.1.55.jar')
That didn't work. Then I tried
RUNJVA CLASS('/JAVA/Jars.jsch-0.1.55.jar':. ANL0106J) CLASSPATH('/Java/Jars/jsch-0.1.55.jar')
That didn't work either. What am I doing wrong?
Having successfully done this many many times, your last try seems pretty close, but change the CLASS parameter to point to your class file which contains the main method. ANL0106J seems like a pretty weird class name.. Example would be:
CLASS(com.company.test.ApplicationMain)
With the CLASSPATH pointing to the required jars using the full path names. For example:
RUNJVA CLASS(com.company.test.ApplicationMain) CLASSPATH('/test/app.jar:/test/dependency.jar')
To make matters a bit easier, you could even include your dependency in your JAR file by using something like maven or Gradle to create your builds, which can then be configured to generate fat jars. Essentially, those are jars that contain the other JAR files that your application depends on. That way, you can also be pretty sure that your application will continue to work, even after you update a single jar file on your ibm i machine for example. Shadowjar for example is pretty easy to setup using a gradle project which will do this for you. Then it's just a matter of running the bootjar gradle task and using the RUNJVA command, simply pointing to your single JAR. Don't get caught up in dependency management hell, please. Save yourself and future devs by using something like maven or gradle. Gradle/maven can even be used to manage depencencies using a maven repository with a tool such as Sonatype Nexus which can also be hosted locally. If your JAR has a valid manifest, you don't have to do anything else. It would look like this:
RUNJVA CLASS('/test/app.jar')
Especially useful for using CI, which can build the JAR for you from a GIT repository and place the fat jar in the correct path, with you not having to do a single thing. Setting up Jenkins on an as400 isn't that difficult at all using the apache WebSphere application server which is an option that can be used to host WAR files, to put it simply (it can do a lot more than that though :P).
Hell, using only a single jar for the RUNJVA command should also speed up the time it takes to start your application since it only needs to verify a single jar. Just food for thought. Here's the maven entry by the way:
https://mvnrepository.com/artifact/com.jcraft/jsch/0.1.55
On a side note for java/react devs: Yes, fellow Java/react developers, one could use the RUNJVA command to modernize ibm i development to run Spring boot applications! We are successfully running react front end applications using a spring boot backend system, Works extremely fast, as expected :)
(Same answer given to you on Reddit, simply on this platform to make it visible for others that are looking for this on Stackoverflow)
Related
I am building a JavaFX application in Intellij that will be built and distributed with an .exe installer and will be ran as an exe Application. I have been trying to find a way to allow for remote updates, but I have only found resources that update a jar file by using another jar file hosted on a website. Is there a way to allow for remote updates to a exe JavaFX application? I have though about using update4J, but sadly I have no idea how to implement it, use it, or if it will even work with exe applications. I have tried to use FXLauncher, but I am not able to use JavaFX with maven as an error occurs whenever I try adding maven framework to the project.
I am the developer of update4j.
The framework used to be complex and hard to use, but the last release (1.2.2 at time of writing) significantly simplified things leaving only one pain point, namely, generating a configuration.
So for starters, launch the framework using it's own main method:
# on classpath
$ java -jar update4j-1.2.2.jar
# on modulepath
$ java -p update4j-1.2.2.jar -m org.update4j
And read the output.
Creating the configuration is done using a builder, I'm still documenting it but the class javadoc for Configuration is quite complete.
I have created a simple springboot application with inbuild tomcat which works fine when I am running it as JAVA Application in Eclipse. I tried to export this as a WAR file and tried to run it in Windows command line and also in UNIX box. I tried to execute it like below,
java -jar C:\Users\Iam\Documents\SpringHelloWorld.war main.java.com.controller.SpringBootWebApplication
Error: An unexpected error occurred while trying to open file C:\Users\Iam\Documents\SpringHelloWorld.war
java -cp C:\Users\Iam\Documents\SpringHelloWorld.war main.java.com.controller.SpringBootWebApplication
Error: Could not find or load main class main.java.com.controller.SpringBootWebApplication
I just export it as a WAR file, should i need to define anything before exporting it as WAR in Springboot ( note: i am not using maven or gradle )
Below is my project structure :
enter image description here
Probably it is possible to do this without Maven/Gradle, but I would never take this approach.
Even considering the best case, you will end up re-creating what others have created in the Spring Boot parento pom.xml or in his Gradle equivalent, so why you would waste a lot of time recreating what is already created by someone else? If you really want to know how the war is created, then take a look in Spring Boot parent pom, but you should limit your work to wrap what is ready for production in order to compose your solution.
Also consider that Maven and Gradle are constantly developed and updated, along everything belongs to their ecosystems. If you plan to replace them, then you should be prepared to mantain and develop alone your own build platform, which is a non-trivial effort.
Better include Maven or Gradle, you'll be more productive.
I have a Java application I've developed in Eclipse. To package it into a .jar, I simply run File->Export->Runnable JAR file with copy jar files into sub folder selected.
For deployment, I turn over the compiled jar file along with my source code and the deployment team packages it up and deploys it to our systems. One of the responsiblities of the deployment team is to verify that the source code that is turned over compiles into the binary that is turned over with it. This is the only Java program the deployment team works with so they don't have Eclipse available to import my source code and validate it against what I provided them. For the time being, they have just been taking my word for it, but that needs to change. They will need to compile the code on their own and make sure it matches what I've given them.
How would they go about doing this? I suppose one option is to get all of them up and running Eclipse, but that seems like an overkill. Is there something they can run outside of Eclipse without having Eclipse installed to generate a jar file that they could validate is the same as what I've provided?
Thank you for any assistance.
First, how can they tell that what you supplied "matches"? That doesn't really make sense.
What they really want to do is to build their own deployment artifacts from your source. They can either set up Eclipse and use that as their build tool, or you and they can agree to use a build tool such as Maven or Gradle. These tools integrate with Eclipse, but they are designed to run stand-alone or as part of a tool like Hudson or Bamboo, which will perform build on a schedule or when a VCS is updated.
A client used Maven and Bamboo, along with the rest of the Atlassian suite, to handle enormous builds based on contributions of more than 100 developers. That included running JUnit tests, test coverage, and code quality tools.
I am currently building snapshots of a project using Java, Maven, Jenkins and Artifactory, and running the WAR on Tomcat.
After I copy a WAR file out of Artifactory into Tomcat and rename it, I have essentially "lost" the version of the application. I have two remote teams that are constantly dropping wars across integration machines and it very quickly becomes difficult to tell what is running where.
Eventually I would like to be able to query the app for it's version, or even just print out the app version into a log file at startup, but first I have to get the version into the war file itself.
I'm not entirely certain which entity is responsible for creating the version but it looks like it is Artifactory creating the SNAPSHOT version, like "myapp-1.2.0-20140514.145130-1.war".
The only solution I can think of is to stop using snapshots, increment maven versions manually at checkin, and then run a script that injects the maven version into a .java file before it is compiled. Yuck. Is there a way I can get this version into the app with my current setup?
This is a fairly common problem. In such an environment, with multiple teams and commits you might want to have more than just a simple version - namely who initiated this build, when and why/how. Take a look here: Job Exporter Plugin. It will output a nicely (Java friendly) formatted properties file that you can easily import into your application in order to get all the details about the job that was responsible for building and deploying that specific version of your app. Well, if you will implement this - there is no "out-of-the-box" mechanism to do so, you can write your own using regular Java APIs.
The other option is to use the Maven's plugins to do the effort for you. As it is a little bit more portable, it's actually harder to implement. One way to do so is to use Maven BuildNumber plugin. It can use timestamps, store build number in a properties files and do a lot of stuff... but it's local as this file should probably not to be committed. The other option is to rely on your repository (SVN, git or other) and get the last revision ID (i.e. with this plugin). It's handy as well, but it's not perfect and easy to read.
I would suggest to go with option 1 - the Jenkins plugin works great and you will get much more handy information. Just remember to read that file with an if-clause, so local builds can rely on something else or you will skip reading the file if it's missing...
Additionally, I have stumbled upon a plugin that does the extraction of your version from the Maven or SBT build process quite nicely - the Semantic Versioning Plugin. This does what is advertised - extracting the version from POM or whatever and including this as a file and a variable in your build process. So you have the freedom to use both, either include the file in your build process and do what you heart wishes AND/OR use the variable to affect the build flow in Jenkins. Now, because this plugin still have couple of bugs I would like to point you for now to my own build of this plugin with fixes already in that can be obtained from here. I will take my own version down the moment that all fixes will be merged to the official plugin...
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.