Hi.
Sounds like what you need is exclusion?

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-vfs2</artifactId>
    <version>${commons-vfs2.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
        <exclusion>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-jdk14</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-nop</artifactId>
        </exclusion>
    </exclusions>
</dependency>



Romain Manni-Bucau <rmannibu...@gmail.com> 于2020年9月2日周三 下午2:01写道:

> Hi,
>
> I think it is risky because some dependencies are really provided so you
> should write an extension which does it for specific artifacts but then
> question will be: what about parent provided deps?
>
> Therefore my proposal would be to ask upstream projects to fix their pom or
> add a pom in their own build to provide you that feature.
>
> Le mer. 2 sept. 2020 à 07:47, <jedrzej.dudkiew...@zdalnyserwis.net.pl> a
> écrit :
>
> > Hello,
> >
> >
> >
> > I have Maven project using spring-boot that is composed of base project
> and
> > components. This is mainly runtime dependency: Base (B) provides some
> > services, and components (C1, C2, C3.) are "installed" by dropping them
> > into
> > specific directory. This works fine, but as I expected I have some
> problems
> > with dependency management in specific cases. These specific cases are as
> > follows: there are two components, lets say C1 and C2, which pack
> activemq
> > and hawtio. Components are built using very simple mechanism - I have
> > separate projects that include component's artifacts (basically my
> compiled
> > code), and specify <dependencies>. Most of dependencies are provided
> > indirectly by specifying Base (B) or other Components (C1, C2.) with
> scope
> > <proided>. They are built using maven shade plugin (so
> > "jar-with-dependencies" aka "fat jar"). The only problem I have is with
> > aforementioned "activemq" and "hawtio". They are built not from compiled
> > code but by including artifacts by dependency. That means that AFAIU
> maven
> > reads their poms and includes specified dependencies - but their scope is
> > set to "compile" (probably some are transitive and are included from
> other
> > artifacts, but it doesn't matter), so shade plugin includes quite a lot
> of
> > dependencies into created fat jar - it results in multiple instances of
> > same
> > artifacts. I can work around it by specifying in e.g. hawtio's pom.xml
> > these
> > dependencies by hand with scope "provided", but I don't think this is
> > manageable in the long run - I have 20 dependencies right now and I
> suppose
> > any new version will only require more. And now, when the situation is
> > (hopefully) clear, here goes my question:
> >
> >
> >
> > I'd like to create a plugin, that would somehow intercept dependency
> > resolution and change scope to provided if given artifact is provided by
> > (so
> > <scope>provided</scope>) any other provided artifacts. So if Base (B)
> > provides e.g. artifact A1 and hawtio requires A1 (explicitly in pom, so
> > with
> > "compile" scope), plugin would check that A1 is already provided, so it
> > would change A1's scope to "provided> - this can be also done as a
> separate
> > step, it is just that I don't know how to get my hands on full dependency
> > graph.
> >
> >
> >
> > Or maybe there is already such plugin and I just couldn't find it? Or
> maybe
> > this approach was tried and failed and I should do everything some other
> > way
> > (which means asking on other group)?
> >
> >
> >
> > Thanks in advance,
> >
> > Jędrzej Dudkiewicz
> >
> >
> >
> >
> >
> >
>

Reply via email to