We need to audit the rest as well the exclude subsystem feature was added after javaee.api
was created so there is other stuff in here that needs to be pulled out.
On Feb 7, 2014, at 4:54 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
Got it. Ok this looks like an oversight. We should remove
javax.ws.rs.api from javaee.api and have the rest easy subsystem add that API as desired.
On Feb 7, 2014, at 4:43 PM, Bill Burke <bburke(a)redhat.com> wrote:
> Not following you. Its already catagorized, isn't it? Via the implicit
> dependencies added by the jaxrs subsystem? The problem of the OP was
> that a different subsystem is adding java.ee.api. The user wanted to
> use Resteasy 3.0.6 with EAP 6 and couldn't find the magic sauce to do it.
>
> On 2/7/2014 5:35 PM, Jason Greene wrote:
>> I think the problem is that RestEasy has N extensions (plugins) per 1 subsystem.
So the generic subsystem exclude doesn’t really match.
>>
>> On Feb 7, 2014, at 4:28 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>>
>>> Right now JBoss Modules acts purely on paths, so when you import
>>> something you specify what paths to filter out. This is why I say using
>>> aggregate modules is a bad idea. It makes more sense to have a
>>> user-friendly name for conceptual imports. For example either I want
>>> resteasy (in which case I want all the imports that I need, even if I
>>> don't know I need them (and I won't if I'm a normal user)), or I
don't
>>> (in which case I want nothing). Why not categorize imports by
>>> subsystem and have the flag for the subsystem actually exclude the
>>> imports as the user expects?
>>>
>>> On 02/07/2014 04:14 PM, Bill Burke wrote:
>>>> I've had this conversation with Stuart before about resteasy
modules.
>>>> We didn't come to a conclusion as there's pro's and con's
each way.
>>>> BTW, You can't exclude exports, which is the very same problem
we're
>>>> seeing with ee spec module.
>>>>
>>>> IMO, the problem is with JBoss Modules. If you add an exclude for a
>>>> module, you should expect that module to be excluded. Even if that
>>>> module is exported by an implicit dependency.
>>>>
>>>> On 2/7/2014 4:58 PM, Tomaž Cerar wrote:
>>>>> On semi related note, why does app need direct dependancy to all 10+
>>>>> rest easy modules?
>>>>> couldn't that be done by simply having one/two dependancies that
than
>>>>> have all the other deps exported?
>>>>>
>>>>> that way it would be much easier to override whole rest easy
version.
>>>>>
>>>>> but ee spec issue still remains...
>>>>>
>>>>>
>>>>> On Fri, Feb 7, 2014 at 10:14 PM, Bill Burke <bburke(a)redhat.com
>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>
>>>>> Chris sent me this rant on overriding built in Resteasy. I
replied how
>>>>> to fix it on his blog. The biggest problem is javaee.api which
sucks in
>>>>> every EE API. Is there a reason you don't trust the
subsystems to suck
>>>>> in the EE APIs they need?
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: dzone rant on resteasy/modules
>>>>> Date: Fri, 07 Feb 2014 13:49:02 -0500
>>>>> From: Chris Bredesen <cbredesen(a)redhat.com
>>>>> <mailto:cbredesen@redhat.com>>
>>>>> To: Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
>>>>>
>>>>> Just saw this by accident, have fun!
>>>>>
>>>>>
http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s
>>>>>
>>>>> -CB
>>>>>
>>>>> --
>>>>> Chris Bredesen
>>>>> Supervisor, Software Engineering
>>>>> Red Hat Global Support Services
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>>
http://bill.burkecentral.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat