Jump to content

[Article]Requirements and Recommendations


jgcode

Recommended Posts

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

Link to comment

(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?

Link to comment
  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.