Introduce subprojects or packages as hierarchical elements in projects

[PaulL]

I just sent a product suggestion to NI and added the same as a comment to an existing topic in the idea exchange:

Idea Exchange Link: Subprojects/Cross project builds

My text:

Introduce subprojects or packages as hierarchical elements in projects

Please introduce the ability to incorporate a project as a subproject or package within another project. This functionality is critical for effective code reuse and maintainability.

As an example of why this is important, I offer the following:

We have created a class ComponentData and a number of associated classes and other files. We neatly package these in a file structure on disk and in virtual folders in a LabVIEW project. [Note that we use virtual folders since in principle, at least, we can use a given class in different ways in different projects.]

Now ComponentData and its associated classes are common classes that we created precisely for reuse between components, each of which we define in its own project. We encounter an issue when we attempt to reuse ComponentData and its associated elements, however.

We can create a project (call it Component.lvproj) and attempt to incorporate this project into a new project for a particular component. This, however, is not useful, since it merely creates a link to Component.lvproj and does not import any of the elements of Component.lvproj into the larger project.

Alternatively, we can copy the virtual folder hierarchy containing ComponentData and its associated classes and other files into the new project. This does explicitly import the elements, but simply copying virtual folders in this manner does not support maintenance needs. While it is true that if we edit the class definition in one project it will update in all callers (each class correctly has a single definition), unfortunately other changes (moving or renaming virtual folders, moving elements between folders, and so on) we make in one project will not reflect in other projects. This approach is wrong in principle as well as in practice because we end up with multiple independent definitions of the same thing. (The definition should exist in only one place.)

What should happen is that we should be able to define a subproject or package and import it into a project, such that:

1) the package elements are now accessible in the larger project (portable)

2) any changes to the subproject or package will appear in all referencing projects (single definition)

3) any part of a particular package may itself become a subpackage itself (hierarchical)

[Note: As I write I realize that using autopopulating folders (which are inappropriate for the reason mentioned above) can satisfy 1 and 2 to some extent but not 3.]

A wonderful example of what I propose exists in a UML design tool we use called Enterprise Architect (and almost certainly within many UML tools). Within a given project we define a hierarchical layer of packages. (In UML each package, like a LabVIEW project, has an XML definition.) At whichever level we choose, we can choose to add a package to version control. (In our case the tool interfaces to the CollabNet client to a Subversion repository. The CollabNet client is open-source, free, and certified, by the way, and is a much better client than the horrible PushOK client currently available for Subversion connections from LabVIEW). When we want to reuse a package in another project, we simply pick the package we want from version control. (We can select a lower-level package if we don’t want the entire hierarchy.) To make sure the package is up to date we simply invoke a command to update the package from the pop-up menu. This works quite well.

Summary: The ability to import subprojects or packages in a hierarchical manner is critical for effective code reuse and maintenance. We consider this a quite essential feature of any project paradigm in any software development environment. The benefits to users (and therefore to NI) are many and the drawbacks are, well, none. Please ensure this becomes a feature of a version of LabVIEW in the very near future.

_____

I am curious to hear what others think.

In particular, I think this functionality is critical and essential, and very definitely belong natively in a LabVIEW project.

I suggest that autopopulating folders are not the solution.

I suggest that the LabVIEW project must support this functionality--natively! (As I write I wonder if VIPM does this. It very well may, but at least the part I am asking for I think obviously belongs in the project itself).

In any case, please comment on the thread at NI Ideas (rather than here)!

Thanks!

Paul