Samples and implementors

[Arthur De Magalhaes]

Hey everyone,

Are there any MP guidelines for having a "/samples" (sample applications, full source code) and "implementors.md" (list of current implementors and their OSS repos if applicable) for each project?

We would like to add those artifacts into the MP OpenAPI repo, but want to be consistent with the other MP projects.  

I think it would be useful to have that at the top level of each spec's repo, so that someone browsing the spec can easily have access to some samples and a list of githubs/vendors they can use to try it out.  

Thanks,

Arthur

[Ken Finnigan]

For implementors it would be best to link to [1], so that we're not duplicating information in different places.

Ken

[1] - https://wiki.eclipse.org/MicroProfile/Implementation

--
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+unsubscribe@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/736a43a4-989a-4c27-b432-464611fd31fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[donbo...@gmail.com]

Hi Arthur,

I agree with Ken about not duplicating the implementors info.  

Having samples is a good idea -- I'm not necessarily thinking a whole app as a sample, but perhaps a gallery of smaller snippets that could show different suggested ways to use the APIs.  Is that what you're thinking too?

Regards,

Don

[Arthur De Magalhaes]

Thanks for the feedback guys - I agree with keeping the implementors info where it is.  Perhaps I can add a link to it from the MP OpenAPI's readme page.  

We have some snippets of samples in the spec already, so we were thinking about actual full self-contained applications that one could run in one of the implementations.    That gives a better "bigger picture view" of the whole spec as opposed to independent snippets.  

So if there are no objections, we propose the guideline to have a  "samples" folder at the top level (sibling to tck | api | spec folders) of the corresponding sub-specification.  Is there a wiki we should document this?

Thx,

Arthur

[Emily Jiang]

Can you demostrate this in https://github.com/eclipse/microprofile-conference? We use that app to demo all programming model. You can also create some app in https://github.com/eclipse/microprofile-samples to demonstrate open api, which might be closer to what you are trying to do.

Basically, you should demonstrate Open API in both repo.

Emily

[Ondro Mihályi]

Hi Arthur,

As Emily pointed out, there are already 2 repositories to gather examples:

- at the level of a complete application that aims to demonstrate all MP features: microprofile-conference
- at the level of more fine-grained usecases and tutorials: microprofile-samples

I think we've already discussed and agreed that samples specific to individual spec can be added to the spec repository too. It's up to you.

My opinion is that:

- samples in the spec repository should be simple and to the point to demonstrate basic concepts and get new users started quickly. 
- anything bigger should go into the microprofile-samples repository, which we plan to transform to a repository for all kinds of getting started resources, including how-to guides (in asciidoc), sample applications, code samples, etc.
- microprofile-conference app is a demo application and should be updated to use all MP features. But it's just a demo - it should be easy to build & run and should prove that MP is really usable in a microservices architecture

--Ondro

[Ondro Mihályi]

And I forgot to mentiond that samples in the spec repositories should not be vendor-specific in my opinion, even if that would mean they aren't buildable or executable. They should only depend on MP APIs and provide sample code using the API.

Ondro

[Arthur De Magalhaes]

Thanks Emily / Ondro - this definitely helps.   I will open an item for us to look into how to best fit into the conference app.   

I wasn't aware we had that samples repo, so thx for the pointer.  At the very minimum, we should convert those Swagger references to MP OpenAPI =)     Will open another issue for that too.

- Arthur

[Werner Keil]

Hi,

Where can I find MP OpenAPI samples?

It's stated, that Wildfly (11? and hopefully both Swarm and the "full" version) passes the OpenAPI TCK. I am working on an OpenAPI related project right now where we look into OpenAPI extensions and tweaks, some of which could already been done in the MicroProfile features or be of interest to others in the community.

Thanks,

Werner

[Ken Finnigan]

Werner,

WildFly does not implement MicroProfile.

WildFly Swarm is what implements MicroProfile. And yes we're currently working on a PR that will bring MP Open API into a release, hopefully 2018.3.0 next week.

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+unsubscribe@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/37ddf454-2898-4242-a726-30f37e8183cf%40googlegroups.com.

[Arthur De Magalhaes]

Hi Werner,

At the moment you can see 2 sample apps from the TCK: https://github.com/eclipse/microprofile-open-api/tree/master/tck/src/main/java/org/eclipse/microprofile/openapi/apps

We will be uploading more samples to the samples repo in the next few weeks.

Thx,

Arthur

[Werner Keil]

Arthur/Ken,

Thanks for the reply. It's quite unfortunate, that unlike Payara (where Micro and "Full" are pretty much in sync regarding supported MicroProfile APIs and libraries) Wildfly does not provide them in the Full bundle OOTB, but it should be no problem to use it as a Maven or Gradle dependency (not "provided")

After helping the Metrics feature (indirectly via uom-cloud implementing microprofile-metrics-api) a lot recently, I would be happy to get involved with OpenAPI since it blends in well with some of the needs at the current client.

Especially security aspects and integration of e.g. EE4/Security API or Microprofile JWT are of great interest.

Werner