Giter VIP home page Giter VIP logo

cics-bundle-maven's Introduction

cics-bundle-maven Maven Central Latest Nexus Snapshots Build Status

Also see the Generated Maven plugin documentation ↗


About this project

This is a Maven plugin and related utilities that can be used to build CICS bundles, and deploy them into CICS TS.

This project contains:

  • cics-bundle-maven-plugin, a Maven plugin that authors CICS bundles for deploying resources into CICS TS. It supports a subset of bundleparts, including Java assets. Read the generated plugin documentation for information about this plugin's goals.

    Using the plugin you can:

  • cics-bundle-reactor-archetype, a Maven archetype that provides a simple reactor build that contains a CICS bundle and a Dynamic Web Project (WAR). This archetype builds and packages the WAR and CICS bundle.

  • cics-bundle-deploy-reactor-archetype, a Maven archetype that provides a simple reactor build that contains a CICS bundle and a Dynamic Web Project (WAR). This archetype packages the WAR into a CICS Bundle and installs it into CICS.

  • samples, a collection of samples that demonstrate the different ways in which to use the plugin.

Supported bundlepart types

The cics-bundle-maven-plugin supports building CICS bundles that contain the following bundleparts:

It can deploy CICS bundles containing any bundleparts.

Prerequisites

To use the plugin to build CICS bundles, make sure that Maven is installed.

Make sure any required bundles or projects are installed into your local maven repository (.m2 cache) correctly using mvn install if they are not available in an online repository.

The plugin builds CICS bundles for any in-service version of CICS Transaction Server for z/OS (version 5.3 and later at the time of writing).

However, if you are using the deploy goal of the plugin to deploy bundles to CICS, you must enable the CICS bundle deployment API. The CICS bundle deployment API is supported by the CMCI JVM server that must be set up in a WUI region or a single CICS region. See the CICS TS doc for details. To use the deploy goal, make sure that:

  • For a CICSPlex SM environment, set up the CMCI JVM server in the WUI region of the CICSplex that contains the deployment target region. The WUI region must be at CICS TS 5.6 or later.
  • For a single CICS region environment (SMSS), set up the CMCI JVM server in the deployment target region. The region must be at CICS TS 5.6 with APAR PH35122 applied, or later.

Create a CICS bundle (in a separate module) using cics-bundle-maven-plugin

This way of building a CICS bundle is useful when the CICS bundle contains more than one Java bundlepart, or contains extra bundleparts like FILE or URIMAP. It uses a separate module for the CICS bundle.

The cics-bundle-maven-plugin contributes a new packaging type called cics-bundle. This is bound to the plugin's build goal that will use the information in the pom.xml and dependencies to create a CICS bundle, ready to be stored in an artifact repository or installed into CICS.

To create a CICS bundle in this way:

  1. Create a new Maven module for the CICS bundle.

  2. Register the plugin to the pom.xml of the CICS bundle module:

    <build>
      <plugins>
        <plugin>
          <groupId>com.ibm.cics</groupId>
          <artifactId>cics-bundle-maven-plugin</artifactId>
          <version>1.0.3</version>
          <extensions>true</extensions>
        </plugin>
      </plugins>
    </build>

    Note that the version should be the latest version of this plugin, which can be found at the top of this page.

  3. Change the packaging type of the CICS bundle module to the new CICS bundle type:

    <packaging>cics-bundle</packaging>

    If at this point you build the CICS bundle module, it will create a valid CICS bundle! However, it doesn't do much, because it doesn't define any bundle parts.

  4. In the CICS bundle module, define a dependency on another module for a Java project that can be included into CICS, such as an OSGi bundle, WAR, EAR, or EBA.

    <dependencies>
      <dependency>
        <groupId>my.group.id</groupId>
        <artifactId>my-web-project</artifactId>
        <version>1.0.0</version>
        <!-- Version ranges are also supported CICS phase in support with OSGi bundles i.e. -->
        <!-- <version>[1.0.0,2.0.0)</version> -->
        <type>war</type>
      </dependency>
    </dependencies>
  5. The plugin requires very little configuration. However, an important property for Java bundleparts is the name of the JVM server that the application will be installed into. To define this, alter how you registered the plugin to add some configuration, with the <defaultjvmserver> property:

    <build>
      <plugins>
        <plugin>
          <groupId>com.ibm.cics</groupId>
          <artifactId>cics-bundle-maven-plugin</artifactId>
          <version>1.0.3</version>
          <extensions>true</extensions>
          <configuration>
            <defaultjvmserver>DFHWLP</defaultjvmserver>
          </configuration>
        </plugin>
      </plugins>
    </build>

    Now if you build the CICS bundle (mvn clean verify or mvn clean install) it will pull in the dependency, add it into the CICS bundle, and define it in the CICS bundle's manifest. The CICS bundle is ready to be deployed to CICS or stored in an artifact repository (if you use mvn clean install the CICS bundle is installed into your local .m2 repository at the end of the build).

    The generated CICS bundle takes its bundle ID from the Maven module's artifactId and its version from the Maven module's version.

  6. To include CICS bundleparts like FILE or URIMAP, put the bundlepart files in your bundle Maven module's bundle parts directory, which defaults to src/main/bundleParts. Files in your Maven module's bundle parts directory will be included within the output CICS bundle, and supported types will have a <define> element added to the CICS bundle's cics.xml. The location of the bundle parts directory can be configured by using the <bundlePartsDirectory> property. The configured directory is relative to src/main/.

Create a CICS bundle (from an existing Java module) using cics-bundle-maven-plugin

This way of building a CICS bundle modifies an existing Java module to make it also build the CICS bundle. This makes it more lightweight, but it has limitations - the CICS bundle can only contain one Java bundlepart, and can't contain any extra bundleparts such as FILE or URIMAP.

To create a CICS bundle in this way:

  1. Take an existing OSGi bundle, WAR, EAR or EBA module. In this case we'll use the bundle-war goal for a WAR module, but there are matching bundle-osgi, bundle-ear and bundle-eba goals for those types of module. These goals bind, by default, to the verify phase.

  2. Register the plugin to the pom.xml of the CICS bundle module, and add the appropriate goal as an execution, including configuration for which JVM server the CICS bundle will be installed into:

    <build>
      <plugins>
        <plugin>
          <groupId>com.ibm.cics</groupId>
          <artifactId>cics-bundle-maven-plugin</artifactId>
          <version>1.0.3</version>
          <executions>
            <execution>
              <goals>
                <goal>bundle-war</goal>
              </goals>
              <configuration>
                <jvmserver>DFHWLP</jvmserver>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>

Now if you build the Java module with verify phase or later, i.e. mvn clean verify to avoid installing the artifact locally or mvn clean install to install it locally in your .m2 directory, it will build the module as usual but then also wrap it in a CICS bundle, and define it in the CICS bundle's manifest. The CICS bundle is added to the output of the module, by default using the cics-bundle classifier, and is ready to be stored in an artifact repository or deployed to CICS.

Deploy a CICS bundle using cics-bundle-maven-plugin

Following the instructions from one of the two methods above, you will have built a CICS bundle. You can use the cics-bundle-maven-plugin to install this into CICS by using the CICS bundle deployment API. This requires some setup in CICS as a prerequisite.

  1. Ensure a BUNDLE definition for this CICS bundle has already been created in the CSD. You will need to know the CSD group and name of the definition. The bundle directory of the BUNDLE definition should be set as follows: <bundle_deploy_root>/<bundle_id>_<bundle_version>.

The username defined in the pom.xml is the developer’s credentials which need to have access to the appropriate RACF profile_prefix.CMCI.DEPLOYER EJBROLE. Credentials, such as a username and password, should not be directly placed into the pom.xml file. Instead, variables for the credentials should be referenced in the pom.xml file.

  1. In the pom.xml, extend the plugin configuration to include the extra parameters below:

    <build>
      <plugins>
        <plugin>
          <groupId>com.ibm.cics</groupId>
          <artifactId>cics-bundle-maven-plugin</artifactId>
          <version>1.0.3</version>
          <executions>
            <execution>
              <goals>
                <goal>bundle-war</goal>
                <goal>deploy</goal>
              </goals>
              <configuration>
                <!-- if you are deploying a Java module that also builds the CICS bundle,
                     you must specify the artifact with the cics-bundle classifier to be deployed.
                <classifier>cics-bundle</classifier>
                -->
                <defaultjvmserver>DFHWLP</defaultjvmserver>
                <url>http://yourcicsurl.com:9080</url>
                <username>${cics-user-id}</username>
                <password>${cics-password}</password>
                <bunddef>DEMOBUND</bunddef>
                <csdgroup>BAR</csdgroup>
                <cicsplex>CICSEX56</cicsplex>
                <region>IYCWEMW2</region>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>

    Note: If you're deploying the bundle into a single CICS region environment (SMSS), omit the <cicsplex> and <region> fields.

  2. Edit the values in the configuration section to match your CICS configuration.

    • url - Set the transport, hostname, and port for your CMCI
    • username & password - These are your credentials for CICS. Use Maven's password encryption, or supply your credentials using environment variables or properties
    • bunddef - The name of the BUNDLE definition to be installed
    • csdgroup - The name of the CSD group that contains the BUNDLE definition
    • cicsplex - The name of the CICSplex that the target region belongs to. This value is ignored in a single CICS region environment (SMSS).
    • region - The name of the region that the bundle should be installed to. This value is ignored in a single CICS region environment (SMSS).

Now if you run the Maven build it will create the CICS bundle as above, and install this in CICS. If you run into an unable to find valid certification path to requested target error during deployment, see Troubleshooting for a fix.

Each time you make a change to the Java project and rerun the build it will redeploy the bundle and publish your changes.

Typically, you won't want this deployment to happen in every environment that the build is run. Placing this execution in a separate Maven profile that is only enabled in development environments is suggested.

Using nightly/snapshot development builds

Snapshot builds are published to the Sonatype OSS Maven snapshots repository which is not available in a default Maven install. To try a snapshot build, you will need to add the following plugin repository to your pom.xml:

<project>
  ...
  <pluginRepositories>
    <!-- Configure Sonatype OSS Maven snapshots repository -->
    <pluginRepository>
      <id>sonatype-nexus-snapshots</id>
      <name>Sonatype Nexus Snapshots</name>
      <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
      <releases>
        <enabled>false</enabled>
      </releases>
    </pluginRepository>
  </pluginRepositories>
  ...
</project>

Samples

Use of this plugin will vary depending on what you're starting with and the structure of your project. We have included some samples to demonstrate the different methods.

  • Reactor sample
    This sample is the best starting place if you don't already have a Java project you want to build and want to have a go at building and deploying straight away. This is a reactor project with one module including the source for a web page (including a JCICS call), which will be packaged into a WAR. It has a second module, which creates the bundle and installs this in CICS. Further information can be found here.

  • WAR sample
    This sample shows how you can add to the pom of an existing Java Maven project, to build it into a bundle and install it in CICS. Further information can be found here.

Archetypes

Another way to get started with the plugin is to use one of the provided archetypes. Maven archetypes provide parameterized templates for how a module could, or should, be structured. There are two archetypes, one which builds and packages a WAR into a CICS Bundle, and another which then installs this bundle to CICS using the CICS bundle deployment API. Further details on how to use the archetypes can be found here.

Versioning your Maven-built CICS bundles

Maven best practice is to version your code <version>-SNAPSHOT during development (for instance 0.0.1-SNAPSHOT or 1.0.0-SNAPSHOT - for more information see the Maven doc about SNAPSHOT versions).

Developing your code using a SNAPSHOT version will ensure that every time you build your code the previous SNAPSHOT is overwritten in your local Maven repository.

When you are happy with the quality of your code and want to make a release version, reversion your plugin to remove the -SNAPSHOT qualifier. The maven-release-plugin provides facilities to automatically remove qualifiers, automatically updating dependencies and promoting code in your source control.

If you do not want to use the maven-release-plugin, you can update the version numbers of your parent reactor project, which will also update child project version numbers. Run this command within your parent reactor project:

mvn versions:set -DnewVersion=0.0.1

Note that this versions:set approach will not update dependencies (e.g. from your bundle project to your Java project) which you will need to update manually.

After releasing your code, update to your next development version number, for instance 0.0.2-SNAPSHOT.

Troubleshooting

unable to find valid certification path to requested target during deployment

