Collaboration on Implementations

[Ken Finnigan]

All,

As the WildFly Swarm team has had some inquiries about it's Eclipse MicroProfile implementations being available outside WildFly Swarm recently, and without any WildFly Swarm dependencies.

I wanted to bring an idea to the wider community to gauge interest.

Firstly I'd like to say I know we've had discussions around RIs for Eclipse MicroProfile in the past, and it was agreed that we didn't want to do that, and I'm not proposing that here.

So, what am I proposing.

I'd like to propose starting a community around developing common implementations for Eclipse MicroProfile specifications, with existing implementations being contributed as a starting point for collaboration.

These would need to be vendor agnostic in that the code within the common implementation didn't rely on specifics around WildFly Swarm, OpenLiberty, TomEE, etc, it would literally be the core classes required for an implementation.

One key piece is being able to viably execute those classes against the TCK, but I think that would be possible for most specifications by using the Arquillian Weld container, or maybe a custom container to act like one of our implementations for the purposes of passing the TCK.

Now, there may be some implementations that won't work this way, because of their reliance on implementation specific details, such as Rest Client relying on RESTEasy or CXF proxies. However, there may be an opportunity to develop implementation independent pieces to substitute for the custom framework pieces. Or even feed such requirements back into Jakarta EE specs, where appropriate.

If there's general agreement that such a thing is a good idea, I see there being two possible avenues for this to be achieved:

1. A new Eclipse project to hold the implementations. It would almost be a replica of the existing MicroProfile project in that there would be an umbrella that has many sub pieces inside it
2. Create a new GitHub organization for this effort, with a jointly defined name, where we can all collaborate with the usual GitHub processes

I will finish by saying that long term such an effort wouldn't be discussed as part of Eclipse MicroProfile, like I'm doing now, but it was a convenient way to reach the whole community to initiate discussion on the topic.

Regards

Ken

[James Roper]

I think this makes a lot of sense.

While working on the messaging API proposal, there were a number of non trivial parts of the code that I found that are going to end up needing to behave identically in every vendor implementation - particularly with the way that the CDI integration is implemented, the way messaging end points are discovered and how its decided that they are to work. So either they're going to have essentially duplicate code, or they'll end up with different behavior resulting in non portability between vendors. There's also parts of the code that would definitely be vendor specific. I think when providing an API like the messaging spec, it would make sense to share those parts of the implementation that are not vendor specific, by creating an SPI that vendors implement and work with. Note that I don't think such an SPI should be part of the spec, it definitely wouldn't be a formal thing, it doesn't need to be thoroughly specified (since vendors working on it will no doubt also be contributing to the shared code themselves and clearly are able to talk to each other), and I don't think a separate TCK from the TCK for the main API would be necessary. It's more about sharing the parts of the code that either only have one semantic implementation, or where it doesn't make sense for additional vendor value adds.

--
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/491b33b4-79b8-4209-a818-7d7cd655cfc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Octonaut

Lightbend – Build reactive apps!
Twitter: @jroper

[Mark Little]

I just want to add/expand on something to what Ken has said: there’s no suggesting that this would be a mandatory part of Eclipse MicroProfile work and therefore we’re neither suggesting nor requiring that other vendors, groups or individuals working on implementations would need to move to this project, but we do believe it would be a good idea to pool efforts now and then.

Mark.

--
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.

[Emily Jiang]

Ken,

As for the transparency point of view, both Open Liberty and Wildfly Swarm are all open source. People can view the source and contribute to the source though.

I am ok to document where the Open Liberty implementations are. However, to create a standalone implementation and then do the integration is a big effort. I can understand we need standalone implementations if there is a RI requirement. What is the big benefit to put multiple implementations in Eclipse and then just reconsume your own one. If we don't do sharing, I don't think it is worth the effort though. I might completely misunderstand you.


Emily

[Ken Finnigan]

Emily,

Right, a lot of the existing implementations are already open source, that wouldn't change.

I'm also not suggesting this new community would contain multiple implementations for the same specification.

I'll try and clarify what I mean with some examples.

The community I'm proposing could have an implementation for the MP FT spec, which could have been contributed by any vendor, but which Red Hat and IBM jointly contribute to it going forward.

Conversely the MP OpenAPI spec could be contributed to by Red Hat and Tomitribe, with IBM preferring their own implementation in their own repository.

