LAVA CR Certified - Internal Dependencies

[jgcode]

• OpenG packages can be included in the zip file if they are required dependancies. You can also just list the package dependancies (names with version) in the description. Do not include unpackaged OpenG code.

Dear Mod(s)

Am I able to include OpenG or MGI VIs (renamed) in an llb for distribution along with my source code. Or does "not unpackaged" strictly refer to vip/ogp packages?

For example, if I use VIPM and I want to include packages as internal dependencies is this a violation of the LAVA CR Certification?

Thank you for your time

Regards

JG

[crelf]

Am I able to include OpenG or MGI VIs (renamed) in an llb for distribution along with my source code. Or does "not unpackaged" strictly refer to vip/ogp packages?

If it was in a package when you got it, then (as long as it's license allows) you should distribute it the same way (ie: don't just copy out three VIs from the OpenG array package, include the whole package instead). Not very efficient, but it's generally what the packaged components' license agreements require.

As for "not unpackaged" packages referring strictly to vip and ogp - I'm not sure what you mean. Do you mean VIs that you got from someone else but they didn't come as VIPM-compatible packages? If so, then sure - include them as dependant subVIs (again, if the licensing allows you to). I'm not sure if that's what you're asking - can you please elaborate a bit on what you're trying to do?

For example, if I use VIPM and I want to include packages as internal dependencies is this a violation of the LAVA CR Certification?

Personally, I'd create a vipc with external dependencies for anything that's available naively through the VIPM network (eg: OpenG, public JKISoft packages), and include internal dependencies for those that aren't (this keeps your submission size down, and our servers' HD requirements down, and makes everything available to everyone with an internet connection).

[jgcode]

Hi Crelf

Thank you for replying.

To clarify: I am chasing the definition of the word unpackaged in the context Do not include unpackaged OpenG code in relation to submitting LAVACR Certified code. For a library-type dist, I would definitely do what you are suggesting, but it is for a tool-type dist so I want to know that all the dependencies are definitely included at all times (so my tool will never be broken / and I never had to do any checking on launch aka OGPB APIs). Otherwise it is up the user to have everything correctly installed. I understand your point on server size, but for a small tool-type dist, it will only add a little size for a couple of VIs that I need to include (so server size consideration should not be a big issue in this case, LAVACR rules are).

I understand if I threw some OpenG subVIs in a zip folder with my src than that would be bad for everyone.

But I want to know if I create a dist with (e.g. OpenG) dependent VIs all saved in an llb (and namespaced inside) along with my other support subVIs that this will be ok

I am worried that if it is out of its original package (.vip/ogp) then it is considered unpackaged meaning a llb type dist would not be LAVACR Certified.

Another example is VIPM internal dependencies' are only included if they are linked in the dist (it is not the whole package) and those files (can) get renamed with the namespace as well, and stored in a llb. So that must be covered under the packages license to do this? Would this type of dist be LAVACR certified?

On a side note I must say thanks, as I came across a post of yours a while back that suggested to include a .vipc file list (no physical packages) I didn't know you can do this! It is brilliant way to pass dependencies that are on the VI Package Network (i.e. Open G - so thanks) and keep the file size down. Esp with links to MGI monolithic library and a few large OpenG packages

[Ton Plomp]

Hi Crelf

Thank you for replying.

To clarify: I am chasing the definition of the word unpackaged in the context Do not include unpackaged OpenG code in relation to submitting LAVACR Certified code.

If you look at the Code Capture Tool, you will see that the OpenG VIs are packed inside a support folder where all the files are renamed, this renaming is important and I think this is what Michael means.

On the other side you see that the Code Capture Tool has a dependencie to the oglib_appcontrol library. This is only valid for the OGP file where I use some VIs from the oglib_appcontrol library in the post-install wizard.

Ton

[jgcode]

If you look at the Code Capture Tool, you will see that the OpenG VIs are packed inside a support folder where all the files are renamed, this renaming is important and I think this is what Michael means.

On the other side you see that the Code Capture Tool has a dependencie to the oglib_appcontrol library. This is only valid for the OGP file where I use some VIs from the oglib_appcontrol library in the post-install wizard.

Ton

Thanks for the example Ton.

This is what I want to do, but was unsure of the context of the statement.

Cheers

[crelf]

To clarify: I am chasing the definition of the word unpackaged in the context Do not include unpackaged OpenG code in relation to submitting LAVACR Certified code. For a library-type dist, I would definitely do what you are suggesting, but it is for a tool-type dist... I want to know if I create a dist with (e.g. OpenG) dependent VIs all saved in an llb (and namespaced inside) along with my other support subVIs that this will be ok... I am worried that if it is out of its original package (.vip/ogp) then it is considered unpackaged meaning a llb type dist would not be LAVACR Certified.

Oh - I gotcha. Yeah, I think that creating a distrubution where the reuse components have a different namespace is totally fine. The example you gave is valid IMHO.

On a side note I must say thanks, as I came across a post of yours a while back that suggested to include a .vipc file list (no physical packages) I didn't know you can do this! It is brilliant way to pass dependencies that are on the VI Package Network (i.e. Open G - so thanks) and keep the file size down. Esp with links to MGI monolithic library and a few large OpenG packages

Actually, I think it's one of the most important features of VIPM - we have a repository of packages on a server, so our projects' VIPCs (every project has one, and it's under SCC) all contain external packages. That said, when we need to get project code to customers, we create a VIPC that has all of the packages internal. VIPM is, of course, smart enough to be able to scan the project and only include the packages that are used in it, so our customers don't end up with our whole reuse library - only those packages that the project needs. We sometimes create "external" versions of our packages (we have two repositories: internal and external) - ie: with BDs removed, or crippled in some other way, and VIPM helps us do all of that pretty easily.

[jgcode]

Oh - I gotcha. Yeah, I think that creating a distrubution where the reuse components have a different namespace is totally fine. The example you gave is valid IMHO.

That is great!

Actually, I think it's one of the most important features of VIPM - we have a repository of packages on a server, so our projects' VIPCs (every project has one, and it's under SCC) all contain external packages. That said, when we need to get project code to customers, we create a VIPC that has all of the packages internal. VIPM is, of course, smart enough to be able to scan the project and only include the packages that are used in it, so our customers don't end up with our whole reuse library - only those packages that the project needs. We sometimes create "external" versions of our packages (we have two repositories: internal and external) - ie: with BDs removed, or crippled in some other way, and VIPM helps us do all of that pretty easily.

Thanks Crelf, would you mind going into detail on this as it is something I have had to put thought into recently. We predominately do application releases, but there's probably 10-20% who want to pay extra for the source code.

I guess my question is: What is the best way to provide elements of <your company's> reuse library for clients that purchase source code whilst maximizing the protection of your IP?

What do you mean by two repositories?

Obviously the packages need to be name spaced the same so the code does not need to be relinked?

How is the external packaged versioned wrt the internal package?

One project I would like to do is too look at a tool or build hook that will apply security to the VIs i.e. as you mentioned password protect (API and subVIs), strip icons, labels, hide names on the FP etc.. (subVIs only). I even like the way JKI create a HEX string and rename the subVIs - thats cool.

Are you able to comment on the how your tool works and it's implementation in the release cycle of your source code distribution for a client project?

And details will be greatly appreciated.

Cheers

JG

[Jim Kring]

I guess my question is: What is the best way to provide elements of <your company's> reuse library for clients that purchase source code whilst maximizing the protection of your IP?

What do you mean by two repositories?

Obviously the packages need to be name spaced the same so the code does not need to be relinked?

How is the external packaged versioned wrt the internal package?

One project I would like to do is too look at a tool or build hook that will apply security to the VIs i.e. as you mentioned password protect (API and subVIs), strip icons, labels, hide names on the FP etc.. (subVIs only). I even like the way JKI create a HEX string and rename the subVIs - thats cool.

Are you able to comment on the how your tool works and it's implementation in the release cycle of your source code distribution for a client project?

And details will be greatly appreciated.

Cheers

JG

Hey Jon,

I'll ping you off-line to talk with you a little bit about how JKI handles this. We may eventually offer some features in VIPM Professional that address this use case. As you've mentioned, we have technology that we use in-house to do this.

Thanks,

-Jim

[jgcode]

Hey Jon,

I'll ping you off-line to talk with you a little bit about how JKI handles this. We may eventually offer some features in VIPM Professional that address this use case. As you've mentioned, we have technology that we use in-house to do this.

Thanks,

-Jim

You are too kind!

Cheers

JG