Forcing "provided" for some dependencies

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

Forcing "provided" for some dependencies

jedrzej.dudkiewicz
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

jedrzej.dudkiewicz
Thanks for an answer.

Yes, I can do it like this, but I'd like to avoid listing all dependencies. Is there any way to do it? For hawtio, there are 28 dependencies that I have to list, and in some other there are even more. I thought that it should be possible to do it automatically somehow.

JD


> -----Original Message-----
> From: Xeno Amess <[hidden email]>
> Sent: Wednesday, September 2, 2020 8:12 AM
> To: Maven Developers List <[hidden email]>
> Subject: Re: Forcing "provided" for some dependencies
>
> 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
> > >
> > >
> > >
> > >
> > >
> > >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]