Each specification would only have one implementation within the community, and then it's up to each vendor to determine whether they wish to contribute/use that implementation or develop their own.

There may also be situations where an implementation is just a thin common layer for vendors to expand on, such as what James described for messaging in a previous message.

Hope that explains what I'm proposing better.

Ken

[Ondro Mihályi]

Beyond what was written, my view
- this initiative is completely voluntary
- the code isn't part of the MicroProfile project
- each common impl can be a separate project at Eclipse or just a project on github, without any hard dependencies among them
- even if there's a dependency e.g. on VXF or Jersey, it should be pl8ggable or abstracted away

The benefit is to share the code which is repetitive and most implementations would write the same thing in a different color. Anything beyound that should be pluggable and part of the vendor implementations or separate libraries like DeltaSpike.

--Ondro

[Rudy De Busscher]

+1 on collaboration, each vendor doesn't need to reimplement the wheel (maybe only the attachment to the vehicle :) )

Rudy

[Kevin Sutter]

Just to offer an alternate view...  We've discovered several benefits to *not* having a common, shared implementation.  (Sorry, I still have a tough time differentiating between a shared implementation and a reference implementation, but I'll play along...)  Having multiple implementations has proven benefits -- better specs, better APIs, and better TCKs.  I'm concerned that if we go down this common, shared implementation route, then we'll be limiting the set of development efforts that will be testing out the MicroProfile artifacts.  As many of us have experienced over the years, only having a single implementation has not uncovered issues with the specs, apis, and tcks until several months later when the vendors finally produce alternative implementations.

I understand the discussion here about this shared implementation being an optional aspect of the MP features.  But, if this approach is adopted by the MP community, I'm concerned that it might become the expected process and we'll end up with reference implementations...

My two cents...
--  Kevin

[Ken Finnigan]

Kevin, I'm not requesting this shared implementation approach become part of the existing MP community. It would either be its own project at Eclipse or simply a GitHub organization for sharing projects. I've suggested it be separate as I didn't want this to be construed as providing an RI for MP.

I understand your point about multiple implementations leading to better specs and TCKs, especially in finding edge cases. However, I would see multiple vendors working on a common implementation still finding at least some of those situations when that common piece is being integrated into a vendors implementation, as most vendors take different approaches.

I would also add that offering a shared implementation could attract additional vendors to MP by offering a ready made set of implementations for existing specifications, as opposed to vendors being turned away by needing to develop half a dozen or more implementations before they can release something that's MicroProfile compatible.

I'll finish by saying that this idea is in no way mandatory for any vendor. If IBM chooses to be involved, whether it's as part of 1, 2, or 5 implementations, it would be great to have them participating, but if IBM chooses not to be involved that's fine as well. Each vendor needs to decide what the best approach for them is for each specification/implementation.

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/459621f3-1fc5-43d3-8d5b-3fe0bda54dbf%40googlegroups.com.

[Emily Jiang]

The more you talk this way, the more it is like a RI.  By the way, as I mentioned earlier, most of the application servers implementing MP are open source and their implementations are in the open. When you first brought it up, I was steering towards each app server lists the location of their impl so that everyone can see/learn. I am already seeing the split community - when said "if IBM does not participate it, then...". I feel this is not the right way to head towards. 

Emily

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.

[Ken Finnigan]

It’s certainly not my intention to portray this as an attempt at making an RI, or as an attempt to split the community.

If my choice of words have given that impression, I sincerely apologize.

I’m merely seeking to find out if there’s interest from other vendors to collaborate on one or more implementations, nothing more.

Ken

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b85f59bb-6e0b-4b63-a9bb-167fd21462ee%40googlegroups.com.

[Ondro Mihályi]

Hi Emily,

I don't understand how this may even remotely be like having an RI. This initiative is completely independent from Microprofile and Ken just invites everybody on the MicroProfile mailing list to join it if they want. I can even imagine that even under this initiative multiple separate implementations can happen in collaboration if there are 2 different groups of parties that have a different view on the implementation. The effort is not to create a single reference implementation but collaborate on some implementations where it makes sense.

I think about it as an initiative started by Red Hat who invite all others to collaborate. Payara is ready to accept the invitation. But we don't oblige ourselves to collaborate on all implementations nor use all of them in Payara Server. We have interest in collaborating in some implementations but may not need or want collaboration on some others. I see no reason to be negative about the initiative as it's completely voluntary and ad hoc organized.

--Ondro

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/b85f59bb-6e0b-4b63-a9bb-167fd21462ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/0CfBqzYKkaw/unsubscribe.
To unsubscribe from this group and all its topics, 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/F4296EA0-B093-4F84-BDBB-8613C23BFC86%40kenfinnigan.me.

[Guillermo González de Agüero]

I really welcome this idea. MicroProfile being based on CDI opens the door to easily pluggable implementations, even at application level (on Java EE environments).

This initiative would mean I could swap implementations to get the latest version when my server still doesn't have it.

At the same time, it would bring MicroProfile to Java EE runtimes that doesn't yet have it (e.g.: WebLogic), but also to Servlet containers where CDI is already pluggable nowadays.

Great idea overall. Hope it comes to a reality.

--

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/491b33b4-79b8-4209-a818-7d7cd655cfc8%40googlegroups.com.

[Arjan Tijms]

Hi,

Just to mention; MP JWT in Payara, through part of the Payara source tree, is basically completely server independent. It only really uses Java EE public APIs to code against.

There’s one Jersey specific API used, but that’s only for registering the JAX-RS feature when the jar is a container jar. If the jar is in web-inf/lib it would be scanned by JAX-RS.

[Werner Keil]

Hi,

Will be interesting to see, how things progress at Jakarta EE. As Glassfish was also contributed, there NOT having an RI seems hard to imagine ;-)

Werner

[Andy Gumbrecht]

I really like this idea, and would love to work on any shared implementation approach for all the specifications.

It would benefit the community and vendors alike, in that it would lead to more eyes on for each implementation and also reduce the effort for less resource wealthy contributors.

I'm +1 for a public Github, ASL & EPL, fork & PR approach. This would allow for non-eclipse member contribution, as these implementations don't need to be governed by Eclipse agreements.

Andy.

[Werner Keil]

Most of the compatible Java EE implementations are by other companies than Oracle, too ;-)

Eclipse maybe not so much for MicroProfile but certainly for Jakarta EE will have to come up with a proper way to claim and check compatibility, maybe even a certification, companies need to pay for.

IMO a better way of charging money than to join certain WGs or gain voting rights, especially if you look at contribution stats like https://projects.eclipse.org/projects/technology.microprofile/who

Even if you leave that "Eclipse Genie" out of the Bottle, there is still an large number of people not affiliated with one of the bigger companies (IBM, Red Hat, Payara or Tomitribe) who contribute to MicroProfile on a regular basis.

Werner

[Ken Finnigan]

For those that are interested in collaborating on implementations, I've created a Google Group to discuss next steps,etc.

Please join me at https://groups.google.com/forum/#!forum/shared-eclipse-microprofile-implementations

Ken

[Mike Croft]

+1

I don't think this is like an RI at all, but could certainly be helpful. Collaborations like this might pick up on other issues earlier and (potentially) add more features quickly. Whatever the result, this isn't something that's a binding, permanent change (or even something that would be the case for every spec) but is definitely worth trying.

[Kevin Sutter]

(Sorry, I am on vacation, so slow to respond...)

I'm still a little confused on the proposal here...  I see Ken's google group (yes, naming is hard).  Is the proposal to develop these shared implementations for existing MP components (ie. Config, JWT, etc)?  Or, is this proposal targeted at only new components (ie. reactive, or messaging, or transactions)?  I suppose an intermediate question would be new versions of existing components (ie. Config 1.3, Metrics 1.2, etc)?  Or, is this to be determined depending on the conversations with participants?  Just wondering if there's been any thoughts on the scope of this effort.

FWIW, I'd be more interested in participating in future component implementations, rather than current.  Since several implementations already exist for current components, it would seem like "busy work" to retrofit any of these as stand-alone, shared implementations.  (imho)  But, possibly working together on stand-alone, shared implementations for future components might provide some benefits to the community.  As has been stated, it might actually draw additional people into the community to participate.

Also, just to clarify, I'm assuming this effort would only be targeted at stand-alone implementations of individual components.  That is, we wouldn't be trying to provide a shared implementation of our top-level, convenience features -- MicroProfile 1.2, or MicroProfile 1.3.  Correct?

Thanks for the discussion.  If this thread is dead and this type of questions should be posted to the new group, let me know.