Why does it happen?
You may run into this error when deploying your CICS bundle.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It indicates an issue with establishing a trusted connection over TLS/SSL to the remote server (CICS Bundle Deployment API). It may happen when you are using a self-signed certificate or a certificate that's issued by an internal certificate authority, or that the certificate is not added to the trusted certificate list of your JVM.

How to resolve it?
You have two ways of resolving this issue:

  1. Recommended Obtain the server certificate(s) and add it/them to the trusted certificate list to your JVM:
    For security consideration, you may still want the TLS/SSL checking to be enabled. In this case, follow the instructions in How do I import a certificate into the truststore to trust the server's certificate, supplying your server's information. More information about the command involved is listed below:

  2. Disable TLS/SSL certificate checking:
    Add <insecure>true</insecure> to the <configuration/> block for the deploy goal in the bundle's pom.xml (See snippet in Step 2 in deploy a CICS bundle to a target CICS region).
    Note: Trusting all certificates can pose a security issue for your environment.

internal server error during deployment

You might see this error in the Maven log when you deploy a CICS bundle:

com.ibm.cics.bundle.deploy.BundleDeployException: An internal server error occurred. Please contact your system administrator

Why does it happen?
It indicates errors on the CMCI JVM server side.
How to resolve it?
Contact your system administrator to check the messages.log file of the CMCI JVM server. For more information about how to resolve CMCI JVM server errors, see Troubleshooting CMCI JVM server in CICS documentation.

Error creating directory during deployment

You might see this message in the Maven log when deploying a CICS bundle:

[ERROR]  - Error creating directory '<directory>'.

Why does it happen?
The error occurs because the credential that deploys the bundle doesn't have access to the bundles directory.
How to resolve it?
Contact your system administrator to make sure the deploy_userid configured for the CICS bundle deployment API has WRITE access to the bundles directory. The bundles directory is specified on the com.ibm.cics.jvmserver.cmci.bundles.dir option in the JVM profile of the CMCI JVM server.
For instructions on how to specify the bundles directory and grant access to deploy_userid, see Configuring the CMCI JVM server for the CICS bundle deployment API in CICS documentation.

Contributing

We welcome contributions! Find out how in our contribution guide.

Support

The CICS bundle Maven plugin is supported as part of the CICS Transaction Server for z/OS license. Problems can be raised as IBM Support cases, and requests for enhancement can use the Ideas site, for product CICS Transaction Server for z/OS.

Equally, problems and enhancement requests can be raised here on GitHub, as new issues.

License

This project is licensed under the Eclipse Public License, Version 2.0.

cics-bundle-maven's People

Contributors

banjaxxer avatar davenice avatar dependabot[bot] avatar imgbotapp avatar inam747 avatar ind1go avatar jt-nti avatar kyemaloy97 avatar ledina avatar sophiegreen avatar stewartfrancis avatar tom-foyle avatar tom-latham avatar vera-chan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cics-bundle-maven's Issues

Support deploying from another artifact

Currently to deploy you either have to specify the bundle location, or it will default to getting the artifact for that maven project. Allow specifying a bbundle published as another artifact.

Deploying error: Text may not be null

[ERROR] Failed to execute goal com.ibm.cics:cics-bundle-maven-plugin:1.0.3-SNAPSHOT:deploy (default) on project cics-java-liberty-restapp: Execution default of goal com.ibm.cics:cics-bundle-maven-plugin:1.0.3-SNAPSHOT:deploy failed: Text may not be null -> [Help 1]

What does that mean ? It's not clear what it's complaining about...

Diagnosed by stew:

Ok the dependency from cics-bundle-maven-plugin wasn't updated to use the snapshot version of cics-bundle-common. If you could raise a defect Mike, that'd be great. Public repo is fine

    <dependency>
      <groupId>com.ibm.cics</groupId>
      <artifactId>cics-bundle-common</artifactId>
      <version>1.0.2</version>
    </dependency>

The pom I used:

<?xml version=“1.0” encoding=“UTF-8"?>
<project xmlns=“http://maven.apache.org/POM/4.0.0” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd”>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.ibm.cics</groupId>
  <artifactId>cics-java-liberty-restapp</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>war</packaging>
  <dependencies>
    <!-- https://mvnrepository.com/artifact/javax.xml.bind/jaxb-api -->
    <dependency>
      <groupId>javax.xml.bind</groupId>
      <artifactId>jaxb-api</artifactId>
      <version>2.3.1</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>3.1.0</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>javax.annotation</groupId>
      <artifactId>jsr250-api</artifactId>
      <version>1.0</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>javax.ws.rs</groupId>
      <artifactId>javax.ws.rs-api</artifactId>
      <version>2.0.1</version>
    </dependency>
    <!-- JCICSX dependency -->
    <dependency>
      <groupId>com.ibm.cics</groupId>
      <artifactId>com.ibm.cics.jcicsx</artifactId>
      <version>1.000.0-5.6</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
  <pluginRepositories>
    <!-- Configure Sonatype OSS Maven snapshots repository -->
    <pluginRepository>
      <id>sonatype-nexus-snapshots</id>
      <name>Sonatype Nexus Snapshots</name>
      <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
      <releases>
        <enabled>false</enabled>
      </releases>
    </pluginRepository>
  </pluginRepositories>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <!-- The below bundles the application as a WAR in a CICS bundle and deploys this to CICS using the CICS bundle deployment API.
           This is optional and can be removed if you don’t wish to deploy the application this way -->
      <plugin>
        <groupId>com.ibm.cics</groupId>
        <artifactId>cics-bundle-maven-plugin</artifactId>
        <version>1.0.3-SNAPSHOT</version>
        <executions>
          <execution>
            <!-- These goals will firstly run the war packaging on the project, and then will run the deploy goal, which will happen during the verify phase of the lifecycle by default-->
            <goals>
              <goal>bundle-war</goal>
              <goal>deploy</goal>
            </goals>
            <configuration>
              <!-- The bundle classifier indicates that the war should be packaged into a CICS bundle -->
              <classifier>cics-bundle</classifier>
              <!-- Update the default JVM server that the application will be installed into by default, This is used when creating the bundle, and goes into the CICS bundle’s manifest -->
              <jvmserver>DFHWLP</jvmserver>
              <!-- Set the URL of the deploy target -->
              <url>http://winmvs2c.hursley.ibm.com:22566</url>
              <!-- We’d recommend that you use Maven’s password encryption, or supply your credentials using environment variables or properties, as shown here. -->
              <username>MCOBBE</username>
              <password></password>
              <!-- Identify which bundle definition you’re going to use from the CSD and which region and CICSPlex you want to deploy to -->
              <bunddef>DEMOBUNDLE</bunddef>
              <csdgroup>SOMETHING_HERE</csdgroup>
              <!-- in a stand-alone region, neither of these parameters are needed: -->
              <!-- <cicsplex>CICPY022</cicsplex> -->
              <!-- <region>CICPY022</region> -->
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Build Node bundle parts

#14 covers non-Java based bundle parts.

It would be good to build Node bundle parts which we haven't taken into account for that issue.

Add build timestamp in cics.xml

The Explorer implementation that generates cics.xml injects a build time within the <manifest> tag, like:

    <meta_directives>
        <timestamp>2014-02-11T12:55:48.222Z</timestamp>
    </meta_directives>

The Maven implementation should do similar.

Add validation when building

Validate during build to match existing validation in CICS Explorer where possible.

  • name of generated bundle part (valid characters, no spaces)
  • jvmserver name validity ... probably don't want to mandate because of option to allow default JVM server for the region
  • verify behaviour if dependent Java project doesn't build cleanly
  • ...?

Docs improvement suggestion

The docs for https://ibm.github.io/cics-bundle-maven/deploy-mojo.html need improving such that
it's clear the and parameters should be omitted if the region is a stand-alone one.

----------------- conversation leading up to this issue being raised ------------------
So for a stand-alone region, with A CMCI-enabled Liberty JVM server, and a normal liberty JVM server, I still don’t know what value to put for the field. Or perhaps this isn’t a supported configuration ?
Context: Trying to use the maven plug-ins to deploy a JCICSX sample. (edited)

Tom Foyle
For a stand-alone region, you should remove the and fields, as they are not relevant.

David Knibb
yep - because your single region (SMSS) is not part of a CICSplex.

Stew Francis
If the doc doesn't make that clear, can you raise a defect so we can address that? Thanks Mike!

Mike Cobbett
It could be clearer. A Required:No is the only hint I think. https://ibm.github.io/cics-bundle-maven/deploy-mojo.html

