Build support for Java language in zAppbuild

[FALLAI-Denis]

Hi,

We need to set up a build chain for the Java language on z/OS.

Unless I'm mistaken, Java language support is not implemented in zAppbuild, nor perhaps in the IBM Dependency Based Build APIs, in particular to manage artifacts dependencies.

Is there any work planned for Java language support in zAppbuild (and DBB)?

If we have to develop our own Java language management through zAppbuild, would you have any advice to give us? Where could we collect information on managing Java compilations in a z/OS environment?

Note that DBB is a Java application for z/OS environment. So the DBB team should have experience on the subject?

Thanks.

[FALLAI-Denis]

Relate to Build support for Java language in DBB

[dennis-behm]

@FALLAI-Denis,

Thanks for bringing this up. It is the right time to discuss this while we just had some early discussions about it internally especially with the WCA4z assistant.

Today, zAppBuild facilitates building ZOS Connect Services as well as CICS Resource Builder definitions - all driving build tasks on USS - which can have a loose dependency to the traditional Cobol / PLI modules.

There are various technologies where you can use JAVA on the mainframe, that can be built differently (javac, gradle, maven).

What is the particual environment for your java application? How do you build them today, and what are your expectations in terms of managing dependencies?

[FALLAI-Denis]

Hi @dennis-behm,

Thank you for considering my request.

The request comes from our development teams who wish to use the Java language for mainframe processing, initially batch processing to manage XML flow exchanges.

To date we have never developed in Java on z/OS-USS, nothing committed and everything is to be built.

In other development streams, Java projects use Maven.

I started looking around and found some information about using IDz and a Java Development Toolkit, but I think I also figured out that the build was done on the workstation and then it was the result of the build, the jar files, which were delivered/deployed to the mainframe. This is not the same approach as a mainframe build using zAppbuild control and IBM DBB facilities.

The expected solution is to be able to build and deliver components developed in Java language in the same standard as our traditional applications developed essentially in COBOL. We want to be able to produce packages (Artifactory) containing the executables as well as a manifest describing the components with metadata allowing us to manage versioning and intelligent deployments (only deploy what has been modified compared to a previous deployment) . The packages are attached to an application set and must be able to contain components built from various origins, because above all we are deploying an application and the package is the image either of a version of this application, or the image of a change in the application, containing all the components defined for this scope. The package is the guarantee of the consistency of the components linked by the change.

[Woodsmithkenny]

Java would not need zAppBuild, nor is zAppBuild geared for Java code. Since Java code can be compiled elsewhere and run on the mainframe, I would advise that you merely deploy the class or jar files. However, if you do decide to compile Java on the mainframe, know that it would compile under the Unix system (Java does not go into PDSE's). Subsequently, you can use what Dennis recommended such as Maven or Gradle to execute the build process. Your distributed team's knowledge would apply here.

The only reason I can see that you would want to compile on the mainframe is to take advantage of the JZOS API that is built into the IBM SDK for z/OS.

[FALLAI-Denis]

Hi @Woodsmithkenny,

All our mainframe compilation process, (COBOL, Assembler, BMS), already run under USS. We also want to track all build action and have reports on these build actions thru DBB reporting and dependencies to be tracked by DBB and stored in medatadata DBB store. There is no reason for us to compile locally on a workstation since in most cases the result of the construction cannot be executed on this workstation (most often these are processes that must be executed in a CICS context).

The result of the build must also be stored in an Artifactory repository to then be deployed on test and acceptance environments, before being deployed in production.

Our mode of operation is to manage the sources under Git, to use DBB to trigger differential builds (and possibly by impacts on dependencies), and the Git commits must be associated with build references (Tags), themselves same associated with the Artifactory packages created following the build.

Thanks.

[Woodsmithkenny]

You can still store in Artifactory, still store code in Git. But why would you bother with storing dependency information in the DBB metadata store? Square peg, round hole. Remember also, that DBB never 'triggers' a build. Rather it is the underlying Git provider (Gitlab, GitHub, Azure Devops, etc).

Also, there is a HUGE difference in how we compile. With Java it's a FULL build every time. You don't recompile just a fraction of it like we do with COBOL or PL/I. With Maven or Gradle, your dependencies are stored within the build file. As far as a compile report, that comes out of javac command.

And a Java developer would always (and I mean ALWAYS) compile locally on the workstation regardless of whether they can only execute it on the mainframe. Further, a developer can execute portions of the code using JUnit testing, which can be called as part of every build cycle to ensure quality.