10:57 p.m.
On 17 Oct, 2013, at 19:55, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
So every module is explicitly listing all its dependencies (fine) and
then the main pom has exlusions for all of them to prevent transitive dependencies between
modules? Ugh.
Yeah, pretty much. It really might not be worth it which is why I wanted to bring it up
before I continued down the path. Maybe one idea would be to exclude only things like the
logmanager, but allow transitive dependencies for org.wildfly and probably DMR and MSC.
Are some of these modules even a problem? I don't see how management-client-content
or host-controller or patching would be in the dependency set for the client jar poms.
The two client jars that were an issue actually weren't a result of anything in
WildFly. I just started going through it and opened this lovely can of worms.
I so pray for the day when Maven finally just has reasonable flags to turn off transitive
dependencies.
That would be awesome. Like a compile scope that actually means, I don't know compile
not runtime :)
On 10/17/13 9:40 PM, James Perkins wrote:
> 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.
> --
> James R. Perkins
> JBoss by Red Hat
>
> Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
>
> Can you explain more as to what this patch is doing? Partly it seems to
> be directly declaring some dependencies in WF modules instead of having
> them coming in transitively from other WF modules. Which is ok by me if
> the module directly imports classes from the dependency. But I don't
> know what practical difference this change makes.
>
> I don't get (or like) the exclusions in the main pom.xml at all.
>
> On 10/17/13 8:06 PM, James R. Perkins wrote:
>> Debugging a TCK issue I found that the client jars that shade in their
>> dependencies were also pulling in the logmanager transitively from a
>> couple dependencies. This led to look at what else was coming in
>> transitively and realized, as we probably already know, it goes deep.
>>
>> I started making some changes [1] after talking to David (which I may
>> have misunderstood so don't blame him :)) to exclude dependencies for
>> WildFly maven modules. I'm not really close to be done as it seems this
>> will take quite a while. The question is do we even want to exclude
>> dependencies like this? If I continued and did a PR would it be
>> accepted? I have a feeling it's going to be quite massive.
>>
>> [1]: https://github.com/jamezp/wildfly/compare/WFLY-2332
>>
>> --
>> James R. Perkins
>> Red Hat JBoss Middleware
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
--
James R. Perkins
JBoss by Red Hat