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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev