Forcing "provided" for some dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Forcing "provided" for some dependencies

jedrzej.dudkiewicz
(I'm sorry if this appears twice, I sent it two hours ago and *then* read
that if I'm not subscribed it can take "hours to days" to appear due to such
messages being moderated, so I'm resending this after subscribing).

 

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 | Threaded
Open this post in threaded view
|

Re: Forcing "provided" for some dependencies

Romain Manni-Bucau
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, <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Forcing "provided" for some dependencies

Xeno Amess
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 <[hidden email]> 于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, <[hidden email]> 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
> >
> >
> >
> >
> >
> >
>