I'm making a JApplet and need to make a JAR file to connect to a .htm file with the applet tag. The simple solution I could think of was to use the tool in drjava that says "Create Jar File From Project..." but alas, it's not highlighted for some reason, so I can't do that. What I'm really looking for is either (a) an explanation as to why drjava can't turn my classes into a jar file, (b) an alternative to allow me to create this jar file, or ideally (c) both. Thanks for your help ahead of time.
I don't use Drjava, but here is how you can create a JAR file from the command line without any IDE specific complications.
Simply go to the folder/directory where your project is located. Let's say your class files are located in the bin folder. You can then use
jar cvf myapplet.jar -C bin .
The JAR is then ready to be deployed.
Related
trying to archive all the files into a zip file that is formed in the workspace in jenkins pipeline script. I tried using this
archiveArtifacts 'C:\Program Files (x86)\Jenkins\jobs\pipeline CI_MS\workspace'
but error was shown as "file not found"
Thanks for any help
Do you really want to archive everything in the entire workspace? Hardcoding the path like that is a bad idea. The workspace moves, and if you are using a more recent version of Jenkins (that wasn't upgraded from an old version), you are probably not even looking in the right space.
Use this:
archiveArtifacts "${WORKSPACE}"
Add to the end of the path if you want to archive files in subdirectories.
I have the following files which I would like to upload to Artifactory as a 9.8.0 versioned artifact.
NOTE: The first two files DO NOT have an extension (they are executable files i.e. if you open them/cat on it, you'll see junk characters).
Folder/files of a given version 9.8.0 in CVS is like:
com.company.project/gigaproject/v9.8.0/linux/gigainstall
com.company.project/gigaproject/v9.8.0/solaris/gigainstall
com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe
com.company.project/gigaproject/v9.8.0/gigafile.dtd
com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd
com.company.project/gigaproject/v9.8.0/giga.jar
com.company.project/gigaproject/v9.8.0/giga.war
Uploading the above files which have an extension is very easy... You log in to Artifactory as an administrator/user which has access to deploy artifacts, click on "Deploy" tab, browse for the Artifactory file and once you select the file, click on "Upload" button.
Next you'll see a screen (like shown above). You'll tweak what you want in the fields on this page and once you click on "Deploy Artifact", you are done. All you have to make sure is you select the correct file.extension file while uploading and make sure the file extension is shown in the "Target Path" box correctly (with the version -x.x.x, etc.).
My questions:
Question 1: How do I upload an artifact which doesn't have an extension? It seems like Artifactory by default takes an artifact as a .jar extension. How can I upload the "gigainstall" artifact as shown in the folder/file structure above for both Linux and Solaris? I see I can use the artifact name as gigainstall-linux and gigainstall-solaris and differentiate it, but I am not sure how to tell Artifactory that this artifact doesn't have any extension.
I don't think the development team will start generating this artifact with a proper extension (as this artifact may be hard coded everywhere in other projects where they are currently getting it from CVS/SVN source control somewhere - which is itself a bad practice to store an artifact in a source control version tool).
Question 2: How would I tell a build system (for example, Gradle) to consume a non-extensioned artifact during, let's say, 'compile' task. In build.gradle under section dependencies { .. }, I will add something like as shown below, but I am not sure for non-extensioned files (the first two in the folder/file structure I mentioned above).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0#'
//compile 'com.company.project:gigainstall-linux:9.8.0#??????'
//compile 'com.company.project:gigainstall-linux:9.8.0#""'
//compile 'com.company.project:gigainstall-linux:9.8.0#"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0#"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0#war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0#dtd'
compile 'com.company.project:gigaanotherfile:9.8.0#dtd'
}
Answer 1 (will cover 2 as well in a different sense): Using Artifactory "Artifact Bundle" feature section under "Deploy" tab can do the TRICK for AT LEAST uploading the artifacts in a way we want, by creating a zip file first (containing the structure and artifacts in it) --OR you can upload the artifacts using/calling Artifactory REST API way.
High level idea:
Create a zip file called gigaproject.zip OR anyname.zip/.tar/compressed file which Artifactory can read. Inside the zip, create the structure - how these artifacts will be loaded to Artifactory
i.e.
gigaproject.zip will contain the following folders/structure/files.
Case 1:
com/company/project/gigaproject/9.8.0/linux/gigainstall
com/company/project/gigaproject/9.8.0/solaris/gigainstall
com/company/project/gigaproject/9.8.0/win32/gigainstall.exe
com/company/project/gigaproject/9.8.0/gigafile.dtd
com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd
com/company/project/gigaproject/9.8.0/giga.jar
com/company/project/gigaproject/9.8.0/giga.war
NOTE: In case 1 example, I didn't use any -x.x.x in the filename (i.e. I'm using plain and simple giga.jar instead of giga-9.8.0.jar).
The above Upload/Deploy will result the files (as shown in the following snapshot):
So, we have achieved what we wanted. Actually (visibly speaking yes), but not in a way Artifactory usually stores these artifacts (as they should -x.x.x version embedded in the file name and where artifact id should match the artifact filename). Now, if you want to consume the following in a Gradle build file, you CANNOT as first, you haven't uploaded the filename with -x.x.x version name in it, secondly, the artifact id in our case 1 tree was "gigaproject" (after com/company/project folder), so Gradle way of defining what artifact id and what artifact file name you want won't work.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
Conclusion: It's possible to upload any files (with/without extension in Artifactory) in any structure but it depends how your build system will consume it or will be able to consume it or not.
- I deleted the structure I just created with case 1 .zip file from Artifactory repository to try next case#2 and deleted the .zip file I created.
Case 2:
Let's create an individual versioned file name for each artifact and also create structure in the format - how Artifactory actually stores them (an artifact as seen in a repository in a tree view) and create a .zip file containing that structure. Let's use the same "Artifact Bundle" feature to upload this .zip file to upload individual artifacts that we need in Artifactory - where artifact-id (second value which we mention while trying to consume it) would match the artifactfile name in Artifactory.
Folder/file structure for the .zip file:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe
com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd
com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd
com/company/project/giga/9.8.0/giga-9.8.0.jar
com/company/project/giga/9.8.0/giga-9.8.0.war
NOTE: This time, we'll be using the same "Artifact Bundle" feature and for similar files (gigainstall under both Linux/Solaris folders), I took the approach of creating gigainstall folder (containing gigainstall-9.8.0.linux and gigainstall-9.8.0.solaris file names) i.e. when we'll consume these artifacts in Gradle under dependencies { ... } section for compile, we'll use x.x.x# way to fetch these artifacts from Artifactory.
OK, once "Artifact Bundle" Deploy/Upload was successfully complete, I got the following message.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Now, let's see how it looks like in Artifactory while searching for one of the artifact/in Tree view. You can see we have the files now in place, with filename-x.x.x.extension way so that I can consume them easily in Gradle.
In Gradle build file (build.gradle), I'll mention:
dependencies {
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:gigainstall:9.8.0#solaris"
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:giga:9.8.0
compile "com.company.project:giga:9.8.0#war
compile "com.company.project:gigafile:9.8.0#dtd
compile "com.company.project:gigaanotherfile:9.8.0#dtd
}
OH OH!! - That didn't work, see below for Gradle error. Why? - Artifactory Bundle upload/deploy feature uploads a zip file content what you have in the .zip but it DOES NOT create a .pom file per artifact it deploys. Thus, making the Gradle build to fail. May be in Ant this might succeed. This occurred for each individual .jar/.war/.dtd/etc file. I'm just showing one error example.
While doing gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
Case 3: Let's take a simple approach (workaround but will save a lot of pain).
Create gigaproject.zip file with the following structure, this approach takes - No x.x.x version value embedded in the individual artifact/filename in the folder/file structure. We will use "Single Artifact" approach (which will create the .pom for gigaproject.zip file automatically during the upload/deploy process provided by Artifactory). You'll still be able to get gigainstall file without needing any extension to its name using this approach. During the upload/deploy step, as you already have seen, you upload gigaproject.zip and artifactory will upload it to a given Target Repository as "gigaproject-x.x.x.zip" where x.x.x is 9.8.0 in our case. See the image snapshot below.
gigaproject/linux/gigainstall
gigaproject/solaris/gigainstall
gigaproject/win32/gigainstall.exe
gigaproject/gigafile.dtd
gigaproject/gigaanotherfile.dtd
gigaproject/gigaproject.zip
gigaproject/giga.jar
gigaproject/giga.war
Now, upload it in Artifactory using "Single Artifact" feature. Click "Deploy Artifact" once you tweak the values for GroupId, ArtifactId, Version, etc.
Once this is uploaded. You'll see in the zip artifact in the target repository (I took a bad example, usually this would be libs-snapshot-local or libs-release-local instead of ext-...), you'll be able to consume the ZIP artifact directly in Graddle:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0#zip"
}
Once the .zip is available to Gradle build system, now you can tell Gradle to unpack this .zip file somewhere in your build/workspace area where you can feed the actual(unpacked) files (gigainstall, .dtd, .jar, .war, etc.) to the build process/steps.
PS: Case# 1 and 2 would have worked for Ant I guess.
Answer 2:
If you have uploaded a non-extensioned file in either way. Make sure you have manually created/uploaded its POM file as well (i.e. if I uploaded gigainstall-9.8.0 as an artifact under com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, then at the same level, I have to/should create it's POM file (see a simple template .pom file for a custom jar artifact or while uploading an extensioned file via "Single Artifact" deploy, you'll see what POM Editor window shows you) and upload both so that Gradle won't error out saying no POM conflict/error. Ant might not need pom (I didn't check that).
Once it's there in Artifactory, the following line should work -- OR comment please if you find another way.
dependencies {
// See nothing mentioned after - x.x.x#
compile "com.company.package:gigainstall:9.8.0#"
}
I'm here again with another case that is getting me out my mind.
So, this is happening, I'm trying to run an executable java class(.jar) as a Windows Service, and all my attempts failed so far. To make it a little easier, I turned my jar into a batch file, wich only executes the jar in background, here is the code:
start "" javaw -jar C:\LocalService.jar
The batch works fine. However I have tried to install this batch as a service by using the next line in cmd:
sc create "LocalService" binPath= "C:\LocalService.bat"
The Service installs correctly, but as soon as I try to start it, it pops up an error (The code error is 1053, says something about the service did not start correctly)
Also, I have try with a software called NSSM (non-sucking service manager) It installs fine too, but the service does not start either.
Do you guys know what am I missing?
By the way, I'm doing all this on Windows 7 Professional.
Thanks!
thanks for your comments
Both tools didnt work for me, sadly. However I was able to do it with a software called Java Service Wrapper. This is not a free software, so I needed to buy a license to get it to work.
The steps were simple:
1.-Create a folder with the name of the service, then inside add 4 folders: lib,bin,logs,conf
2.-On the lib folder you have to copy your jar and also the wrapper.jar and wrapper.dll (these last two are in the zip you download from the website)
3.-Copy 4 files to the bin folder: InstallApp-NT.bat.in, App.bat.in, UnintstallApp-NT.bat.in and wrapper.exe (this last one is the one that defines your license, if you can get a file wrapper.exe from somebody else who had paid a license it will work fine. These file also came in the zip from the website) Remove the .in from the batch files
4.-The most tricky step is this: You have to copy from the wrapper's folder called conf a file called wrapper.conf.in Remove the .in extension and edit it with a tex editor. The most important lines you have to edit are:
wrapper.java.command=C:\Program Files (x86)\Java\jre7\bin\java //Specify JRE Path. Will work with eviroment variable
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperJarApp //Choosing this class means your are using a .jar file to execute when the service starts
wrapper.java.classpath.1=C:\LocalService\lib\wrapper.jar //This one is constant.
wrapper.java.classpath.2=C:\LocalService\lib\LocalService.jar //This is the path to your executable jar
wrapper.java.library.path.1=C:\LocalService\lib //Path to your own lib folder (the you created at the begining)
wrapper.app.parameter.1=C:\LocalService\lib\LocalService.jar // again the path to your jar
Then just execute the InstallApp-NT.bat and start the service and your are done
It worked to me with absolute paths, however according to documentation it will work fine with relative path too.
This is how I solved my problem and I hope someone with the same issue will find this helpful
See you next time!
I have this error message:
Preparing to deploy: Created staging directory at:
'C:\Users\leet\AppData\Local\Temp\appcfg4768292050846213939.tmp'
Scanning for jsp files. Compiling jsp files. Scanning files on
local disk. java.io.IOException: Jar
C:\Users\leet\AppData\Local\Temp\appcfg4768292050846213939.tmp\WEB-INF\lib\appengine-api-1.0-sdk-1.7.7.jar
is too large. Consider using --enable_jar_splitting.
I issued the command like this, but it does not work with --enable_jar_splitting.
"C:\Program Files\Java\jdk1.7.0_17\bin\java.exe" -Xmx1100m -cp
"%~dp0..\lib\appengine-tools-api.jar"
com.google.appengine.tools.admin.AppCfg --enable_jar_splitting -e
user#domain.com update "C:\myfolder\myproject\war"
Any comment?
The Java App Engine 1.7.7.1 SDK has been released to address this windows specific issue.
The Google Eclipse plugin has been updated, as well as the Google App Engine Maven artifacts and plugin (just use the 1.7.7.1 version).
to solve the library error message, you have to do this:
1) open your windows explorer and locate it to your eclipse folder. e.g. ".\eclipse\plugins\com.google.appengine.eclipse.sdkbundle_1.7.7\appengine-java-sdk-1.7.7\lib\user".
2) you will then see a file called "appengine-api-1.0-sdk-1.7.7.jar", rename it to "appengine-api-1.0-sdk-1.7.7.original". (just don't delete as you need in future)
3) copy that 2 files you created earlier - "appengine-api-1.0-sdk-1.7.7-1.jar" and "appengine-api-1.0-sdk-1.7.7-2.jar" and paste into this folder.
4) switch it eclipse ide, clean the project and rebuild it. then, the error message will go away.
i solved the issue by splitting the "appengine-api-1.0-sdk-1.7.7.jar" file my own.
in case anyone else want to know how to do that, follow these steps
1) unzip "appengine-api-1.0-sdk-1.7.7.jar" file from 7z.
2) balance them into 2 folders (each about 15mb) regardless any structure.
3) name the first folder as "appengine-api-1.0-sdk-1.7.7-1" and second folder as "appengine-api-1.0-sdk-1.7.7-2".
4) make sure you have jdk installed. e.g. "C:\Program Files\Java\jdk1.7.0_17\bin". set it to environment so you can run the file from that bin folder.
5) IMPORTANT: you must go into that first "appengine-api-1.0-sdk-1.7.7-1" folder and not at the parent folder of those folders.
6) launch cmd.exe and type "jar cf appengine-api-1.0-sdk-1.7.7-1.jar *" for the first archive.
7) do it again the same for the second archive (repeat step 5 and step 6).
8) go to \war\web-inf\libs folder, delete the existing appengine-api-1.0-sdk-1.7.7.jar.
9) copy and paste the appengine-api-1.0-sdk-1.7.7-1.jar and appengine-api-1.0-sdk-1.7.7-2.jar into \war\web-inf\libs folder.
10) now deploy it. it should work like charms!
EDIT:
Spelling correction.
Using that instruction :
To clarify, we're going to release a minor update for 1.7.7. For the
meantime, you can re-jar the file as follows:
cd to the working directory
$ jar xf somewhere\appengine-java-sdk-1.7.7\lib\user\
appengine-api-1.0-sdk-1.7.7.**jar
$ jar cfm somewhere\appengine-api-1.0-sdk-1.7.7.**jar META-INF/MANIFEST.MF *
and replace the old jar with the newly created one.
from http://www.mail-archive.com/google-appengine#googlegroups.com/msg67954.html
and the messages from the solutions here, I was able to make it work like this :
Open a command line and go into the bin directory of your JAVA installation where the jar.exe file is
cd "C:\Program Files\Java\jdk1.7.0_17\bin\"
Then, you need to find the file "appengine-api-1.0-sdk-1.7.7.jar" somewhere on your computer. It's at 2 places (not counting the temp directories), in the \war\WEB-INF\lib folder in your eclipse project and also in the "plugins" folder of your eclipse installation. Precisely there : \plugins\com.google.appengine.eclipse.sdkbundle_1.7.7\appengine-java-sdk-1.7.7\lib\
You just need one of those 2 paths.
Now in the command line, just type :
jar xf "C:\whatever-folder-your-eclipse-is-in\plugins\com.google.appengine.eclipse.sdkbundle_1.7.7\appengine-java-sdk-1.7.7\lib\user\appengine-api-1.0-sdk-1.7.7.jar"
and then
jar cfm "C:\whatever-folder-your-eclipse-is-in\plugins\com.google.appengine.eclipse.sdkbundle_1.7.7\appengine-java-sdk-1.7.7\lib\user\appengine-api-1.0-sdk-1.7.7.jar" META-INF/MANIFEST.MF
Now, if you go to that folder and check the .jar file, it should now be 11 mb instead of 30 something. Now you need to copy this one and replace the same jar in your webapp folder in \war\WEB-INF\lib\ so that both jars named "appengine-api-1.0-sdk-1.7.7.jar" have a 11 mb size.
Now the error should be gone and you don't have to split anything.
I use JDIC in my executable Jar file, when it runs, it needs to have IeEmbed.exe and MozEmbed.exe in the same dir as the Jar file, I wonder if there is a way to package all 3 files into a single executable Jar file, so when I distribute the app, there is only one executable Jar file to worry about, besides, there are problems sending and downloading *.exe files, what's the solution ?
For instance, my executable Jar file is called Java_App.jar, how to get <1>IeEmbed.exe <2>MozEmbed.exe and <3>Java_App.jar into a Jar file called : My_App.jar, and when user double clicks on My_App.jar, it will run the Java_App.jar and find the needed IeEmbed.exe and MozEmbed.exe files from inside the My_App.jar package without unpacking and save them into a local dir.
There is no problem packaging them together per se. The jar file is finally a .zip file.
The problem will come when your app try to load it because it won't be able to find the .exe in the system path.
The solution is to make an installable file ( which can be a .zip file ) and expand and copy the .exe file for you for instance in a "bin" directory