--  Kevin

On Tue, Mar 27, 2018 at 9:06 AM, Mike Croft <backtoth...@gmail.com> wrote:

+1

I don't think this is like an RI at all, but could certainly be helpful. Collaborations like this might pick up on other issues earlier and (potentially) add more features quickly. Whatever the result, this isn't something that's a binding, permanent change (or even something that would be the case for every spec) but is definitely worth trying.

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/0CfBqzYKkaw/unsubscribe.
To unsubscribe from this group and all its topics, 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/f389f9cc-918e-4f77-a66f-be8eda6e3600%40googlegroups.com.

[Ken Finnigan]

I see it being potentially both, but in the end its up to the community.

Not every vendor has already implemented all MP 1.3 specs, so there's potential for collaboration on already implemented specs for some vendors. That would likely entail a vendor providing their implementation as a base for further advancement and improvement.

I agree it wouldn't make sense to try and provide a common implementation for the entire MP level, such as 1.2 or 1.3, as that delves too much into the implementation specific nature of each vendors stack.

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/CABH8ermPFr8UyJefAfF9wTJDfzARAepqYdEP4_-qV6zxO%3D4hbA%40mail.gmail.com.

[John Clingan]

A reference implementation, in my mind, is a formally endorsed project. What is being proposed here does not have any formal endorsement by the MicroProfile project.

IMHO, I think this is going to happen regardless. Not all vendors want to write their own implementation of every spec. I think what Ken is advocating is some formal recognition to this fact, but not a formal endorsement. With my Product Manager hat on, there are business reasons for Red Hat engineers to innovate in some areas, but leverage common implementations in others. I suspect this is the case with other organizations as well.

[Emily Jiang]

I was thinking a workgroup is created to discuss further instead of a new workgroup, because the implementation is part of MicroProfile. I might misunderstand this. What is the purpose to branch off the discussion? I think whatever the community agree should be stayed in the MicroProfile community. We also need to make sure this implementation is not the only one out of there. 

Emily

[Ken Finnigan]

Emily,

What I was proposing is not for the implementations to be part of the existing MicroProfile community. If it was, then the proposal would definitely be trying to create RI's.

I'm not sure what you're saying with your last two statements.

Anyway, I've setup a Google Group to discuss the idea of shared implementations for individual MicroProfile specifications.

Maybe at some point it's decided that having RIs and merging the two is what the community wants, but right now it seems the preferred option is to keep them separate.

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/4bde3257-65aa-4412-a737-fca7dd7df903%40googlegroups.com.

[Mark Little]

+1 on the fact this isn’t an attempt to do RIs but rather enable interested individuals and groups to collaborate on MP component implementations.

+1 on not understanding the last statements.

Mark.

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/CAKeeVe5Pb9Zpm7j1r9F10HeOLa-wN9OHbFNbjDTW%3D-7BN2ejrg%40mail.gmail.com.

[Bob McWhirter]

Wearing my Red Hat hat, I’m hoping for sharing of implementations (full or even partial) between WildFly and WildFly Swarm.

Even previously-written specs. As Ken said, I think it’s up to whatever people want to do.

Like for “older” specs, how many of us have written very similar MetricServlets with prometheus exporters? Particularly since so much of the things are CDI-centric with well-defined interfaces, a lot of shared commonality could be useful.

When/If this gets off the ground, refactoring from WildFly and WildFly Swarm of existing implementations of older specs is where I’d personally be starting.

-Bob

On Tue, Mar 27, 2018 at 10:32 AM, Kevin Sutter <kwsu...@gmail.com> wrote:

--

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/CABH8ermPFr8UyJefAfF9wTJDfzARAepqYdEP4_-qV6zxO%3D4hbA%40mail.gmail.com.

[John D. Ament]

Likewise, I love hearing the approach described below.  I think its great that Andy M and I have been able to work on the MP Rest Client collaboratively on a client impl within CXF (rather than building it directly in liberty).  Likewise, Mark S, Romain and I have been working on getting some common components focused on MP implementations within Apache Geronimo.  

John

[Emily Jiang]

John (Ament), I liked the MP config and MP Rest Client implementation in Apache. It is a good thing.

In my previous comments, I just voiced a couple of my concerns.
1. The new implementation needs to be transparent and open, not labeling for RI - I think Ken and Mark answered that.
2. We should encourage multiple implementations per spec to flush out potential spec issues. Sorry if that seemed unclear.

