<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:50510B0D.7000406@redhat.com" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="bburke@redhat.com" photoname="Bill Burke"
src="cid:part1.02000909.09070207@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:bburke@redhat.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Bill Burke</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
8:22 AM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<br>
<br>On 9/12/2012 6:02 PM, Stuart Douglas wrote:
<br><blockquote type="cite"><br>
<br><blockquote type="cite">Bill Burke <a class="moz-txt-link-rfc2396E" href="mailto:bburke@redhat.com"><mailto:bburke@redhat.com></a>
<br>13 September 2012 5:37 AM
<br>On 9/12/2012 2:39 PM, Jason Greene wrote:
<br><blockquote type="cite">On Sep 12, 2012, at 1:13 PM, Bill
Burke<a class="moz-txt-link-rfc2396E" href="mailto:bburke@redhat.com"><bburke@redhat.com></a> wrote:
<br>
<br><blockquote type="cite">I'm sending this here before I submit a
JIRA.
<br>
<br>JAX-RS deployments need to import more dependencies, specifically:
<br>
<br>* the jackson libraries
<br>* Apache Http Client 4 libraries
<br>
<br>Jackson and HC4 are often used within jax-rs deployments because
users
<br>need to add additional configuration and initialization that can
only be
<br>done programmatically.
<br></blockquote>OK but are you sure you want to support direct usage of
those libraries? Part of the reason why we don't re-export third party
libs we use is because we want the flexibility to upgrade/drop/replace,
and we don't want to support a user using say google collections, just
because we made use of it in our code base.
<br>
<br>(In case it sounds that way, I'm not arguing against you, I am just
legitimately asking if you want to worry about maintenance of those
items. If so no problem)
<br></blockquote>
<br>Yes, we have to expose and support direct usage. They are both
<br>intricate in developing JAX-RS applications. Resteasy client
framework
<br>is just a layer on top of Apache HC. For example, we rely on HC4
APIs
<br>to set up user/password and other authentication settings. Jackson
<br>annotations are used a lot as well as creating
<br>ObjectMapper's(JAXBContext equivalent) directly that are plugged in
<br>through JAX-RS apis (ContextResolver).
<br>
<br>I want to really apologize for not checking up on this months and
months
<br>ago. I incorrectly assumed that things would just work and be
exposed
<br>as they were in AS6. A lot of this is related to my lack of
<br>understanding of the module system too.
<br>
<br><blockquote type="cite"><blockquote type="cite">Another thing:
<br>
<br>Can modules be declared with empty <resources>? It would be
cool if we
<br>could have a resteasy module with which all it did was define what
<br>modules it would export to a deployment. Right now this metadata is
<br>hardcoded, correct? This sucks for multiple reasons. One: users
will
<br>have to manually define a lot of module dependencies, or they will
end
<br>up including resteasy and thirdparty libraries that may conflict and
<br>cause CCEs. Two: Its very hard for me to provide a patch to AS7 if
I
<br>want to provide *ALL* features that come with the resteasy
distribution.
<br> Sure I could include and export everything within the current
resteasy
<br>default module, but I would rather have separate modules for these
features.
<br></blockquote>Sure we do that for javaee for example (aggregation
modules). If you would like to make an aggregate for JAX-RS thats fine,
the only problem is you will prevent people from being able to exclude
anything in that list. So to use an example if you add apache http
client 4.1, and a user decides they want 3.0 or 5.0, they would have to
exclude the aggregate module, and then include everything in it except
http client. You could also do various different common combinations.
<br></blockquote>
<br>I just don't see a way around it. Couldn't they also just modify
the
<br>aggregation module? Maybe you need to add a feature to JBoss
Modules
<br>that allows a deployment to override the version of an exported
dependency?
<br></blockquote>
<br>If these are just added to the deployment as dependencies via the
<br>JaxrsDependencyProcessor then they can be excluded and overridden by
an
<br>entry in jboss-deployment-structure.xml. If you make one big
aggregation
<br>module you loose that flexibility.
<br>
<br></blockquote>
<br>
<br>If we changed the JaxrsDependencyProcessor to import Apache HC 4.1.
How
would the user upgrade to Apache HC 4.2? Do they not have to create a
new module for 4.2 and import it within their
jboss-deployment-structure.xml? Why not have them do one more step and
work with the aggregate module instead? They can always version the
aggregate module too, right? If they get used to working with an
aggregate module, isn't it a lot easier for them to support multiple
different versions of Resteasy for different applications?
<br></div>
</blockquote>
<br>
The user should be able to exclude the Apache HC 4.1 (and any Resteasy
modules that depend on it) in jboss-deployment-structure.xml and then
bundle 4.2 and any other Resteasy modules directly in their application.
This way they do not have to actually modify the app server. <br>
<br>
Stuart<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:50510B0D.7000406@redhat.com" type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<br>
<br><blockquote type="cite">I'm not saying that this is necessarily a
massive problem, but that is
<br>the price you pay for using an aggregation module.
<br>
<br>Something else we could potentially look at supporting is container
<br>integration for bundled Resteasy, so if you include the Resteasy
jars in
<br>your application the scanning + EE integration code will still run,
but
<br>it will not add dependencies on the containers Resteasy jars.
<br>
<br></blockquote>
<br>What do we do for similar situations involving hibernate,
infinispan,
and other popular projects?
<br>
<br>
<br></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="stuart.w.douglas@gmail.com" photoname="Stuart Douglas"
src="cid:part2.03030808.02030801@gmail.com" name="postbox-contact.jpg"
height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:stuart.w.douglas@gmail.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Stuart Douglas</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
8:02 AM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<br>
<br>
<blockquote type="cite" cite="mid:5050E45D.3030908@redhat.com"
style="border: 0px none;">
<div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
moz-do-not-send="true" name="compose-unknown-contact.jpg"
src="cid:part1.02000909.09070207@gmail.com" photoname="Bill Burke"
photoaddress="bburke@redhat.com" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;" href="mailto:bburke@redhat.com" moz-do-not-send="true">Bill
Burke</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
5:37 AM</span></font></div></div></div>
<div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136,
136, 136); margin-left: 24px;
margin-right: 24px;"><pre wrap="">On 9/12/2012 2:39 PM, Jason Greene wrote:
</pre><blockquote type="cite"><pre wrap="">On Sep 12, 2012, at 1:13 PM, Bill Burke <a moz-do-not-send="true" href="mailto:bburke@redhat.com" class="moz-txt-link-rfc2396E"><bburke@redhat.com></a> wrote:
</pre><blockquote type="cite"><pre wrap="">I'm sending this here before I submit a JIRA.
JAX-RS deployments need to import more dependencies, specifically:
* the jackson libraries
* Apache Http Client 4 libraries
Jackson and HC4 are often used within jax-rs deployments because users
need to add additional configuration and initialization that can only be
done programmatically.
</pre></blockquote><pre wrap="">OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base.
(In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem)
</pre></blockquote><pre wrap=""><!---->
Yes, we have to expose and support direct usage. They are both
intricate in developing JAX-RS applications. Resteasy client framework
is just a layer on top of Apache HC. For example, we rely on HC4 APIs
to set up user/password and other authentication settings. Jackson
annotations are used a lot as well as creating
ObjectMapper's(JAXBContext equivalent) directly that are plugged in
through JAX-RS apis (ContextResolver).
I want to really apologize for not checking up on this months and months
ago. I incorrectly assumed that things would just work and be exposed
as they were in AS6. A lot of this is related to my lack of
understanding of the module system too.
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Another thing:
Can modules be declared with empty <resources>? It would be cool if we
could have a resteasy module with which all it did was define what
modules it would export to a deployment. Right now this metadata is
hardcoded, correct? This sucks for multiple reasons. One: users will
have to manually define a lot of module dependencies, or they will end
up including resteasy and thirdparty libraries that may conflict and
cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I
want to provide *ALL* features that come with the resteasy distribution.
Sure I could include and export everything within the current resteasy
default module, but I would rather have separate modules for these features.
</pre></blockquote><pre wrap="">Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations.
</pre></blockquote><pre wrap=""><!---->
I just don't see a way around it. Couldn't they also just modify the
aggregation module? Maybe you need to add a feature to JBoss Modules
that allows a deployment to override the version of an exported dependency?</pre></div>
</blockquote>
<br>
If these are just added to the deployment as dependencies via the
JaxrsDependencyProcessor then they can be excluded and overridden by an
entry in jboss-deployment-structure.xml. If you make one big aggregation
module you loose that flexibility. <br>
<br>
I'm not saying that this is necessarily a massive problem, but that is
the price you pay for using an aggregation module. <br>
<br>
Something else we could potentially look at supporting is container
integration for bundled Resteasy, so if you include the Resteasy jars in
your application the scanning + EE integration code will still run, but
it will not add dependencies on the containers Resteasy jars. <br>
<br>
Stuart<br>
<blockquote type="cite" cite="mid:5050E45D.3030908@redhat.com"
style="border: 0px none;">
<div class="__pbConvBody" __pbrmquotes="true"
style="color:#888888;margin-left:24px;margin-right:24px;">
<blockquote type="cite"><blockquote type="cite"><pre wrap="">Another alternative could be to only distribute and export the core
resteasy modules with AS7. Then, users would just include other
resteasy features/components/jars directly within their deployments.
</pre></blockquote><pre wrap="">Yeah that could work as well.
</pre></blockquote><pre wrap=""><!---->
What do you think is better and would create less headaches for users?
An aggregate module? Or just ship with core resteasy? I think we may
be stuck with an aggregate module as the alternative would break
backward compatibility?
</pre></div>
<div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
moz-do-not-send="true" name="compose-unknown-contact.jpg"
src="cid:part1.02000909.09070207@gmail.com" photoname="Jason Greene"
photoaddress="jason.greene@redhat.com" height="25px" width="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;" href="mailto:jason.greene@redhat.com"
moz-do-not-send="true">Jason Greene</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
4:39 AM</span></font></div></div></div>
<div class="__pbConvBody" __pbrmquotes="true"
style="color:#888888;margin-left:24px;margin-right:24px;"><pre wrap="">On Sep 12, 2012, at 1:13 PM, Bill Burke <a moz-do-not-send="true" href="mailto:bburke@redhat.com" class="moz-txt-link-rfc2396E"><bburke@redhat.com></a> wrote:
</pre><blockquote type="cite"><pre wrap="">I'm sending this here before I submit a JIRA.
JAX-RS deployments need to import more dependencies, specifically:
* the jackson libraries
* Apache Http Client 4 libraries
Jackson and HC4 are often used within jax-rs deployments because users
need to add additional configuration and initialization that can only be
done programmatically.
</pre></blockquote><pre wrap=""><!---->
OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base.
(In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem)
</pre><blockquote type="cite"><pre wrap="">Another thing:
Can modules be declared with empty <resources>? It would be cool if we
could have a resteasy module with which all it did was define what
modules it would export to a deployment. Right now this metadata is
hardcoded, correct? This sucks for multiple reasons. One: users will
have to manually define a lot of module dependencies, or they will end
up including resteasy and thirdparty libraries that may conflict and
cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I
want to provide *ALL* features that come with the resteasy distribution.
Sure I could include and export everything within the current resteasy
default module, but I would rather have separate modules for these features.
</pre></blockquote><pre wrap=""><!---->
Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations.
</pre><blockquote type="cite"><pre wrap="">Another alternative could be to only distribute and export the core
resteasy modules with AS7. Then, users would just include other
resteasy features/components/jars directly within their deployments.
</pre></blockquote><pre wrap=""><!---->
Yeah that could work as well.
_______________________________________________
jboss-as7-dev mailing list
<a moz-do-not-send="true" href="mailto:jboss-as7-dev@lists.jboss.org" class="moz-txt-link-abbreviated">jboss-as7-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" class="moz-txt-link-freetext">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
</pre></div>
<div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
moz-do-not-send="true" name="compose-unknown-contact.jpg"
src="cid:part1.02000909.09070207@gmail.com" photoname="Bill Burke"
photoaddress="bburke@redhat.com" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;" href="mailto:bburke@redhat.com" moz-do-not-send="true">Bill
Burke</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
4:13 AM</span></font></div></div></div>
<div class="__pbConvBody" __pbrmquotes="true"
style="color:#888888;margin-left:24px;margin-right:24px;"><div>I'm
sending this here
before I submit a JIRA.<br><br>JAX-RS deployments need to import more
dependencies, specifically:<br><br>* the jackson libraries<br>* Apache
Http Client 4 libraries<br><br>Jackson and HC4 are often used within
jax-rs deployments because users <br>need to add additional
configuration and initialization that can only be <br>done
programmatically.<br><br>Another thing:<br><br>Can modules be declared
with empty <resources>? It would be cool if we <br>could have a
resteasy module with which all it did was define what <br>modules it
would export to a deployment. Right now this metadata is <br>hardcoded,
correct? This sucks for multiple reasons. One: users will <br>have to
manually define a lot of module dependencies, or they will end <br>up
including resteasy and thirdparty libraries that may conflict and <br>cause
CCEs. Two: Its very hard for me to provide a patch to AS7 if I <br>want
to provide *ALL* features that come with the resteasy distribution. <br>
Sure I could include and export everything within the current resteasy
<br>default module, but I would rather have separate modules for these
features.<br><br>Another alternative could be to only distribute and
export the core <br>resteasy modules with AS7. Then, users would just
include other <br>resteasy features/components/jars directly within
their deployments.<br><br></div></div>
</blockquote>
</div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="bburke@redhat.com" photoname="Bill Burke"
src="cid:part1.02000909.09070207@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:bburke@redhat.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Bill Burke</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
5:37 AM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><pre wrap="">On 9/12/2012 2:39 PM, Jason Greene wrote:
</pre><blockquote type="cite"><pre wrap="">On Sep 12, 2012, at 1:13 PM, Bill Burke <a class="moz-txt-link-rfc2396E" href="mailto:bburke@redhat.com"><bburke@redhat.com></a> wrote:
</pre><blockquote type="cite"><pre wrap="">I'm sending this here before I submit a JIRA.
JAX-RS deployments need to import more dependencies, specifically:
* the jackson libraries
* Apache Http Client 4 libraries
Jackson and HC4 are often used within jax-rs deployments because users
need to add additional configuration and initialization that can only be
done programmatically.
</pre></blockquote><pre wrap="">OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base.
(In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem)
</pre></blockquote><pre wrap=""><!---->
Yes, we have to expose and support direct usage. They are both
intricate in developing JAX-RS applications. Resteasy client framework
is just a layer on top of Apache HC. For example, we rely on HC4 APIs
to set up user/password and other authentication settings. Jackson
annotations are used a lot as well as creating
ObjectMapper's(JAXBContext equivalent) directly that are plugged in
through JAX-RS apis (ContextResolver).
I want to really apologize for not checking up on this months and months
ago. I incorrectly assumed that things would just work and be exposed
as they were in AS6. A lot of this is related to my lack of
understanding of the module system too.
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Another thing:
Can modules be declared with empty <resources>? It would be cool if we
could have a resteasy module with which all it did was define what
modules it would export to a deployment. Right now this metadata is
hardcoded, correct? This sucks for multiple reasons. One: users will
have to manually define a lot of module dependencies, or they will end
up including resteasy and thirdparty libraries that may conflict and
cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I
want to provide *ALL* features that come with the resteasy distribution.
Sure I could include and export everything within the current resteasy
default module, but I would rather have separate modules for these features.
</pre></blockquote><pre wrap="">Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations.
</pre></blockquote><pre wrap=""><!---->
I just don't see a way around it. Couldn't they also just modify the
aggregation module? Maybe you need to add a feature to JBoss Modules
that allows a deployment to override the version of an exported dependency?
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Another alternative could be to only distribute and export the core
resteasy modules with AS7. Then, users would just include other
resteasy features/components/jars directly within their deployments.
</pre></blockquote><pre wrap="">Yeah that could work as well.
</pre></blockquote><pre wrap=""><!---->
What do you think is better and would create less headaches for users?
An aggregate module? Or just ship with core resteasy? I think we may
be stuck with an aggregate module as the alternative would break
backward compatibility?
</pre></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="jason.greene@redhat.com" photoname="Jason Greene"
src="cid:part1.02000909.09070207@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:jason.greene@redhat.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Jason Greene</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
4:39 AM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><pre wrap="">On Sep 12, 2012, at 1:13 PM, Bill Burke <a class="moz-txt-link-rfc2396E" href="mailto:bburke@redhat.com"><bburke@redhat.com></a> wrote:
</pre><blockquote type="cite"><pre wrap="">I'm sending this here before I submit a JIRA.
JAX-RS deployments need to import more dependencies, specifically:
* the jackson libraries
* Apache Http Client 4 libraries
Jackson and HC4 are often used within jax-rs deployments because users
need to add additional configuration and initialization that can only be
done programmatically.
</pre></blockquote><pre wrap=""><!---->
OK but are you sure you want to support direct usage of those libraries? Part of the reason why we don't re-export third party libs we use is because we want the flexibility to upgrade/drop/replace, and we don't want to support a user using say google collections, just because we made use of it in our code base.
(In case it sounds that way, I'm not arguing against you, I am just legitimately asking if you want to worry about maintenance of those items. If so no problem)
</pre><blockquote type="cite"><pre wrap="">Another thing:
Can modules be declared with empty <resources>? It would be cool if we
could have a resteasy module with which all it did was define what
modules it would export to a deployment. Right now this metadata is
hardcoded, correct? This sucks for multiple reasons. One: users will
have to manually define a lot of module dependencies, or they will end
up including resteasy and thirdparty libraries that may conflict and
cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I
want to provide *ALL* features that come with the resteasy distribution.
Sure I could include and export everything within the current resteasy
default module, but I would rather have separate modules for these features.
</pre></blockquote><pre wrap=""><!---->
Sure we do that for javaee for example (aggregation modules). If you would like to make an aggregate for JAX-RS thats fine, the only problem is you will prevent people from being able to exclude anything in that list. So to use an example if you add apache http client 4.1, and a user decides they want 3.0 or 5.0, they would have to exclude the aggregate module, and then include everything in it except http client. You could also do various different common combinations.
</pre><blockquote type="cite"><pre wrap="">Another alternative could be to only distribute and export the core
resteasy modules with AS7. Then, users would just include other
resteasy features/components/jars directly within their deployments.
</pre></blockquote><pre wrap=""><!---->
Yeah that could work as well.
_______________________________________________
jboss-as7-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
</pre></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="bburke@redhat.com" photoname="Bill Burke"
src="cid:part1.02000909.09070207@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:bburke@redhat.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Bill Burke</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">13 September 2012
4:13 AM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div>I'm sending this here
before I submit a JIRA.<br><br>JAX-RS deployments need to import more
dependencies, specifically:<br><br>* the jackson libraries<br>* Apache
Http Client 4 libraries<br><br>Jackson and HC4 are often used within
jax-rs deployments because users <br>need to add additional
configuration and initialization that can only be <br>done
programmatically.<br><br>Another thing:<br><br>Can modules be declared
with empty <resources>? It would be cool if we <br>could have a
resteasy module with which all it did was define what <br>modules it
would export to a deployment. Right now this metadata is <br>hardcoded,
correct? This sucks for multiple reasons. One: users will <br>have to
manually define a lot of module dependencies, or they will end <br>up
including resteasy and thirdparty libraries that may conflict and <br>cause
CCEs. Two: Its very hard for me to provide a patch to AS7 if I <br>want
to provide *ALL* features that come with the resteasy distribution. <br>
Sure I could include and export everything within the current resteasy
<br>default module, but I would rather have separate modules for these
features.<br><br>Another alternative could be to only distribute and
export the core <br>resteasy modules with AS7. Then, users would just
include other <br>resteasy features/components/jars directly within
their deployments.<br><br></div></div>
</blockquote>
</body></html>