Dependency Management in VS Code

[gquerret]

Why?

Modern development ecosystems (Java, JavaScript, Python, etc.) rely heavily on dependency management, yet this practice is largely absent in OpenEdge ABL development. This creates significant challenges as OpenEdge code reuse typically relies on copy-pasting source files between projects, network shares with common code, manual .pl library management without clear versioning, and complex PROPATH configurations that are hard to maintain.

Using dependencies would have a direct impact on:

• Developers: Simple installation, automatic updates
• CI/CD: Reproducible builds, no fragile network dependencies
• Architecture: Encourages modularity and separation of concerns
• Maintenance: Controlled updates with easy rollback
• Security: Complete traceability of all dependencies

Proposed solution

The Language Server will rely on the Maven standard for dependencies for several reasons:

• Wide variety of enterprise-ready tools (Nexus, Artifactory, GitHub Packages, ...)
• Already a standard in the Java ecosystem (and the LS is written in Java)
• Support for classifications (one artifact can have multiple variations)

Dependencies are declared in the standard openedge-project.json configuration file, next to buildPath entries.

• Without dependency management:

  "buildPath": [
    { "type": "source", "path": "src/main/abl" },
    { "type": "source", "path": "src/test/abl" },
    { "type": "propath", "path": "src/main/resources" },
    { "type": "propath", "path": "../fwname/src" }, // Expecting framework to be checked out with the right version in this directory
    { "type": "propath", "path": "../fwname/src/inc" }, // One line per propath entry in framework source code
    { "type": "propath", "path": "../fwname/src/inc2" },
    { "type": "propath", "path": "../fwname2/sources" }, // Each framework has its own convention for source directories
    { "type": "propath", "path": "../fwname2/images" },
    { "type": "propath", "path": "../fwname2/inc" },
    { "type": "propath", "path": "${DLC}/tty/netlib/OpenEdge.net.apl" }, // Hope user has the right version of OE
    { "type": "propath", "path": "${DLC}/tty/netlib/OpenEdge.Core.apl" }
  ]

• With dependency management:

  "buildPath": [
    { "type": "source", "path": "src/main/abl" },
    { "type": "source", "path": "src/test/abl" },
    { "type": "propath", "path": "src/main/resources" }
  ],
  "dependencies": [
    { "groupId": "com.vendor.framework", "artifactId": "fwname", "version" : "9.1.0", "extension": "pl" },
    { "groupId": "com.vendor2.framework2", "artifactId": "fwname2", "version" : "7.4.1", "extension": "zip" },
    { "groupId": "com.progress.opendge", "artifactId": "net", "version" : "12.8.9", "extension": "apl" },
    { "groupId": "com.progress.opendge", "artifactId": "core", "version" : "12.8.9", "extension": "apl" },
    { "groupId": "cefsharp", "artifactId": "cefsharp", "version" : "124.3.80", "classifier": "assembly", "extension": "zip" },
  ]

With this syntax, all dependencies will be added after the last "source" entry and before any "propath" entry.

• Alternate solution:

  "buildPath": [
    { "type": "source", "path": "src/main/abl" },
    { "type": "source", "path": "src/test/abl" },
    { "type": "propath", "path": "src/main/resources" }
    { "type": "maven", "groupId": "com.vendor.framework", "artifactId": "fwname", "version" : "9.1.0", "extension": "pl" },
    { "type": "maven", "groupId": "com.vendor2.framework2", "artifactId": "fwname2", "version" : "7.4.1", "extension": "zip" },
    { "type": "maven", "groupId": "com.progress.opendge", "artifactId": "net", "version" : "12.8.9", "extension": "apl" },
    { "type": "maven", "groupId": "com.progress.opendge", "artifactId": "core", "version" : "12.8.9", "extension": "apl" },

The alternate syntax would clarify in which order to dependencies are added in the propath.

During the initialization of the project, all dependencies will be fetched from the repository to the standard location ($HOME/.m2/repository). Propath is then modified depending on the classifier and extension of the dependency. The very first version of the document only focuses on compile and assembly dependencies.

• pl and apl compile dependencies are added to the propath
• zip compile dependencies are extracted somewhere in the .builder directory of the project; each pl and apl in the root directory are added to the project, followed by the directory where the zip file is extracted. While simple OOABL dependencies can be pushed as pl or apl packages, many dependencies also provide include files (temp-table and dataset definition for example) that are needed in the propath.
• zip assembly dependencies are extracted somewhre in the .builder directory of the project, then the LS will generate an assembly.config file pointing to the various directories where the DLL are located

❓ Any extra classifier or post-processing required?

The runtime propath (in VS Code) will also be modified to reflect the list of dependencies. A solution has to be found to inject propath in VS Code tasks.

As in Java, compile dependencies can have matching javadoc and sources artifacts. Those artifacts will also be fetched and used by VS Code to show more information to the developer. The debugger will also use the sources package to show source code.

Initial implementation

• It's not expected that Maven Central will be used to host OpenEdge artifacts, so a private Nexus / Artifactory instance will be required
• The standard configuration file $HOME/.m2/settings.xml will be used to connect to remote repositories. First implementation will always use the default profile; support for profiles will be added later.

Future improvements

• Transitive dependencies, i.e. com.vendor.framework:fwname:9.1.0 depends on com.vendor.framework:fwname2:7.4.1 and com.progress.openedge:net:12.8.9, so it's not required to specify those dependencies in the JSON file. Transitive dependencies are specified when packages are pushed to the repository.
• Add a <VSCodeConfiguration /> child node to <PCTRun> that will manage dependencies and create propath on the fly
• Provide a way to easily generate and push artifacts
• Extra view in VS Code to browse dependencies content (for zip and pl/apl files)
• GroupId, ArtifactId and version will be added in the openedge-project.json file
  • If a dependency is available in the current workspace (same group, artifact and version) then the propath of this project will be used instead of fetching the Maven dependency

[kenherring]

Love the idea. Will be interesting to see what sort of packages get shared publicly. Discoverability will be important for adoption.

The suggested dependencies sections seem really verbose. Perhaps there's an opportunity to use the package.json type syntax that node uses? Something like this is much easier on the eyes:

  "dependencies": {
    "com.vendor.framework:fwname.pl": "9.1.0",
    "com.vendor2.framework2:fwname2.zip": "7.4.1",
    "com.progress.opendge:net.apl": "12.8.9",
    "com.progress.opendge:core.apl": "12.8.9",
    "cefsharp:cefsharp.zip": "124.3.80",
  }

It's not expected that Maven Central will be used to host OpenEdge artifacts, so a private Nexus / Artifactory instance will be required

I haven't used it much, so I'm not super familiar with it's limitations, but github packages seems like it would be worth considering. Keeping packages in the GitHub might make it less scary for newcomers to contribute, since there isn't another tool to learn.

[gquerret]

Something like this is much easier on the eyes

I'll check if both syntaxes can be supported.

I haven't used it much, so I'm not super familiar with it's limitations, but github packages seems like it would be worth considering.

I've never used GH packages as a Maven repo (only as a Docker images repo), but the documentation says that it's compatible. However, I think the primary usage is for companies having private packages, not for open source packages.