[wildfly-dev] Dependency Changes

[Tomaž Cerar]

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 at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131018/5b80690b/attachment.html