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.