Migrate java code samples to new repo / make easier to use

[planetf1]

Update: see notes further down. Now expanding to improve overall usability of java samples

Our notebooks use a few environment variables so that they can be used without change across localhost, docker-compose & k8s

The java code samples tend to assume localhost:8080

It would be nice to support the same environment variables in the code samples, so that as well as using standalone, they could also be used 'as is' within an appropriate tutorial environment

Some docs will be needed, since the user may be running the code samples on local laptop, yet running egeria on k8s or compose, but the default could be to assume they will run within the containerized environment, and provide docs about setting them if not.

This would make it easier for someone to work through the samples

[planetf1]

We could also consider using the same typical user ids and server names as that used in the tutorial setup, ie for asset management sample use peter profile, for admin use gary geeke

[planetf1]

The values can be replaced (and as a code sample that's not too much to be expected) in the code, or via cli parms, but it still feels more approachable if things work out of the box to get people up to speed.

[mandy-chessell]

Hello Nigel, I think we do already use the same userIds. Also I thought all the samples take the url and server name as a parameter.

[planetf1]

It's primarily the URL that we default to http://localhost:8081 or similar in the code and we could default that using the variable name defined in the docker/k8s environment. This would just slightly reduce the steps (either by setting input parms - and I realise things like the file need to be specified anyway) if/when we want to integrate client code (and a new container) into these tutorial environments

Just like in the notebook we would set the URL to a) input parm b) env var if set c) default to localhost version

It's relatively minor, we may decide unnecessary

As an example, the CSV file reader sample cocoMDS1 garygeeke http://localhost:8080

Yet in the asset management notebook, the users are peterprofile using cocoMDS1 on localhost:8081, and we also use erinoverview using cocoMDS2 on localhost:8080

Consistency would help re-enforce the scenario, and make it easier to work /experiment with the samples in a sandpit environment

[planetf1]

odpi/egeria#284 is adding further client samples with hardcoded URLs

This issue should be broadened out. It's about making it easy for a developer to experiment with client examples. To do this they will also need an egeria server to use.

We already document a few different ways to run a sample egeria environment 'ootb' - locally, docker-compose, k8s . There's also documentation on running egeria more generally by launching the platform directly - or indeed a user could simple run the own managed docker containers.

The client samples are likely to often be run locally at the cli, or from a user's IDE -- but for demos may also run in a container

So ensuring parms can be passed, and/or picked up via environment/properties is essential.

However in addition, the samples need to be easily obtainable, and buildable

I would therefore suggest we need to do the following

• ensure every sample can be built standalone - providing it's own maven pom.xml for example, not dependent on egeria parent
• ensuring that each sample is setup to use any required dependencies - either by colocating dependencies within the jar, or providing the jars in an appropriate place (former probably easier)
• ensuring all samples are collected, with any required clients, into an appropriate assembly (.gz etc) for sharing
• providing a new docker container, or more likely a way to use the existing one (hint: it probably already works but isn't documented) to run code samples to support labs
• ensuring samples can be run locally, against docker, compose, k8s etc.
• Look at an easy way to configure the hosts/ports to be used - perhaps a combinations of properties (easy, via env vars to inherit in a container) or invocation parms
• documenting the above

One somewhat parallel consideration is whether we want to move samples to a seperate repo. ++ : clearer, easier to clone, less confusion. -- : another repo to manage

[planetf1]

See odpi/egeria#284 - need to decide where to put/distribute the clients, ie new repo etc

[planetf1]

odpi/egeria#2693 has seperated out the samples into unique modules, but further work is needed on the code/docs etc so this remains relevant to leave open

[planetf1]

The code samples now are runnable, and synchronized with the users used by coco.

They do still build off the main maven project rather than seperately

They do assume localhost, since it is expected a developer is only running the code samples locally. We have no 'containerized' tutorial support which is a potential option for the future

removing from the 2.0 milestone as we consider further work for the future in this area

[planetf1]

With some basic work done, the next improvement for usability is to migrate these code samples to the new repository Assigning the issue there for the right focus (even though we'll need a PR here to execute removal)

[planetf1]

Assigning to @mandy-chessell who is refactoring and migrating samples over to this new repo.

[planetf1]

Closing now, as creation of new tutorials has gone down a very clear path in offering new examples to support learning