I export an eclipse RCP application (defined in a .product file) as an archive. But when I try to extract it using windows 7 build in extract tool I just get:
corrupted archive
I can extract the archive using 7zip though. Why can windows7 not open the archive created by eclipse?
Not sure, but I think I have seen this too.
Then it turned out to be an entry for the directory/folder that caused the trouble - i.e an entry on the form plugin/. The last slash was not accepted.
Related
Please note: I have created this GitHub project right here that can be used to perfectly reproduce the problem I'm seeing.
Java 8 here attempting to use Launch4J via the gradle-launch4j Gradle plugin to build a Windows native EXE application. I am doing the development of a Java Swing app on my Mac but the app must run as a Windows EXE on Windows 10. I am also using ShadowJar to build my self-contained "fat jar".
I can build my (Swing) app's fat jar and then run it on my Mac via java -jar build/lib/myapp.jar. It starts and runs no problem.
Here is my Gradle config for Launch4J:
launch4j {
mainClassName = 'com.example.windows.hello.HelloWindowsApp'
icon = "${projectDir}/icon.ico"
jdkPreference = 'jdkOnly'
initialHeapSize = 128
jreMinVersion = '1.8.0'
jreMaxVersion = '1.8.9'
maxHeapSize = 512
stayAlive = false
bundledJre64Bit = true
bundledJrePath = '../hello-windows/jre8'
}
When I run ./gradle clean build shadowJar createExe createDistro it produces:
hello-windows.zip/
hello-windows.exe --> The Windows EXE built by the 'createExe' task
lib/* --> The lib/ dir for the EXE that is also built by the `createExe` task
jre8/ --> OpenJDK JRE8 (copied from the libs/jre8 dir)
So I copy that ZIP file and port it over to a Windows 10 (64-bit) machine. I extract the ZIP and run the EXE by double clicking it inside Windows Explorer (which I can confirm does see the EXE as an Application type). First I see this:
Why is this happening? Are there any Launch4J configurations/settings I can change so that this doesn't happen?
Thanks in advance!
You need to sign the executable created by launch4j as described here to prevent SmartScreen from blocking it to be run. See also the related discussion in the support forum.
Your first question is more like a Windows question. When you unzip an application from a zip file, Windows will naturally mark it as unsafe, in fact if you check the application properties tab, you will see a checkbox where you can remove that unsafe attribute. It's same as running chmod+x for an executable script in Linux.
For the second part, I assume you are using the gradle plugin for Launch4j, there are two main ways to configure Launch4j assuming your project folder is structured commonly with the jre library in the same folder containing your executable folder.
By specifying the path only like
../jre
By specifying the full relative path
../jre/bin/javaw.exe
Your generated xml at the end should look like this in the first case.
<jre>
<path>../jre</path>
</jre>
The main point is that the path to JRE is relative to the position of the executable not the current directory. In this case, we step back one directory from the executable folder to the folder containing jre.
Try setting the bundledJrePath in your build.gradle to just jre8:
launch4j {
...
bundledJrePath = 'jre8'
}
Because that is in your case the relative path where the jre is when extracting the zip.
http://launch4j.sourceforge.net/docs.html
<path>, <minVersion>, <maxVersion>
The <path> property is used to specify the absolute or relative path (to the executable) of a bundled JRE, it does not rely on the current directory or <chdir>. Note that this path is not checked until the actual application execution
Beware that the path must not contain the /bin/javaw.exe.
When running the exe with the debug flag like this
hello-windows.exe --l4j-debug
then it will create a file launch4j.log in the same directory.
There you can check that the correct jre is picked up, for example:
...
Bundled JRE: jre8
Check launcher: C:\Users\IEUser\Downloads\hello-windows\jre8\bin\javaw.exe (OK)
...
I upvoted the answer above from sschuberth, as that is the best answer to your question. Signing the executable will make SmartScreen happy.
As addition I would rather prevent trying to create an executable, even signing it, best to create a MSI. For example by using Javapackager. See also this question. That guy created his own tool after using Nullsoft.
It is very cumbersome to get an executable accepted by every virus scanner around the world. I have the experience of using WIX Toolset to create an MSI and wrapped it into a bootstrapper executable, signed it using the company signing certificate. However in the end I had to send requests to McAfee, Norton, Avast, AVG, KasperSky and Trend Micro. Gladly all accepted it over time, only Trend Micro never even responded.
I work on an existing Maven project with Eclipse Luna and WebSphere 8.5.5.1.
The source of the ibm-application-bnd.xml is:
D:\projects\svn\application\ear\src\main\application\META-INF\ibm-application-bnd.xml
Once a day, at a random moment, the application folder itself is overwritten with the ear-file, so the \main folder contains a binary file named application and is actually the ear file because I openend the file because I saw it had the same size as the ear (8 MB).:
D:\projects\svn\application\ear\src\main\application
The happens at least once a day, and I have the impression that Eclipse, or JRebel of WebSphere creates this file.
The result is that I have to quit Eclipse, delete the file and update from SVN to get the application folder with the binding xml back.
Any thought how to fix this?
Easy way you could stop the folder from being deleted (and perhaps also find the culprit) is to open command prompt in that directory - it won't allow the folder to be removed in that case.
I've downloaded spring-tool-suite-3.6.1.RELEASE-e4.4-win32-x86_64.zip and getting the following error while trying to unzip and install:
Error 0x80010135: Path too long
POM.properties
Type PROPERTIES File
Date Modified 6/11/2014 12:47PM
Size 146 bytes.
What may be the reason?
Possible solutions:
Rename spring-tool-suite-3.6.1.RELEASE-e4.4-win32-x86_64.zip to springts.zip
Move spring-tool-suite-3.6.1.RELEASE-e4.4-win32-x86_64.zip to C:/ or in another location that is not very deep.
Change your extractor to 7-zip.
Try with any alternative for zip such as 7Zip or WinRAR. 7Zip worked for me
This happens because of the zip file name being too long.You can rename the downloaded zip file to something like STS.zip (Give a short name) and then try to extract it.The error should now disappear.
When you extract, it will try to extract in a folder named "spring-tool-suite-3.6.1.RELEASE-e4.4-win32-x86_64" which is too long for a folder name. Simple rule of thumb -- install to C:\ and rename the above to STS361_x8664. Be very frugal with folder names.
This happens because the file name & path are too long.
Rename them to something smaller and simpler.
Here is the link that I found helpful
Step 1: Download STS zip file from spring official website
Step 2: After downloading Spring Tool Suite zip file then extract that then Open STS directory file click on STS icon below like this.
Step 3: Run that file then Select a directory as a workspace and browse your directory.
Here is complete installations of STS on Windows operating system.
Source : http://commandstech.com/how-to-install-springtoolsuitests-with-scala-on-windows-7-8-10/
I have created a new version of my Joomla extension.
Manual upgrade via zip file or the directory works fine.
But the automatic upgrade (which used to work fine before), now gives an error 500 and the following error messages: "Unknown Archive type", "*Update path does not exist" and "Installation unexpectedly terminated: Update path does not exist".
I have no idea why those messages appear.
The update.xml references the correct zip files. Downloading it manually works just fine.
Joomla(/php/apache) has all rights on the folder containing the joomla installation.
After trying the automatic update, the tmp folder contains the downloaded zip archive with the latest extension version, interestingly without the .zip extension. Is the Joomla downloader not correctly naming the file and then failing upon finding that the file doesn't have a .zip extension?`Or what could it be?
Would be very thankful for any ideas...
Edit: My project is hosted on github, and github seems to automatically create a subfolder in the downloaded zip archive, named -.zip.
I'm using a link to the tagged github zip directly in my update.xml
I'm not sure if github always added this folder in the zip file, back when it still worked for me...
Might the Joomla problem have to do with the zip file containng such a folder, and not directly the extension stuff at root level? If so, anybody know if/how I can change github to not create that subfolder?
Right, just had a quick test of this.
I couldn't seem to find out how to automatically zip up a sub folder (there is a way but I need to do some more research/ask questions regarding this), however what you can do is the following:
Create a zip of your Repo
Open the zip, extract the folder you wish to be zipped then zip it
Create a new version and then drag your zip file into the upload box
Publish the release
Here is an example, have a look at the "Creating Releases" sections at the bottom:
https://github.com/blog/1547-release-your-software
Hope this helps
To answer my own question:
Yes, github seems to have recently changed their policy to create a root folder in the zip file, named as the repository the zip file is downloaded for (stupid, if you ask me, since the exact same information is encoded in the zip file name already anyway!).
Edit and Rewrite: It seems that either something changed in Joomla or that if you adhere to a naming convention - namely the root folder in the zip file having the exact extension name (or, I think and have to test, actually the same as the file name, without the version information), then the automatic update will work.
So as in my case, I have a Joomla package; the package is now in a repository pkg_mypkg. The zip file generated by github has the name pkg_mypkg-version.zip (e.g. pkg_myfancyext-1.0.9.zip), and contains a folder named pkg_mypkg. And inside the pkg_mypkg folder is a pkg_mypkg.xml file, the extension manifest. And this actually seems to be the configuration where automatic update works.
I'm using SharpCompress to unzip a 7zip archive. The IArchive created by ArchiveFactory.Open returns an IEnumerable<IArchiveEntry>, but IArchiveEntry contains nothing indicating if an entry is an anti-item.
Is there a way to recognize anti-items?
I added this to the project's issue tracker.
http://sharpcompress.codeplex.com/workitem/33