[cdi-dev] Team mentions on github

Martin Kouba mkouba at redhat.com
Wed Oct 19 05:52:32 EDT 2016


Hi Werner,

this only works in GitHub pull request comments.

Martin

Dne 19.10.2016 v 11:48 Werner Keil napsal(a):
> Martin,
>
> Thanks for pointing that out. Have to try it on GitHub, e.g. issues or
> elsewhere. I used quoting individual users before on many cases.
>
> However, CDI uses JIRA at JBoss, so not sure, if this would work there, too?
> It does in the GitHub issue tracker. PRs if there's more discussion
> there might work, but maybe not the issue tracker, or do we have an EG
> group there, too?
>
> Werner
>
>
>
> On Wed, Oct 19, 2016 at 10:22 AM, <cdi-dev-request at lists.jboss.org
> <mailto:cdi-dev-request at lists.jboss.org>> wrote:
>
>     Send cdi-dev mailing list submissions to
>             cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>             https://lists.jboss.org/mailman/listinfo/cdi-dev
>     <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>     or, via email, send a message with subject or body 'help' to
>             cdi-dev-request at lists.jboss.org
>     <mailto:cdi-dev-request at lists.jboss.org>
>
>     You can reach the person managing the list at
>             cdi-dev-owner at lists.jboss.org
>     <mailto:cdi-dev-owner at lists.jboss.org>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of cdi-dev digest..."
>
>
>     Today's Topics:
>
>        1. Re: Spliting SE package in an independent jar (Werner Keil)
>        2. Team mentions on github (Martin Kouba)
>        3. [JBoss JIRA] (CDI-625) When exactly are events with
>           @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
>           (Martin Kouba (JIRA))
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Tue, 18 Oct 2016 15:29:39 +0200
>     From: Werner Keil <werner.keil at gmail.com <mailto:werner.keil at gmail.com>>
>     Subject: Re: [cdi-dev] Spliting SE package in an independent jar
>     To: John Ament <john.ament at spartasystems.com
>     <mailto:john.ament at spartasystems.com>>
>     Cc: cdi-dev <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>     Message-ID:
>
>     <CAAGawe1UavyR9qv0iOLCBHpXpuVzMcrBfDL_-bcu2deA9MZNGQ at mail.gmail.com
>     <mailto:CAAGawe1UavyR9qv0iOLCBHpXpuVzMcrBfDL_-bcu2deA9MZNGQ at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>
>     Meaning SE API adds stuff to what EE already needs not sub-setting
>     it, so
>     you end up with more interfaces on SE than EE.
>
>     If the additional SE JAR is simply for bootstrapping on SE, that's
>     understandable, but it does not meet the idea of
>
>     >5. Define a lightweight container, which takes the annotations
>     specified
>     by the @Inject specification, defines the behaviour of the container
>     (which
>     @Inject failed to do), and adds a couple of popular features from
>     CDI such
>     as producer >methods. This will allow much wider adoption of CDI in the
>     Java world, and provide a great stepping stone between Java SE, a
>     servlet
>     container, OSGi and a full Java EE server.
>     from the proposal.
>
>     Was that found out of scope or not doable in CDI 2?
>
>     Having 2 JARs where EE only nees one is not what I would consider
>     "lightweight".
>
>     Werner
>
>
>     On Tue, Oct 18, 2016 at 3:23 PM, John Ament
>     <john.ament at spartasystems.com <mailto:john.ament at spartasystems.com>>
>     wrote:
>
>     > Thats why cdi-se-api depends on cdi-api.
>     >
>     >
>     > ------------------------------
>     > *From:* Werner Keil <werner.keil at gmail.com
>     <mailto:werner.keil at gmail.com>>
>     > *Sent:* Tuesday, October 18, 2016 6:37 AM
>     > *To:* John Ament
>     > *Cc:* cdi-dev
>     >
>     > *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar
>     >
>     > Yes, but on SE you can't just use the "cdi-se-api" on its own.
>     >
>     > So SE on the API level needs 2 JARs not just one. That's what I mean.
>     > I trust the sum of all JARs for an implementation would be somewhat
>     > smaller on SE, otherwise the "Micro" idea of using a
>     self-executable or
>     > "Fat" JAR in those places would be ad-absurdum, if you end up with
>     a "Fat
>     > JAR" that's bigger than most existing app servers;-)
>     >
>     > I would have expected a
>     > core-api
>     > se-api
>     > ee-api
>     >
>     > kind of setup, but if it won't blow implementations on the SE
>     side, I also
>     > understand that.
>     >
>     > Werner
>     >
>     >
>     > On Tue, Oct 18, 2016 at 12:19 PM, John Ament
>     <john.ament at spartasystems.com <mailto:john.ament at spartasystems.com>
>     > > wrote:
>     >
>     >> Opposite Werner, EE API is larger and has the bulk of the
>     content.  SE
>     >> API at this point has two classes.
>     >>
>     >>
>     >> ------------------------------
>     >> *From:* cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>
>     <cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>>
>     >> on behalf of Werner Keil <werner.keil at gmail.com
>     <mailto:werner.keil at gmail.com>>
>     >> *Sent:* Tuesday, October 18, 2016 5:27 AM
>     >> *To:* cdi-dev
>     >>
>     >> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar
>     >>
>     >> So cdi-se-api is larger than the (core) EE API?
>     >>
>     >> An SE implementation should hopefully have a smaller footprint than
>     >> current EE ones (e.g. Weld)?
>     >>
>     >> Werner
>     >>
>     >>
>     >> On Tue, Oct 18, 2016 at 11:09 AM,
>     <cdi-dev-request at lists.jboss.org
>     <mailto:cdi-dev-request at lists.jboss.org>>
>     >> wrote:
>     >>
>     >>> Send cdi-dev mailing list submissions to
>     >>>         cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     >>>
>     >>> To subscribe or unsubscribe via the World Wide Web, visit
>     >>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>     <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>     >>> or, via email, send a message with subject or body 'help' to
>     >>>         cdi-dev-request at lists.jboss.org
>     <mailto:cdi-dev-request at lists.jboss.org>
>     >>>
>     >>> You can reach the person managing the list at
>     >>>         cdi-dev-owner at lists.jboss.org
>     <mailto:cdi-dev-owner at lists.jboss.org>
>     >>>
>     >>> When replying, please edit your Subject line so it is more specific
>     >>> than "Re: Contents of cdi-dev digest..."
>     >>>
>     >>>
>     >>> Today's Topics:
>     >>>
>     >>>    1. Re: Spliting SE package in an independent jar (Martin Kouba)
>     >>>    2. [JBoss JIRA] (CDI-45) Optional Injection Points
>     >>>       (Martin Kouba (JIRA))
>     >>>    3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0
>     >>>       (Antoine Sabot-Durand (JIRA))
>     >>>    4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0
>     >>>       (Antoine Sabot-Durand (JIRA))
>     >>>    5. No meeting tomorrow (Antoine Sabot-Durand)
>     >>>    6. Re: Spliting SE package in an independent jar (Emily Jiang)
>     >>>
>     >>>
>     >>>
>     ----------------------------------------------------------------------
>     >>>
>     >>> Message: 1
>     >>> Date: Thu, 13 Oct 2016 09:56:24 +0200
>     >>> From: Martin Kouba <mkouba at redhat.com <mailto:mkouba at redhat.com>>
>     >>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar
>     >>> To: John Ament <john.ament at spartasystems.com
>     <mailto:john.ament at spartasystems.com>>,  Antoine Sabot-Durand
>     >>>         <antoine at sabot-durand.net
>     <mailto:antoine at sabot-durand.net>>,     cdi-dev
>     <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     >>> >
>     >>> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com
>     <mailto:616fdc4e-26f6-a8d7-16d3-fdceb71faa1f at redhat.com>>
>     >>> Content-Type: text/plain; charset=windows-1252; format=flowed
>     >>>
>     >>> +1 for John's proposal.
>     >>>
>     >>> So there will be two API artifacts:
>     >>> * cdi-api
>     >>> * cdi-se-api (depends on cdi-api)
>     >>>
>     >>> Martin
>     >>>
>     >>> Dne 12.10.2016 v 12:40 John Ament napsal(a):
>     >>> > the way I've envisioned it:
>     >>> >
>     >>> >
>     >>> > - There is no dedicated EE API (none that I could find that is
>     EE only,
>     >>> > except for perhaps session scoped)t
>     >>> >
>     >>> > - There is SE specific API and the current API could be considered
>     >>> "core"
>     >>> >
>     >>> >
>     >>> >
>     >>> > Take the current API module and create two submodules, one for
>     core and
>     >>> > one for SE.  SE depends on core.  EE still refers to core as
>     the same
>     >>> > existing coordinates (create new coordinates for the parent).
>     >>> >
>     >>> > ------------------------------------------------------------
>     >>> ------------
>     >>> > *From:* cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>
>     >>> > <cdi-dev-bounces at lists.jboss.org
>     <mailto:cdi-dev-bounces at lists.jboss.org>> on behalf of Antoine
>     Sabot-Durand
>     >>> > <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>
>     >>> > *Sent:* Wednesday, October 12, 2016 5:18 AM
>     >>> > *To:* cdi-dev
>     >>> > *Subject:* [cdi-dev] Spliting SE package in an independent jar
>     >>> >
>     >>> > to avoid including CDI SE features in Java EE, we already talk
>     about
>     >>> > creating a specific SE jar.
>     >>> >
>     >>> > Any thought on this approach?
>     >>> >
>     >>> > Antoine
>     >>> > ------------------------------------------------------------
>     >>> ------------
>     >>> > NOTICE: This e-mail message and any attachments may contain
>     >>> > confidential, proprietary, and/or privileged information which
>     should
>     >>> be
>     >>> > treated accordingly. If you are not the intended recipient, please
>     >>> > notify the sender immediately by return e-mail, delete this
>     message,
>     >>> and
>     >>> > destroy all physical and electronic copies. Thank you.
>     >>> >
>     >>> >
>     >>> > _______________________________________________
>     >>> > cdi-dev mailing list
>     >>> > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>     <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>     >>> >
>     >>> > Note that for all code provided on this list, the provider
>     licenses
>     >>> the code under the Apache License, Version 2 (
>     >>> http://www.apache.org/licenses/LICENSE-2.0.html
>     <http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas
>     >>> provided on this list, the provider waives all patent and other
>     >>> intellectual property rights inherent in such information.
>     >>> >
>     >>>
>     >>> --
>     >>> Martin Kouba
>     >>> Software Engineer
>     >>> Red Hat, Czech Republic
>     >>>
>     >>> _______________________________________________
>     >>> cdi-dev mailing list
>     >>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>     <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>     >>>
>     >>> Note that for all code provided on this list, the provider
>     licenses the
>     >>> code under the Apache License, Version 2
>     (http://www.apache.org/license
>     >>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>     >>> provider waives all patent and other intellectual property
>     rights inherent
>     >>> in such information.
>     >>>
>     >>> End of cdi-dev Digest, Vol 71, Issue 29
>     >>> ***************************************
>     >>>
>     >>
>     >> ------------------------------
>     >> NOTICE: This e-mail message and any attachments may contain
>     confidential,
>     >> proprietary, and/or privileged information which should be treated
>     >> accordingly. If you are not the intended recipient, please notify the
>     >> sender immediately by return e-mail, delete this message, and
>     destroy all
>     >> physical and electronic copies. Thank you.
>     >>
>     >
>     > ------------------------------
>     > NOTICE: This e-mail message and any attachments may contain
>     confidential,
>     > proprietary, and/or privileged information which should be treated
>     > accordingly. If you are not the intended recipient, please notify the
>     > sender immediately by return e-mail, delete this message, and
>     destroy all
>     > physical and electronic copies. Thank you.
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/2a46a64a/attachment-0001.html
>     <http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/2a46a64a/attachment-0001.html>
>
>     ------------------------------
>
>     Message: 2
>     Date: Wed, 19 Oct 2016 10:13:38 +0200
>     From: Martin Kouba <mkouba at redhat.com <mailto:mkouba at redhat.com>>
>     Subject: [cdi-dev] Team mentions on github
>     To: cdi-dev <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>     Message-ID: <0ab85968-f073-9cec-7a31-c84c4c540d42 at redhat.com
>     <mailto:0ab85968-f073-9cec-7a31-c84c4c540d42 at redhat.com>>
>     Content-Type: text/plain; charset=iso-8859-2; format=flowed
>
>     Dear EG,
>
>     I've just found a github feature called "team mentions" [1]. It allows
>     to reference (send notifications to) every member of a team. The syntax
>     is: @orgname/teamname.
>
>     In cdi-spec organization there is a team called EG [2]. Sometimes it
>     might be useful to reference this team e.g. when a PR is changed/needs
>     review of EG.
>
>     I've added several active members and invited few others. Feel free to
>     accept/reject invitation or send request to join the team.
>
>     To reference the EG team in comments/issues: @cdi-spec/eg
>
>     Thanks,
>
>     Martin
>
>     [1]
>     https://guides.github.com/features/issues/#mentions
>     <https://guides.github.com/features/issues/#mentions>
>
>     [2]
>     https://github.com/orgs/cdi-spec/teams/eg
>     <https://github.com/orgs/cdi-spec/teams/eg>
>
>
>     ------------------------------
>
>     Message: 3
>     Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT)
>     From: "Martin Kouba (JIRA)" <issues at jboss.org <mailto:issues at jboss.org>>
>     Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with
>             @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
>     To: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     Message-ID:
>             <JIRA.12644548.1472028968000.16322.1476865320549 at Atlassian.JIRA>
>     Content-Type: text/plain; charset=UTF-8
>
>
>          [
>     https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>     <https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel>
>     ]
>
>     Martin Kouba reassigned CDI-625:
>     --------------------------------
>
>         Assignee: Martin Kouba
>
>
>     > When exactly are events with @Initialized(X.class) and
>     @Destroyed(X.class) qualifiers fired
>     >
>     -------------------------------------------------------------------------------------------
>     >
>     >                 Key: CDI-625
>     >                 URL: https://issues.jboss.org/browse/CDI-625
>     <https://issues.jboss.org/browse/CDI-625>
>     >             Project: CDI Specification Issues
>     >          Issue Type: Clarification
>     >          Components: Events
>     >            Reporter: Martin Kouba
>     >            Assignee: Martin Kouba
>     >              Labels: F2F2016
>     >             Fix For: 2.0 .Final
>     >
>     >
>     > The spec states that {{@Initialized(X.class)}} is fired when a
>     context is initialized and {{@Destroyed(X.class)}} when a context is
>     destroyed (note that for {{@ApplicationScoped}} the wording leaves
>     out the context: _"when the application is destroyed"_).
>     > Does it mean that:
>     > * {{@Initialized(X.class)}} is fired *after the initialization* of
>     a context is finished, i.e. the context is ready?
>     > * {{@Destroyed(X.class)}} is fired *after the destruction* of a
>     context is finished, i.e. after all the beans are destroyed?
>     > I'm asking because for {{@Destroyed(X.class)}} it might be useful
>     to perform some cleanup before the context is actually destroyed -
>     see also CDI-601.
>     > In RI/Weld, the behaivour of
>     {{@Destroyed(ApplicationScoped.class)}} is currently a little bit
>     inconsistent. For webapps and Weld SE, the event is fired before the
>     context is destroyed. But for non-web EE modules (e.g. ejb jar) the
>     event is fired after the context is destroyed.
>     > I believe this should be more clear.
>
>
>
>     --
>     This message was sent by Atlassian JIRA
>     (v6.4.11#64026)
>
>
>     ------------------------------
>
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>     <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
>     Note that for all code provided on this list, the provider licenses
>     the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html
>     <http://www.apache.org/licenses/LICENSE-2.0.html>).  For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>
>     End of cdi-dev Digest, Vol 71, Issue 32
>     ***************************************
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


More information about the cdi-dev mailing list