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

[davenice]

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.

[IvanHargreaves]

David, perhaps 2) could be lower priority. JVM server in a bundle is a bit of a minority sport, it does not benefit from the same capability as the CSD installed resource. When deployed in a CICS bundle it is less controllable and is life-cycled by bundlepart rather than having the full power of the CICS SPI. For example, customers accidentally writing tight loops in Java cannot use DISABLE/PURGE/FORCE/KILL to recover from the problem. There are other under-development capabilities that will not be available through bundle installed JVMSERVERS too.

[davenice]

Thanks, Ivan. I think we could have the 'additional files' parts working with very little additional effort, but it's good to know that they are less likely to be key parts of the use case!

[davenice]

Should output these in the correct codepage to be consumed into CICS. You could want to deploy to different systems that have different default codepages. Need to double-check exactly which codepages are required.