<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019 at 11:19 AM Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:"trebuchet ms",sans-serif">Right now I'll add MP OpenAPI and MP Fault Tolerance and I'll clean up the caps in the descriptions..</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">If the consensus on the thread, with Darran getting a big vote, is that we need MP JWT then I'll add it.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">For now to be consistent I'll call them MP. I have no problem changing them to use MicroProfile, but I'll let this thread discuss a bit longer on where to put the furniture before I start moving it around. ;)</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I'm curious what the issue with 'MP' is. This has come up in a different context from this one so I'm curious about the reasoning; e.g. if there's a general desire in the MicroProfile community not to abbreviate, or perhaps 'MP' is bad in some cultural contexts, or perhaps it's too overloaded.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:"trebuchet ms",sans-serif"></div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">Re: a generic MicroProfile component, personally I find that kind of thing confusing. General purpose components become a crack where things get lost, or at least slowed done waiting for someone to notice them and reassign. We already have the 'Server' general bucket. I know there are some general tasks we'll be dealing with over the next few quarters, but I wonder for how long that will be a common thing. You can't later remove a component without first removing it from all issues. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019 at 10:56 AM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Not sure if we need a MicroProfile JWT component, it is just another aspect of security maintained by the same team.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019 at 4:48 PM Radoslav Husar <<a href="mailto:rhusar@redhat.com" target="_blank">rhusar@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jira admins whoever you are,<br>
<br>
Out current Jira components for MicroProfile are a bit messy [1].<br>
<br>
1) We are missing MicroProfile Jira components for OpenAPI, Fault<br>
Tolerance, JWT, etc. These need to be added with corresponding owners.<br>
2) The existing components are unnecessarily abbreviated, please<br>
rename "MP Config" and alike to "MicroProfile Config" to make them<br>
easier to find.<br>
3) The existing component descriptions are a bit mangled, e.g.<br>
"MIcroprofile" or "Microprofile".<br>
4) Do we need a "catchall" MicroProfile component for issues not<br>
specific to any spec, e.g. [2], [3]?<br>
<br>
Thanks!<br>
<br>
Rado<br>
<br>
PS: As always, I am happy to do it if given admin access ;-)<br>
<br>
[1] <a href="https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page" rel="noreferrer" target="_blank">https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page</a><br>
<br>
[2] <a href="https://issues.jboss.org/browse/WFLY-12757" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WFLY-12757</a><br>
<br>
[3] <a href="https://issues.jboss.org/browse/WFLY-12681" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WFLY-12681</a><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>