5:37 a.m.
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/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.
> >
>
> --
> 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.