Sep 02 2011 12:55 PM | jgcode in LAVA Code on LabVIEW Tools Network
This Article outlines the Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network. My Package is used as an example in throughout this Article.
Code must be distributed as a package (.vip or .ogp). This will mean it is compatible with both the LabVIEW Tools Network and VIPM
Installation directories have been standardized for the purpose of organisation and avoiding namespace clashes etc.
No package released on LAVA, in the LAVA-CR or elsewhere should install to these locations - only those packages that are approved by LAVA for the LabVIEW Tools Network
Once your package has been accepted, you will own that namespace and can install to other locations (if haven't already) in the future (think of it like a domain) without worry of collisions
Examples VIs: <examples>\LAVA\<package_name>
Examples .bin3 files: <examples>\exbins
# Not for distributions that contain public VIs (i.e. VIs appear in palette or need to be linked to by end users)
Package and Palette Namespacing
Example package names will be lava_<type>_<my_package>-<version>
Where type = lib for Libraries and type=rsc for Resouces/Tools
In VIPM the package name is directly related to the palette name
We require packages to be ordered alphabetically in the dynamic palette hence, the above convention must be followed
Additionally, if using OpenG Package Builder, palette name must match the equivalent VIPM name
It is recommended that VIs should be namespaced similar to old school VIPM renaming syntax (e.g. __lava_lib_<package_name> however, at a minimum __lava should be used
If a LabVIEW Project Library is used to namespace code instead, then add __lava namespace to the distributed library
Both .ogp and .vip packages that contain palette VIs will link to the LAVA Palette package as a dependency which is published on the LabVIEW Tools Network.
The palette must appear under the Addons\LAVA top level palette however, users may wish to include another palette under the correct programming sub-palette.
The VIPM Custom Category feature is currently not used
Any package dependencies must be also published on the LabVIEW Tools Network (aka external dependencies). Packages (especially Tools) should try to limit all dependencies by building in supporting VIs to the package (aka internal dependencies)
The code distributed must meet the requirements of being LAVA Certified. Additionally you should follow the LabVIEW Development Guidelines and the standards for the Compatible with LabVIEW level that you ultimately want to achieve
We recommend you use any color, glyphs, text etc... for your icons. There is no set theme or icons - we don't want to stifle your creativity!
We recommend that you distribute under the most flexible license to aid in end user reuse (e.g. new-BSD license), but there is no licensing requirement - only that you have one
It is recommended that this license is Open Source Initiative approved
Adding a License Agreement file is also recommended (but this requires VIPM Professional)
It would be helpful if members maintained Premium Member status so they can edit and delete posts etc... to maintain their forum professionally
However, if not, we will open up this functionality for Team LAVA Developers
Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space
Oct 25 2011 11:40 PM | jgcode in LAVA Code on LabVIEW Tools Network
This article is a guide on how to build a package in VIPM to meet the requirements of publishing under LAVA on the LabVIEW Tools Network.
You can build packages in VIPM Community Edition (which is free). Alternatively you can use OpenG Package Builder - whatever is preferred.
This guide is aimed to help developers new to package building and for everyone to see what the requirements look like in VIPM and is presented as a walk-through of each screen in the VI Package Builder UI.
An example package named LAVA Test Package is used for all screenshots:
LAVA Test Package is available for download here:
lava_lib_lava_test_package-126.96.36.199.vip 8.8K 189 downloads
(Code is in LabVIEW 2009).
LAVA Palette (external dependency) is avialable for automatic download in VIPM (hosted on LabVIEW Tools Network).
Set the build information for your package here.
Set the Company Name to LAVA; Legal Copyright and Author Name should be your own; Set the License Agreement name (a flexible license is preferred and should be Open Source Initiative approved).
Setting the License Agreement Text File Location requires VIPM Professional, so it is recommended to use only if you have it.
Set the Product Homepage (URL) to the LAVA-CR page of the package (as this is just an example package it cannot be done here) - every package published will have its own LAVA-CR page e.g. Rename LVOOP Labels.
Do not include a Custom Category, this functionality will be provided in a dependent package (see Package Dependencies).
Set the palette Installation Location to Addons\LAVA (minimum requirement).
You can also include as many other palettes as you like that make sense for your package.
Note: You must have installed the LAVA Palette package first to be able to see and select the LAVA sub-palette in the Palettes in LabVIEW dialog.
The LAVA installation directory for palette VIs is <vi.lib>\LAVA. Create a sub-folder for your package. The folder structure under this sub-folder is entirely up to you.
Source File Settings
Namespace your code to be distributed. In this example VIPM old school namespacing is used.
At a minimum, namespacing should reference lava.
Note: If you are importing an existing API over from the LAVA-CR then keeping the existing namespacing for VIs can be considered via discussion).
List all external package dependencies here. All external package dependencies must be avialable for automatic download from the internet in VIPM (e.g. hosted on VI Package Network or LabVIEW Tools Network).
Tool distributions should minimize external dependencies.
When the user of your package downloads and installs it, VIPM will automatically install the dependencies if they are not already installed, for example:
Licensing & Activation
Currently not used.
Set the installation requirements for your package.
If you are converting an existing package (which will have a different name) for publishing under LAVA then that package should added as an incompatible package so that VIPM will uninstall it automatically to avoid any conflicts when the new LAVA package is installed.
Set these if needed.
The package name should be as per the requirements. This is important as the palettes files generated by VIPM use this name and therefore, by following this convention the LAVA Addons palette will be ordered alphabetically.
Once your package is built and installed it will appear in LabVIEW as follows: