jgcode Posted September 2, 2011 Report Share Posted September 2, 2011 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. Requirements Installation Type 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 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 Palettes: <vi.lib>\LAVA<\package_name> Tools: <project>\LAVA\<package_name> Examples VIs: <examples>\LAVA\<package_name> Examples .bin3 files: <examples>\exbins Addons#: <vi.lib>\addons\_LAVA\<package_name> # 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 E.g. lava_lib_my_package-1.0.0.1.vip 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 VI Namespacing 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 Palette Location 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 Dependencies 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) Coding Standards 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 Recommendations Iconography 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! License 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) Premium Membership 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 Folder Naming Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space E.g. <LabVIEW>\vi.lib\LAVA\my_package Click here to view the article Quote Link to comment
Ton Plomp Posted September 2, 2011 Report Share Posted September 2, 2011 (Thumbs up for the extensive document). How would this work for legacy packages? One of the requirements is that you have a 'lava-compliant'-namespace. That's quite hard for the Code Capture Tool with an allready existing API. Ton 1 Quote Link to comment
jgcode Posted September 2, 2011 Author Report Share Posted September 2, 2011 (Thumbs up for the extensive document). How would this work for legacy packages? One of the requirements is that you have a 'lava-compliant'-namespace. That's quite hard for the Code Capture Tool with an allready existing API. Ton I am sure we can work this out - I would love to see CCT on LVTN thru LAVA With flexibility mind - can you conform to everything else bar VI namespacing? If namespacing was maintained, but was in a LAVA version you 'may' have some relinking to the new folder location but LabVIEW 'may' handle this automatically (like I tested for OpenG -in the moving to vi.lib? thread). Can you test it and report back? With the LAVA package name, you can just have a conflict with the current CCT version so it uninstalls automatically. Thoughts? Quote Link to comment
Ton Plomp Posted September 3, 2011 Report Share Posted September 3, 2011 My short test shows that it indeed works, the only requirement to the user is that they have vi.lib\_lava in their search path (or just vi.lib). Ton Quote Link to comment
jgcode Posted September 28, 2011 Author Report Share Posted September 28, 2011 I have updated the LAVA requirements to include changes to the palette location and .bin3 location. These changes are to be inline with Compatible with LabVIEW (LabVIEW 2011) requirements. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.