Thanks
Emily

On Wednesday, March 28, 2018 at 7:10:53 PM UTC+1, John D. Ament wrote:

Likewise, I love hearing the approach described below.  I think its great that Andy M and I have been able to work on the MP Rest Client collaboratively on a client impl within CXF (rather than building it directly in liberty).  Likewise, Mark S, Romain and I have been working on getting some common components focused on MP implementations within Apache Geronimo.  

John

On Wednesday, March 28, 2018 at 9:40:32 AM UTC-4, Bob McWhirter wrote:

Wearing my Red Hat hat, I’m hoping for sharing of implementations (full or even partial) between WildFly and WildFly Swarm.

Even previously-written specs. As Ken said, I think it’s up to whatever people want to do.

Like for “older” specs, how many of us have written very similar MetricServlets with prometheus exporters? Particularly since so much of the things are CDI-centric with well-defined interfaces, a lot of shared commonality could be useful.

When/If this gets off the ground, refactoring from WildFly and WildFly Swarm of existing implementations of older specs is where I’d personally be starting.

-Bob

On Tue, Mar 27, 2018 at 10:32 AM, Kevin Sutter <kwsu...@gmail.com> wrote:

(Sorry, I am on vacation, so slow to respond...)

I'm still a little confused on the proposal here...  I see Ken's google group (yes, naming is hard).  Is the proposal to develop these shared implementations for existing MP components (ie. Config, JWT, etc)?  Or, is this proposal targeted at only new components (ie. reactive, or messaging, or transactions)?  I suppose an intermediate question would be new versions of existing components (ie. Config 1.3, Metrics 1.2, etc)?  Or, is this to be determined depending on the conversations with participants?  Just wondering if there's been any thoughts on the scope of this effort.

FWIW, I'd be more interested in participating in future component implementations, rather than current.  Since several implementations already exist for current components, it would seem like "busy work" to retrofit any of these as stand-alone, shared implementations.  (imho)  But, possibly working together on stand-alone, shared implementations for future components might provide some benefits to the community.  As has been stated, it might actually draw additional people into the community to participate.

Also, just to clarify, I'm assuming this effort would only be targeted at stand-alone implementations of individual components.  That is, we wouldn't be trying to provide a shared implementation of our top-level, convenience features -- MicroProfile 1.2, or MicroProfile 1.3.  Correct?

Thanks for the discussion.  If this thread is dead and this type of questions should be posted to the new group, let me know.

--  Kevin

On Tue, Mar 27, 2018 at 9:06 AM, Mike Croft <backtoth...@gmail.com> wrote:

+1

I don't think this is like an RI at all, but could certainly be helpful. Collaborations like this might pick up on other issues earlier and (potentially) add more features quickly. Whatever the result, this isn't something that's a binding, permanent change (or even something that would be the case for every spec) but is definitely worth trying.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/0CfBqzYKkaw/unsubscribe.

To unsubscribe from this group and all its topics, 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/f389f9cc-918e-4f77-a66f-be8eda6e3600%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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.

[Mark Struberg]

We had this discussion in the very beginning. And the consensus back then was a clear NO. 

The reason is that we want to create common understanding, common specifications but no implementations. Those should be up to the single vendors. 

Having a single project which delivers the spec and the TCK but also implementation will naturally lead to having an extremely poor spec and TCK. 

Been there, done that...

LieGrue,

strub

[Mark Struberg]

+1 
actually tripple +1 ;)

LieGrue,

strub

[Ondro Mihályi]

Hi Mark,

I reapect and understand. But I think you missed the point of this initiative. The goal is to develop some but not all implementations in a collaborative environment so that they can be used on their own without vendor dependencies. The implementations could be used as a library and also in any MP implementation.

Doing this under the MP project as a RI is definitely a non-goal.

However, Ken has created a separate mailing list to discuss this oit of MicroProfile. This thread was more to invite anybody to cooperate and not to discuss whether it should be done.

--Ondro

Dňa so 31. 3. 2018, 21:25 Mark Struberg <markst...@gmail.com> napísal(a):

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/0CfBqzYKkaw/unsubscribe.
To unsubscribe from this group and all its topics, 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/ee295a39-4462-4a8c-85a5-ffbc37145477%40googlegroups.com.