Restructuring/updating the microprofile-conference demo repository and app

[Scott Stark]

Having spent a week in the microprofile-conference demo app to add support for some of the MP-1.2 features, it seems clear that we need to both break up this application and repository as well as simply update the angular dependencies to Angular 4+ to bring it into alignment with the current release.

In terms of breaking up the repository, it seems straightforward to make each of the microservice-* modules their own repository.

Any disagreement on that? I know we touched on this in another thread, and it seemed like that was a consensus there.

The breakup of the frontend pieces is not so straightforward as we first need to define how the frontend displays and makes use of the various MP-1.2 features. You can see what I did for our Wildfly-Swarm tech preview here:

https://github.com/MicroProfileJWT/microprofile-conference/releases/tag/MP_12-RC6

There are some videos of a screen capture of the demo there in addition to the updated microprofile-conference code.

Let's throw around some ideas here and then have a hangout once some candidate directions have appeared.

[Ondro Mihályi]

I admit there were more voices for splitting to multiple repos, but I'd still like to summarize the disadvantages of doing this:

- more repos make it more complex to get started, it would no longer be as simple as clone && mvn install
- it would be harder to keep up with updates in all repos, multiple git pull instead of one
- makes it harder to contribute a new service, instead of a PR against existing repo it would be necessary to ask Eclipse to create a new repo
- there are already a lot of git repos, adding a repo for each service makes it even harder to navigate among them

Now I would like to hear about advantages, because I'm not aware of many.

--Ondro

[Scott Stark]

The main problem is that you cannot update the MP spec and expect that existing services will work. The way that the web-application is currently setup to run, there is a TomEE container that runs the endpoints service, and also wants to pull in all of the other services as well. This does not work currently because it has not been updated to support MP-1.2.

That keeping all services running at the same version of MP was not practical was the primary argument for splitting off the services. Although you can create branches to manage services that implement a given version of the spec, that defeats the purpose of having one repo as you have to have at least a copy of the repo per MP version.

The conference app does not really need to be under the Eclipse organization as it is not a proper release that requires the IP vetting process. 

This could still be the aggregator of the various microservices using subrepositories so that you can do a git clone --recursive && mvn install.

[Ondro Mihályi]

I understand the argument but I don't think it justifies the complexity of splitting the repo.

The core problem is that the services are still coupled and depend on the same parent pom and the version specified in the pom. Each service should specify it's dependencies separately. We've agreed that each service is by default bound to a specific implementation and therefore shouldn't require a version of MP that isn't supported by the impl.

The whole application should be started with `mvn package -P start,ui` which starts each service with the default implementation so I see no reason why TomEE would pull other services than the Speaker service. All other services should be started on different implementations. If you used to start all services on a single instance of TomEE that clearly doesn't work unless TomEE supports the latest version of MP. But it was a "hack" to simplify development and should be rather avoided. If we want to simplify and speed up development with MicroProfile, we need to address it rather than creating workarounds.

In summary, if I got what you meant correctly, the main argument for splitting the repo isn't an issue and can be resolved in a much simpler way. 

--Ondro

[Scott Stark]

Yes, just decoupling the microservices from the parent and having a default implementation to run it are the main issues which can be addressed as you suggest.

[Emily Jiang]

The main advantage of splitting the repo into multiple is to demonstrate microservices architecture properly. Each microservice should have an independent release cycle. The interactions among them should be via services. Only after we split the repos we can demonstrate microservices properly. In this way, the sharing of the parent does not make sense any more. By the way, creating a few more repos should not be a concern for this effort.

Emily

[Ondro Mihályi]

I still think that splitting the repo is just more work and not much in return. Microservices can be demonstrated in a single repo if they don't depend on each other. They can also be released independently - artifacts can have different versions and still be in the same repo.

Let me be honest - the reason I'm so much against the split is that I'm pretty sure I won't be able to work on the conference if the repo splits into several repos. It would just get too complicated for me and I don't have additional time for such unnecessary complexity.

--Ondri

[Emily Jiang]

I would think it will be much better to be worked on as they are all independent. You only need to check out the service you are going to work most of the time.
Emily