How to make .pkg(dot pkg) downloadable? - macos

I have installed Apache Web server & hosted(or uploaded) a .pkg file on it.
Everything is working on server side. I can see directories browser to get
From the server, i can download zip, txt, doc. etc other files, but i am unable to download .pkg(dot pkg). From the browser, .pkg file is actually looks like a folder.
I have on many servers, e.g., SourceForge.net and i have downloaded this package. Its downloadable.
So, my question is how to make .pkg file directly downloadable.
1. Is it some setting from my Apache server or
2. Need to create pkg of some other type?
Thanks for any help.

It sounds like you're missing the mime type for a pkg file.
You'll need to find the mime type config - on an OSX box I have, it's in /private/etc/apache2/mime.types
Add the line
application/x-newton-compatible-pkg pkg
to that file and restart Apache

Short Answer: yes you need to recreate the package by other way.
In OS X there are 4 main types of packages which you can install/distribute:
.pkg packages
.mpkg packages
.app bundles
.dmg drives
Further more .pkg/.mpkg packages have 2 more types flat and non flat packages.
Flat Packages are single file packages.
Non Flat Packages looks like a folder.
Your problem is that your package is a non Flat package. You can this post to create a Flat package.

Related

Spring Tool Suite download and installation

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/

Use Npackd for plug-in distribution

I've set up a repository to distribute plug-ins using Npackd. I am aware, that I can use a batch script to move all files from a package wherever I want, but I'm afraid I might accidentally overwrite files. Currently, my setup works like this (which is npackd common practice, I believe):
a package myFile.zip gets downloaded
the contents gets extracted to %PROGRAMFILES%\myPackage\myFile
a batch script optionally moves the files elsewhere
Unfortunately, the Npackd documentation doesn't explain the internal process of how this is handled. My first concern is that a folder myPackage already exists and might get overwritten, consequently its files being moved by my Install.bat. Is there a way to define the destination path before the files get extracted? Since I'm installing plug-ins for an existing software, this would avoid my script moving all the files.
One way to achieve could be "abusing" the 7z examples, but if possible I'd like to a avoid the dependency since my plug-ins stored inside a standard zip archive, and Npackd can handle these without dependencies.
Npackd always creates a new directory during the installation of a package version. Normally the name of this directory is the package title (e.g. "Firefox"). If this directory already exists the version number is used as a suffix (e.g. "Firefox-27.0.1"). If this directory is also already there an underscore and a number is used additionally (e.g. "Firefox-27.0.1_2", "Firefox-27.0.1_3", etc.)
There is no way to define where a package should be installed exactly. As you would probably define a dependency on the main software package in each plugin anyway, I'd recommend something like this:
<dependency package="com.mycompany.WordProcessor" versions="[5.00.2195, 6.1)">
<variable>WP</variable>
</dependency>
<file path=".Npackd\Install.bat">copy spellcheck.dll "%WP%\plugins"</file>

Automatic Extension Update: Unknown Archive type

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.

Moodle and SCORM .zip packages

I have a scorm package that works in Moodle. However, if unzip it to a folder and then rezip it and try to use it I get the following in Moodle:
"Incorrect file package - missing imsmanifest.xml or AICC structure"
Note, I'm doing this because I was trying to debug it and drilled down to this simple test:
Start with working scorm .zip package "TestCourse.zip"
On mac os x, I double click to extract it to the current folder.
I cmd click on it and selected decompress which makes "TestCourse2.zip"
I try to use "TestCourse2.zip" on Moodle as a scorm package and get the error above.
I tried using a different program to re-zip the folder and got the same results.
What am I missing here?
It's because you rezip the folder itself. You shouldn't do this. You should go into the folder root and then rezip all the contents to generate a new valid package.
imsmanifest.xml must be in the root of the zip file, not inside any folder (and do not change structure in any other way because the imsmanifest have dependencies with the other files).

How to package JMeter with Jar Bundler on Mac

I'm unable to use "Jar Bundler" on mac to create JMeter.app from ApacheJMeter.jar, I was wondering if anyone else had previous experience with configuring this tool? The problem for me seems to be that the lib folder being searched is set to an incorrect base path:
org.apache.jmeter.NewDriver: JMeter home directory was detected as: /Users/username/Applications/JMeter.app/Contents/Resources
I looked here: http://developer.apple.com/library/mac/#documentation/Java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html
But no matter how I configured any of the said properties, the logs looked the same.
The real trick is making sure the bin and lib folders can be found. The only jar file you will need to add is ApacheJMeter.jar. Look in the bin/jmeter script for additional properties to put into the properties tab of the Jar Bundler. The java arguments in the bin/jmeter script should be copied into the VM Options field. Check Set Working Directory to Inside Application Package. Now create application. Open up the .app folder that was just created and copy the bin and lib folders into the Resources directory. Done.

Resources