<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/18/2013 09:28 AM, Tomaž Cerar
wrote:<br>
</div>
<blockquote
cite="mid:CAMquZP7ay3XXgFpewT5r5D5bTtk=NfJNZrMuM5A7Jyfj4wUwxw@mail.gmail.com"
type="cite">
<div dir="ltr">Why don't you just configure shade plugin to use
only specified dependencies and exclude everything else?<br>
</div>
</blockquote>
That would work, but it's more that it opened the question in my
mind what else is coming in transitively. The two client jar's I'm
aware of do this, but they both brought in a transitive dependency
on the logmanager. The exclusion though should happen in the
dependency management of the parent pom not the shade configuration
though.<br>
<blockquote
cite="mid:CAMquZP7ay3XXgFpewT5r5D5bTtk=NfJNZrMuM5A7Jyfj4wUwxw@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Oct 18, 2013 at 5:53 PM, James
R. Perkins <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 10/18/2013 06:17 AM, David M. Lloyd wrote:<br>
> On 10/18/2013 07:51 AM, Brian Stansberry wrote:<br>
>><br>
</div>
<div class="im">>> Back to my original question then.
What problem is this patch solving? I<br>
>> don't like how maven handles transitive
dependencies, but it's a huge<br>
>> effort to try and fight maven, IMHO not worth it
unless it's solving a<br>
>> specific problem.<br>
</div>
The original problem I saw just just the logmanager leaking
into the<br>
shaded client jars. When I ran the dependency tree I noticed
just about<br>
every core module had a transitive dependency on the
logmanager. It got<br>
me thinking about what else might be leaked in and it sounds
like I had<br>
misunderstood what David meant. End result, nothing to see
here move<br>
along. :)<br>
<div class="im">>><br>
>> The server-side runtime dependencies are
controlled via the module.xml<br>
>> files, which, thankfully, have a sane approach to
dependency management.<br>
>> So I think we only need to worry about runtime
for the few things where<br>
>> the pom is actually relevant to runtime; stuff
like<br>
>> model-controller-client or the client jar poms.<br>
>><br>
>> BTW, please don't take my responses as being
critical of the patch or<br>
>> the thread. You're correctly asking the same
questions I am -- "is this<br>
>> worth it?"<br>
> Well I feel like I should clarify something. When I
originally started<br>
> the "exclude everything" policy, I was only excluding
dependencies<br>
> *from* dependencies, not from the core modules. I
don't think adding<br>
> exclusions in dependencies on core modules buys
anything because they<br>
> themselves already have exclusions for things.<br>
</div>
Makes sense. I do think I will add exclusions to core
modules that use<br>
the logmanager. I don't think there are any other
dependencies that<br>
really matter if they leak in, but one less choice of a
Logger when<br>
auto-completing in an IDE might be nice.<br>
<div class="im">><br>
>>>> I so pray for the day when Maven finally
just has reasonable flags to turn off transitive
dependencies.<br>
>>> That would be awesome. Like a compile scope
that actually means, I don't know compile not runtime :)<br>
> That's called "provided".<br>
</div>
Yeah, it's just not as intuitive as compile time and bites
people all<br>
the time. For example looking through the pom's I found a
few spots<br>
where jboss-logging was marked as provided when it should
likely not be<br>
since it is required at runtime. I've also seen cases where
the logging<br>
tooling wasn't marked as provided when it should be since
it's only<br>
needed at compile time :)<br>
<div class="HOEnZb">
<div class="h5">><br>
>>>> On 10/17/13 9:40 PM, James Perkins
wrote:<br>
>>>>> Yes that was basically the idea.
The main benefit is dependencies, like the log manager,
won't leak into projects that shouldn't use them. It
might be more work than it's worth.<br>
>>>>> --<br>
>>>>> James R. Perkins<br>
>>>>> JBoss by Red Hat<br>
>>>>><br>
>>>>> Brian Stansberry <<a
moz-do-not-send="true"
href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>>
wrote:<br>
>>>>><br>
>>>>> Can you explain more as to what
this patch is doing? Partly it seems to<br>
>>>>> be directly declaring some
dependencies in WF modules instead of having<br>
>>>>> them coming in transitively from
other WF modules. Which is ok by me if<br>
>>>>> the module directly imports classes
from the dependency. But I don't<br>
>>>>> know what practical difference this
change makes.<br>
>>>>><br>
>>>>> I don't get (or like) the
exclusions in the main pom.xml at all.<br>
>>>>><br>
>>>>> On 10/17/13 8:06 PM, James R.
Perkins wrote:<br>
>>>>>> Debugging a TCK issue I found
that the client jars that shade in their<br>
>>>>>> dependencies were also pulling
in the logmanager transitively from a<br>
>>>>>> couple dependencies. This led
to look at what else was coming in<br>
>>>>>> transitively and realized, as
we probably already know, it goes deep.<br>
>>>>>><br>
>>>>>> I started making some changes
[1] after talking to David (which I may<br>
>>>>>> have misunderstood so don't
blame him :)) to exclude dependencies for<br>
>>>>>> WildFly maven modules. I'm not
really close to be done as it seems this<br>
>>>>>> will take quite a while. The
question is do we even want to exclude<br>
>>>>>> dependencies like this? If I
continued and did a PR would it be<br>
>>>>>> accepted? I have a feeling it's
going to be quite massive.<br>
>>>>>><br>
>>>>>> [1]: <a moz-do-not-send="true"
href="https://github.com/jamezp/wildfly/compare/WFLY-2332"
target="_blank">https://github.com/jamezp/wildfly/compare/WFLY-2332</a><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> James R. Perkins<br>
>>>>>> Red Hat JBoss Middleware<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>> wildfly-dev mailing list<br>
>>>>>> <a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>>> --<br>
>>>> Brian Stansberry<br>
>>>> Principal Software Engineer<br>
>>>> JBoss by Red Hat<br>
>>> --<br>
>>> James R. Perkins<br>
>>> JBoss by Red Hat<br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
<br>
--<br>
James R. Perkins<br>
Red Hat JBoss Middleware<br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
James R. Perkins
Red Hat JBoss Middleware</pre>
</body>
</html>