Stew Francis
Yeah I agree. The doc there should say in which environments it's required, and which it isn't.
If you could raise an issue against that repo, that'd be great

Build samples as part of build

Continuing from #69 , the samples delivered should be built as part of the main build, to ensure that samples are updated when we break them.
This will likely require a wiremock server set up for them to hit during the deploy step.

Support user property overrides

Maven plugins permit the use of user properties, i.e. system properties that are recognised by the plugin and can be used to override its configuration. For example, from the invoker plugin:

image.png

These give flexibility to the build and allow overriding in different environments more easily.

Best practice for user properties is now to pick a prefix (invoker above) to namespace your properties, avoiding clashes with other plugins.

Allow bundle import statements

Support for bundle import statements. We don't think this is likely to be essential for the kind of use we're targetting.

add support for non-Java-based bundle part types.

The Java-based bundle parts we currently support (WAR/EAR/JAR) are configured by setting dependencies in the pom file and adding the cics-bundle-maven-plugin.

This issue considers adding support for other bundle parts. There are a few categories of these:

  1. Simple bundle parts - e.g. URI map
  2. Bundle parts with additional files - e.g. JVM server, which has an associated JVM profile file
  3. Other Java-based bundle parts we haven't added support for - e.g. EBA projects

In this issue I'm primarily thinking about (1) and (2). (3) should likely follow the same approach as WAR/EAR/JAR.

Having discussed this we have two potential approaches; one where the cics.xml is generated at build time, and one where the cics.xml is a hybrid - partly provided by the user and partly generated based on the pom.xml.

The advantage of having the cics.xml generated is that there is less to go wrong and a clearer path for the user. The disadvantage is that there are some aspects of cics.xml that won't lend themselves to being specified in a pom (e.g. ordering of definitions). For the moment I'm not addressing other elements that could be included in cics.xml.


Approach 1

a) User supplies bundle parts and supporting files if applicable into src/main/cics-bundle
b) In the build phase, copy these files across
c) In the build phase, detect provided bundle part files and generate defines in the cics.xml (as with the Java-based bundles)
d) The defines would be ordered in a way that will cater for the vast majority of use cases (so, traditional definition bundle parts before Java-based bundle parts, pipeline before webservice)


Approach 2 (this was the original issue description)

This a we're considering is like this:
a) Put bundle part files (e.g. mymap.urimap) into src/main/cics-bundle
b) Put cics.xml file into src/main/cics-bundle/META-INF
c) Early in the build phase, copy these files across as the basis for our final CICS bundle
d) When processing the Java-based bundle parts extend the user-provided cics.xml file by appending the Java-based bundle parts specified in the pom (initially).

Further work could include alterations in CICS Explorer to allow users to create bundle parts and a CICS manifest using the GUI directly into the Maven project.

e) At this point we could allow users to add the Java-based bundle parts into the cics.xml using the GUI - the GUI would check the Maven dependencies for available projects. This would then allow the order of the Java-based bundle parts to be controlled.

Add m2e integration for better experience in Eclipse

To improve the workflow in Eclipse, m2e features can be used to auto-build with the Eclipse build cycle, and to show generated resources without a manual refresh.

Tasks:

  • Introduce m2e mapping to validate CICS bundles on incremental builds
  • Use BuildContext to communicate file changes to be refreshed

Be explicit in README.md about support

Give assurances about using this library by documenting how to get support (in addition to what's already in CONTRIBUTING.md), and that support is included in your CICS TS license.

Write full OSGi bundlepart version

At the moment the symbolic name is written into the bundlepart with the version in.

This needs to be updated so that the version is written into the correct xml attribute, separately from the name. So the XML should look something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <osgibundle symbolicname="myosgi" version="1.0.0" jvmserver="JVMONE"/>

Bind maven install plugin to install phase

Currently we don't bind anything to the install phase, which means CICS bundle artifacts never make it to your local maven repo when using the cics-bundle packaging type. We should bind the install plugin to correct this.

Deploying: "null/null" appearing in an info message when running mvn

When deploying an app into a region which isn't part of a sysplex, I get this:

Deploying bundle to http://winmvs2c.hursley.ibm.com:22566 into region null/null

OK, I've not specified the <region> or <cicsplex> tag in the pom.xml, but messages with null inside look wrong.
The cdsgroup is always there, perhaps deploying to that ? with an optional region/cicsplex in the message would be better ?

Allow CICS resources that have additional files which would need transcoding

For instance, pipeline resources require supporting files to be present in EBCDIC on the server.

We'd need to detect the pipeline resource additional file and transcode it during build time.

Other unsupported resources include...
Atomservice (needs to be EBCDIC)
JVM server (JVM profile needs to be local USS/zFS encoding)
Node.js
Pipeline (config file needs to be IBM-037)
Web service (additional files need to be transferred as binary)
EBA
XML Transform
JSON Transform

Improvements to the samples

  • Update samples so that both options can be deployed simultaneously. Currently the war is named the same in both so cannot both be installed and enabled at the same time.

  • Add version number to maven-compiler-plugin to fix warning

  • Update the docs in regards to issues with certificates/trust store

  • Rename default JVM server in the samples

Provide samples for Maven plugin usage

We should provide a couple of sample bundles. We could provide both a 'standalone' bundle that packages a pre-existing WAR project, and a WAR project that is configured to produce a bundle.

We should deliver these as sample projects within cics-bundle-maven/samples and build them automatically as part of our build.

Modify behaviour so that failing to provide a JVM server when required generates an error

Currently we default defaultjvmserver to MYJVMS. However there's no sensible default JVM server name. If users are bundling a Java app, they need to specify a JVM server name.

We should alter the behaviour so that if a JVM server name isn't provided either via defaultjvmserver or specific JVM servers on every relevant project, the build fails and the user is warned.

The only people this will affect is those who genuinely are happy with the default because they have a JVM server called MYJVMS .... it seems that this group will be vanishingly small!

NoClassDefFoundError on mvn clean install for demo-war sample

I'm using jdk 1.8. I get this error when I try to create the cics-bundle for the demo-war sample project.

Command used: mvn clean install
Error messages:
[WARNING] Error injecting: com.ibm.cics.cbmp.BundleWarMojo
java.lang.NoClassDefFoundError: com/ibm/cics/bundle/parts/BundlePublisher$PublishException
...
Failed to execute goal com.ibm.cics:cics-bundle-maven-plugin:1.0.0:bundle-war (default) on project demo-war-bundle: Execution default of goal com.
ibm.cics:cics-bundle-maven-plugin:1.0.0:bundle-war failed: A required class was missing while executing com.ibm.cics:cics-bundle-maven-plugin:1.0.0:bundle
-war: com/ibm/cics/bundle/parts/BundlePublisher$PublishException

Make `/deploy` implicit

When specifying the deployment URL in settings.xml, users shouldn't have to specify the path to the deploy endpoint, as that's going to be the same everywhere. Just where it's hosted should be sufficient.

Publish Maven doc to github pages

Git can natively host markdown, but the Maven doc is produced in HTML.

Push the Maven doc to github pages at the end of the build (probably via a gh-pages branch).

Potentially also pull across the readme as an index page.

Non-reactor bundles fail to deploy if classifier is not set

In the scenarios where we create a CICS bundle from an existing project, using the bundle-osgi / bundle-war / bundle-ear / bundle-eba goals, the classifier attribute claims to be optional with a default value of cics-bundle, but omitting it from pom.xml results in a deployment failure with the error message:

[ERROR] Failed to execute goal com.ibm.cics:cics-bundle-maven-plugin:1.0.1-SNAPSHOT:deploy (default) on project standalone-war: Some of the supplied parameters were invalid:
[ERROR]  - bundle: Error reading bundle manifest: Supplied CICS bundle must have a manifest at META-INF/cics.xml

Also, the comment in the samples makes it sound like the cics-bundle value is somehow significant to the packaging method, whereas I think it's actually just an arbitrary string which is appended to the zip filename?

<!-- The bundle classifier indicates that the war should be packaged into a CICS bundle -->
<classifier>cics-bundle</classifier>

Relevant doc pages:
https://github.com/IBM/cics-bundle-maven#create-a-cics-bundle-from-an-existing-java-module-using-cics-bundle-maven-plugin
https://ibm.github.io/cics-bundle-maven/bundle-war-mojo.html#classifier

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.