What to do about the "Conference App"!

[Ken Finnigan]

In yesterday's MP Hangout we briefly discussed the situation with https://github.com/eclipse/microprofile-conference but we wanted to continue the discussion with a wider audience on the mailing list.

There was general agreement that having the conference app was generally a good idea, as it showcased multiple implementations.

However, as it's languished for a while now we need to define some proper plans around it's goals and maintenance, or agree that it needs to be archived as "job done".

For the goals, there was some discussion around whether it should be an entry level type application that doesn't strive to show all features of MicroProfile but rather is a quick way for users to see how MicroProfile can be used. The alternative is that the goal is to utilize as many of the MicroProfile specifications as possible across the entire application. Becoming like the "Pet Store" of MicroProfile.

Any feedback on what the goals of the application should be is appreciated.

If there's agreement to continue developing the application, either as entry level or more detailed, we need to determine a proper plan for maintaining and updating it with each new release. Some ideas that were brought up during the meeting were:

1. Do specifications become responsible for updating it to use new features as part of the specification release process?
   
2. Should it be treated similarly to a specification of MicroProfile in that there is a "lead" for it, with regular meetings, maybe every 1 or 2 months, to discuss work on it?
3. Possibly having a branch for a new MP specification release so that the API usage can be updated as they're released, but only once all implementations support that release does the branch get moved to "master" and replace the previous version. The reason being that until all implementations are updated to the latest version then the application would not work.

We'd like to hear all the views of the community about whether it should continue, what it's goals should be, and how the maintenance/update process should work.

Thanks

Ken

[Martijn Verburg]

Hi Ken,

I think it's really important to have this (or another) app which is the go-to reference for the specifications.  More thoughts inline.

On Wed, 3 Oct 2018 at 13:24, Ken Finnigan <k...@kenfinnigan.me> wrote:

In yesterday's MP Hangout we briefly discussed the situation with https://github.com/eclipse/microprofile-conference but we wanted to continue the discussion with a wider audience on the mailing list.

There was general agreement that having the conference app was generally a good idea, as it showcased multiple implementations.

However, as it's languished for a while now we need to define some proper plans around it's goals and maintenance, or agree that it needs to be archived as "job done".

For the goals, there was some discussion around whether it should be an entry level type application that doesn't strive to show all features of MicroProfile but rather is a quick way for users to see how MicroProfile can be used. The alternative is that the goal is to utilize as many of the MicroProfile specifications as possible across the entire application. Becoming like the "Pet Store" of MicroProfile.

Any feedback on what the goals of the application should be is appreciated.

I think the quick way to see how it can be used should be an initial goal.  But a stretch goal should be to showcase the specifcations later.

 

If there's agreement to continue developing the application, either as entry level or more detailed, we need to determine a proper plan for maintaining and updating it with each new release. Some ideas that were brought up during the meeting were:

1. Do specifications become responsible for updating it to use new features as part of the specification release process?
   

For the stretch goal I think yes.

1. Should it be treated similarly to a specification of MicroProfile in that there is a "lead" for it, with regular meetings, maybe every 1 or 2 months, to discuss work on it?
   

In my experience, mini projects like this typically need an owner else they languish.

Cheers,

Martijn

1. Possibly having a branch for a new MP specification release so that the API usage can be updated as they're released, but only once all implementations support that release does the branch get moved to "master" and replace the previous version. The reason being that until all implementations are updated to the latest version then the application would not work.
   

We'd like to hear all the views of the community about whether it should continue, what it's goals should be, and how the maintenance/update process should work.

Thanks

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/bf907627-45a7-4008-bcf4-7163feed6165%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Hi,

What I said about the sample app here https://groups.google.com/forum/#!topic/microprofile/C-jgrcNAlr4 (although the "starter" app does not seem to be a demo, but the name is somewhat misleading into that direction) also goes for the "conference" app.

The readme and just one module changed about half a year ago, everything else is up to 2 years old, so it cannot be up to date with all the specs and changes that are produced here.

Cheers,

Werner

[Ondro Mihályi]

Hi,

* Goals:

    * quick getting started app, with a single command line to start everything up (doesn't need to start all the services, jsut a few essentials to get started)

    * eventually showcase all MP spec features, at least code features. There's no way we can reasonable demo all features in a single app, but the repository can have multiple optional modules that can be enabled if people want to dig deeper

* Do specifications become responsible?

     * ideally spec teams should contribute some code to the conference app, but in reality, I think they should at least raise enhancement requests to leverage new functions in the spec

     * if we can find a lead, then it's best if we can treat the conf app as specifications. But individual specs should be raising enhancement requests otherwise it's very hard work to keep the app filled with the latest&greatest. It should be a requirement for releasing a spec that the spec team raises enhancement requests for the conf app before a release

Ondro

[Ivan St. Ivanov]

Hi everyone,

We at Bulgarian JUG started working on the MicroProfile Hands on Lab:

https://github.com/bgjug/microprofile-hol-1x

Its goal is basically to serve as tutorial on how to use the various MicroProfile specs. For that we have a scenario with 5 microservices running on five different runtimes. There are scripts that start each separate microservice and there's a script that starts them all. The only thing you need to have installed in order to run it is Maven (and Java obviously).

So far we have covered Config, Metrics, Health Check and Fault Tolerance. I had a workshop with the current state at Voxxed Days Bucharest. And I got a very positive feedback.

After a short break, I am working now on JWT. Then we have in the pipeline Open API, OpenTracing and Typesafe REST Client. The plan is to complete everything until the end of the month, when we are giving another workshop at Voxxed Days Microservices (together with my fellow JUG member and co-author Dmitry as well as Emily and Antoine).

So I guess with some proper feedback from the spec leads (me and Dmitry are just users, not experts) and some native speakers touch, this can turn into a great tutorial. Something like Arun's Java EE hands-on-lab (which we used as inspiration).

You can check it out here: https://github.com/bgjug/microprofile-hol-1x/releases/download/1.2.0/microprofile-hol.zip

Cheers,

Ivan 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7209b316-e283-48f7-82f7-f3728c54691a%40googlegroups.com.

[Emily Jiang]

Hi Ivan,

Thanks for the update! I think it will be great if this lab can be contributed to MicroProfile. I think a lab to demonstrate all MP specs is very valuable. Thoughts?

Thanks

Emily

[Ivan St. Ivanov]

Hi Emily,

From our point of view (me and Dmitry), when we started this hands on lab already for 1.0, our sole purpose was to contribute it to the MicroProfile organization.

However, it was never in a "complete" state, that is why we haven't promoted it yet.

But now with the Voxxed Days Microservices challenge, we will have to finish it. :)

Cheers,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/79a2c56c-cfee-413d-96e4-07b76b678180%40googlegroups.com.

[Emily Jiang]

Thanks Ivan! Sounds great!

Emily

[Ken Finnigan]

This topic has diverged significantly from it's initial intent.

Although the creation of the Hands on Lab by the Bulgerian JUG is a great advertisement for MicroProfile, we need to be very careful about adding more demos/examples/etc into the MicroProfile umbrella without defined leaders to ensure it's maintained and updated. Otherwise we're simply creating a greater maintenance burden for ourselves, when we already have failed at updating the Samples and Conference repos on a regular basis.

If there is a desire to not continue with the Conference demo and replace it with the content of the Hands on Lab from Ivan, then that needs to be raised and discussed as a separate topic.

Ken

[Werner Keil]

I spoke to one of the DukeConf creators in a JUG that helps iJUG and JavaLand while at JCON in Düsseldorf this week. Asking him, if they ever considered synergies with the MicroProfile Conference demo. He said they looked at it, but it also seems they did not find enough synergies to use and help maintain it.

Werner

[Werner Keil]

And unless others come up as reliable maintainers, for those repositories that are orphaned and unmaintained, please use the "archive" feature on GitHub to show that to members of the community.

Thanks,

Werner