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

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&gt; 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 >

On 17 Oct, 2013, at 19:55, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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&gt; 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

On 10/18/2013 07:51 AM, Brian Stansberry wrote: > > Back to my original question then. What problem is this patch solving? I > don't like how maven handles transitive dependencies, but it's a huge > effort to try and fight maven, IMHO not worth it unless it's solving a > specific problem.

> > The server-side runtime dependencies are controlled via the module.xml > files, which, thankfully, have a sane approach to dependency management. > So I think we only need to worry about runtime for the few things where > the pom is actually relevant to runtime; stuff like > model-controller-client or the client jar poms. > > BTW, please don't take my responses as being critical of the patch or > the thread. You're correctly asking the same questions I am -- "is this > worth it?" Well I feel like I should clarify something. When I originally started the "exclude everything" policy, I was only excluding dependencies *from* dependencies, not from the core modules. I don't think adding exclusions in dependencies on core modules buys anything because they themselves already have exclusions for things.

>>> 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 :) That's called "provided".

>>> 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&gt; 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 >> >> >> >

Why don't you just configure shade plugin to use only specified dependencies and exclude everything else?

On Fri, Oct 18, 2013 at 5:53 PM, James R. Perkins <jperkins(a)redhat.com <mailto:jperkins@redhat.com>> wrote: On 10/18/2013 06:17 AM, David M. Lloyd wrote: > On 10/18/2013 07:51 AM, Brian Stansberry wrote: >> >> Back to my original question then. What problem is this patch solving? I >> don't like how maven handles transitive dependencies, but it's a huge >> effort to try and fight maven, IMHO not worth it unless it's solving a >> specific problem. The original problem I saw just just the logmanager leaking into the shaded client jars. When I ran the dependency tree I noticed just about every core module had a transitive dependency on the logmanager. It got me thinking about what else might be leaked in and it sounds like I had misunderstood what David meant. End result, nothing to see here move along. :) >> >> The server-side runtime dependencies are controlled via the module.xml >> files, which, thankfully, have a sane approach to dependency management. >> So I think we only need to worry about runtime for the few things where >> the pom is actually relevant to runtime; stuff like >> model-controller-client or the client jar poms. >> >> BTW, please don't take my responses as being critical of the patch or >> the thread. You're correctly asking the same questions I am -- "is this >> worth it?" > Well I feel like I should clarify something. When I originally started > the "exclude everything" policy, I was only excluding dependencies > *from* dependencies, not from the core modules. I don't think adding > exclusions in dependencies on core modules buys anything because they > themselves already have exclusions for things. Makes sense. I do think I will add exclusions to core modules that use the logmanager. I don't think there are any other dependencies that really matter if they leak in, but one less choice of a Logger when auto-completing in an IDE might be nice. > >>>> 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 :) > That's called "provided". Yeah, it's just not as intuitive as compile time and bites people all the time. For example looking through the pom's I found a few spots where jboss-logging was marked as provided when it should likely not be since it is required at runtime. I've also seen cases where the logging tooling wasn't marked as provided when it should be since it's only needed at compile time :) > >>>> 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 <mailto:brian.stansberry@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 <mailto:wildfly-dev@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 >>> >>> >>> >> > -- James R. Perkins Red Hat JBoss Middleware _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev