User interface is missing from egeria packaging

[planetf1]

'a clean build of 1.3 does not produce access-services-user-interface-1.3-SNAPSHOT.jar as I expected it to. In fact the user-interface directory is missing from the egeria-1.3-SNAPSHOT-distribution/egeria-omag-1.3-SNAPSHOT directory'

-- User report from: https://odpi.slack.com/archives/CBPRDQPRC/p1576056215113300

My response

we are doing a lot of work on it currently to make it useable. This includes refactoring/renaming which unfortunately is what caused the problem you saw :-(
One alternative way to run is to either
a) Use our egeria docker container (the docker compose & k8s examples show how to do this - I can get more specific it if helps)
b) Launch via java -jar ~/src/egeria/open-metadata-implementation/user-interfaces/ui-chassis/ui-chassis-spring/target/ui-chassis-spring-1.3-SNAPSHOT.jar Note that in fact the UI currently needs to have some basic config provided for the server url and server name. Personally I start it with OMAS_SERVER_URL=http://localhost:8081 OMAS_SERVER_NAME=cocoMDS1 java -jar ~/src/egeria/open-metadata-implementation/user-interfaces/ui-chassis/ui-chassis-spring/target/ui-chassis-spring-1.3-SNAPSHOT.jar but this will depend on your configuration. Soon the configuration of the UI will change quite a bit more.

[planetf1]

cc: @davidradl I missed this one when we did the refactoring. Should have spotted it. Just cc: FYI for next time. I can fix - though wanted to point out in case relevant in your latest refactoring -- it's another location to update.

[planetf1]

Additional discrepancies:

Specified in assembly egeria-omag.xml but does not exist

• ../../open-metadata-implementation/access-services/data-process/data-process-client/target/
• ../../open-metadata-implementation/access-services/data-science/data-science-client/target/

Present in build and above file, but with path errors

• ./adapters/open-connectors/rest-client-connectors/spring-rest-client-connector/target/spring-rest-client-connector-1.3-SNAPSHOT.jar

Other missing services - found in the build
./access-services/asset-lineage/asset-lineage-client/target/asset-lineage-client-1.3-SNAPSHOT.jar
./access-services/design-model/design-model-client/target/design-model-client-1.3-SNAPSHOT.jar
./access-services/glossary-view/glossary-view-client/target/glossary-view-client-1.3-SNAPSHOT.jar
./adapters/open-connectors/rest-client-connectors/rest-client-connectors-api/target/rest-client-connectors-api-1.3-SNAPSHOT.jar
./adapters/open-connectors/rest-client-connectors/rest-client-factory/target/rest-client-factory-1.3-SNAPSHOT.jar
./adapters/open-connectors/rest-client-connectors/spring-rest-client-connector/target/spring-rest-client-connector-1.3-SNAPSHOT.jar
./common-services/gaf-metadata-management/gaf-metadata-client/target/gaf-metadata-client-1.3-SNAPSHOT.jar
./common-services/ocf-metadata-management/ocf-metadata-client/target/ocf-metadata-client-1.3-SNAPSHOT.jar
./common-services/odf-metadata-management/odf-metadata-client/target/odf-metadata-client-1.3-SNAPSHOT.jar
./governance-servers/discovery-engine-services/discovery-engine-services-client/target/discovery-engine-services-client-1.3-SNAPSHOT.jar
./governance-servers/open-lineage-services/open-lineage-services-client/target/open-lineage-services-client-1.3-SNAPSHOT.jar
./governance-servers/stewardship-services/stewardship-services-client/target/stewardship-services-client-1.3-SNAPSHOT.jar
./repository-services/repository-services-client/target/repository-services-client-1.3-SNAPSHOT.jar
./user-interfaces/ui-admin-services/ui-admin-services-client/target/ui-admin-services-client-1.3-SNAPSHOT.jar

Note we also have connectors here

However this raises another issue on the clients -- they are dependent on other libraries which would not be included in the single jar file copy.

The server/UI is ok, since it does generate a jar with dependencies

We probably need to run an assembly to collect dependencies for each module, and then may be able to sort out dups in this final assembly time. Having a seperate packaging step is also easy to miss (see missing clients above), and so a step to somehow mark a library/module as being into a particular package may be better done within each module build, (ie 'client', 'ui', 'server', 'all' etc which the assembly build could then iterate over to collect

Rather than fix one issue here, I think this exposes the fact we need to clarify the intent of our packaging. We then need to ensure it's module driven/easy, and that it is validated - for example if we ship a client jar we need to ensure it can be used

Moving to 1.4 for this discussion

[planetf1]

See additional comments made in 2319 (referenced above)including

• cassandra, and other connectors, don't include dependent libs
• even non-executable jars are 0755
• jars used for differing purposes may need to be split out (connectors, clients [already done] core] & we may need more assemblies which can be overlaid
• Also connector jars are in server - but need to be used from (and tested with) a client - similar considerations for samples

[planetf1]

Also noted that for some packaged jars we also include the source and javadoc jars, for others we don't

[planetf1]

Fixed by #2579 - refactoring missed out the UI