Re: [cdi-dev] Team mentions on github
by Werner Keil
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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)gmail.com>
> Subject: Re: [cdi-dev] Spliting SE package in an independent jar
> To: John Ament <john.ament(a)spartasystems.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAAGawe1UavyR9qv0iOLCBHpXpuVzMcrBfDL_-bcu2deA9MZNGQ@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(a)spartasystems.com>
> wrote:
>
> > Thats why cdi-se-api depends on cdi-api.
> >
> >
> > ------------------------------
> > *From:* Werner Keil <werner.keil(a)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(a)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(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.
> org>
> >> on behalf of Werner Keil <werner.keil(a)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(a)lists.jboss.org>
> >> wrote:
> >>
> >>> Send cdi-dev mailing list submissions to
> >>> cdi-dev(a)lists.jboss.org
> >>>
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>> or, via email, send a message with subject or body 'help' to
> >>> cdi-dev-request(a)lists.jboss.org
> >>>
> >>> You can reach the person managing the list at
> >>> cdi-dev-owner(a)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(a)redhat.com>
> >>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar
> >>> To: John Ament <john.ament(a)spartasystems.com>, Antoine Sabot-Durand
> >>> <antoine(a)sabot-durand.net>, cdi-dev <
> cdi-dev(a)lists.jboss.org
> >>> >
> >>> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f(a)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(a)lists.jboss.org
> >>> > <cdi-dev-bounces(a)lists.jboss.org> on behalf of Antoine Sabot-Durand
> >>> > <antoine(a)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(a)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.
> >>> >
> >>>
> >>> --
> >>> Martin Kouba
> >>> Software Engineer
> >>> Red Hat, Czech Republic
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev(a)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/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
>
> ------------------------------
>
> Message: 2
> Date: Wed, 19 Oct 2016 10:13:38 +0200
> From: Martin Kouba <mkouba(a)redhat.com>
> Subject: [cdi-dev] Team mentions on github
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <0ab85968-f073-9cec-7a31-c84c4c540d42(a)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
>
> [2]
> 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(a)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(a)lists.jboss.org
> Message-ID:
> <JIRA.12644548.1472028968000.16322.1476865320549(a)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 ]
>
> 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
> > 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 {{(a)Initialized(X.class)}} is fired when a context
> is initialized and {{(a)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:
> > * {{(a)Initialized(X.class)}} is fired *after the initialization* of a
> context is finished, i.e. the context is ready?
> > * {{(a)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 {{(a)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 {{(a)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(a)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.
>
> End of cdi-dev Digest, Vol 71, Issue 32
> ***************************************
>
8 years, 2 months
[JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba reassigned CDI-500:
--------------------------------
Assignee: Martin Kouba
> Clarify @Intercepted Bean metadata injection for EE components
> --------------------------------------------------------------
>
> Key: CDI-500
> URL: https://issues.jboss.org/browse/CDI-500
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 2.0 .Final
>
>
> It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component.
> See the CDI spec, "5.5.8. Bean metadata":
> {quote}
> Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate:
> * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and
> * ...
> {quote}
> However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection":
> {quote}
> The component classes listed in Table EE.5-1 with support level "Standard"
> all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled—which it is by default—these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-546) Constant for default observer priority
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba reassigned CDI-546:
--------------------------------
Assignee: Martin Kouba
> Constant for default observer priority
> --------------------------------------
>
> Key: CDI-546
> URL: https://issues.jboss.org/browse/CDI-546
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Jozef Hartinger
> Assignee: Martin Kouba
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> Currently we use:
> {code:JAVA}
> @Override
> public default int getPriority() {
> return javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> };
> {code}
> It would be nice to have the value stored as a constant e.g.:
> {code:JAVA}
> int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500;
> {code}
> so that other code can reference it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-625:
-----------------------------
Sprint: Sprint 1
> 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
> 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 {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)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:
> * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{(a)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 {{(a)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 {{(a)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)
8 years, 2 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
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
> 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 {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)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:
> * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{(a)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 {{(a)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 {{(a)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)
8 years, 2 months
Team mentions on github
by Martin Kouba
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
[2]
https://github.com/orgs/cdi-spec/teams/eg
8 years, 2 months
Re: [cdi-dev] Spliting SE package in an independent jar
by Werner Keil
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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)redhat.com>
> Subject: Re: [cdi-dev] Spliting SE package in an independent jar
> To: John Ament <john.ament(a)spartasystems.com>, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net>, cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <616fdc4e-26f6-a8d7-16d3-fdceb71faa1f(a)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(a)lists.jboss.org
> > <cdi-dev-bounces(a)lists.jboss.org> on behalf of Antoine Sabot-Durand
> > <antoine(a)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(a)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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 71, Issue 29
> ***************************************
>
8 years, 2 months
