ct, then the metadata should said that the
> dependencies have been transformed that way. For modular dependencies,
> shading the artifact has major impacts: it breaks modules encapsulation,
> potentially creating security holes that did not existed in the original
> libraries. For non-mo
should said that the
dependencies have been transformed that way. For modular dependencies,
shading the artifact has major impacts: it breaks modules encapsulation,
potentially creating security holes that did not existed in the original
libraries. For non-modular dependencies, the impacts
Hi Lars,
On Mon, 13 May 2024 at 17:46, Lars Francke wrote:
> The problem is that SBOM tools have no realistic chance to gather that
> information if all they have is a final artifact and the POMs that
> were published as is the case here.
An increasing number of Maven artifacts publish
rs,
>
> ignoring your second email, I felt like it is normal for the pom to ignore
> the shaded dependencies. This is how Maven works.
> For me, it should be the job of a SBOM (CycloneDX format or SPDX for
> exemple) to keep the information of what the shaded jar contains.
> This is
Hello Lars,
ignoring your second email, I felt like it is normal for the pom to ignore
the shaded dependencies. This is how Maven works.
For me, it should be the job of a SBOM (CycloneDX format or SPDX for
exemple) to keep the information of what the shaded jar contains.
This is the role of SBOMs
> org.apache.htrace
> htrace-core4
>
>
> HTrace in version 4.2.0-incubating has a dependency on
> jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
> relocate all of its dependencies[3].
> The published POM of HTrace contains no trace of
4.2.0-incubating has a dependency on
jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
relocate all of its dependencies[3].
The published POM of HTrace contains no trace of these dependencies[4].
A vulnerability scanner like Trivy[5] does find the code via the
META-INF/maven/ files
Thank you very much, Alexander! It solved the issue!
Toshiya
On Thu, Mar 28, 2024 at 4:53 PM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:
> Shade needs an original sources JAR as input for 'createSourcesJar'. Make
> sure to add Maven Source Plugin to your build and put it above Shade
Shade needs an original sources JAR as input for 'createSourcesJar'. Make sure
to add Maven Source Plugin to your build and put it above Shade in the
'plugins' section to ensure that both of them are exeuted in the correct order
during the 'package' phase.
org.apache.maven.plugins
Hello,
I use maven-shade-plugin to create an uber jar and its source jar with
.
https://github.com/tkobayas/shade-test/blob/main/pom.xml
```
org.apache.maven.plugins
maven-shade-plugin
3.5.2
source-jar
The documentation for publishing to Central is very comprehensive. I
suggest you take a closer look. Specifically
https://central.sonatype.org/register/central-portal/
https://central.sonatype.org/publish/producer-terms/
https://repo1.maven.org/terms.html
And maybe contact a lawyer and
Fri, 1 Mar 2024, /Olivier Lamy/:
users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the sources :)
The sources uploaded to Maven Central
gin
> > > plugin-dep
> > > 42.4.2
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák
> > > wrote:
> > >
> > > > Howdy,
t; On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák
> > wrote:
> >
> > > Howdy,
> > >
> > > You would need to ask Sonatype about that, and check here:
> > > https://central.sonatype.org/publish/requirements/
> > >
> > > IMHO best to ask them about
that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repository?)
> >
> > Thank
o ask Sonatype about that, and check here:
> > https://central.sonatype.org/publish/requirements/
> >
> > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > central that has dependencies not available from Central
> > (nor any other public repositor
ed to ask Sonatype about that, and check here:
> https://central.sonatype.org/publish/requirements/
>
> IMHO best to ask them about it: IIUC you want to deploy artifacts to
> central that has dependencies not available from Central
> (nor any other public repository?)
>
> Thanks
> T
Howdy,
You would need to ask Sonatype about that, and check here:
https://central.sonatype.org/publish/requirements/
IMHO best to ask them about it: IIUC you want to deploy artifacts to
central that has dependencies not available from Central
(nor any other public repository?)
Thanks
T
be for regular dependencies and plugins, but
I'm not 100% sure about plugin dependencies in particular (although I would
guess it's the same).
Any input would be appreciated,
Best regards,
Florent
nd therefore module A will not be in the reactor. This
> is
> > > why the m2 repo will always be used for module A in this scenario.
> > >
> > > Joe
> > >
> > > -Original Message-
> > > From: Siddharth Jain
> > > Sent: Thur
m2 repo will always be used for module A in this scenario.
> >
> > Joe
> >
> > -Original Message-
> > From: Siddharth Jain
> > Sent: Thursday, February 15, 2024 7:50 PM
> > To: Maven Users List
> > Subject: Re: How does maven resolve
s List
> Subject: Re: How does maven resolve inter-module dependencies in a
> multi-module build?
>
> External Email: Please be vigilant and check the contents and source for
> signs of malicious activity.
>
> thanks Joe. but then if classes are available both in the target direct
A will not be in the reactor. This is why
the m2 repo will always be used for module A in this scenario.
Joe
-Original Message-
From: Siddharth Jain
Sent: Thursday, February 15, 2024 7:50 PM
To: Maven Users List
Subject: Re: How does maven resolve inter-module dependencies in a multi-module
build
ice that I can run mvn compile from the root directory
> and
> > it will build the 3 projects. The projects may have inter-dependencies
> > e.g., B depends on A and let's say C depends on both A and B.
> >
> > My question is while building B how does maven locate the compiled code
>
ects A, B, C and a parent pom defined in the root
> directory. I notice that I can run mvn compile from the root directory and
> it will build the 3 projects. The projects may have inter-dependencies
> e.g., B depends on A and let's say C depends on both A and B.
>
> My question is whil
Hello,
I am working on a multi-module Maven build. e.g., I have a root directory
containing 3 sub-projects A, B, C and a parent pom defined in the root
directory. I notice that I can run mvn compile from the root directory and
it will build the 3 projects. The projects may have inter-dependencies
On Wednesday, 31. January 2024, 16:34:22 CET Mansour Al Akeel wrote:
> We have a large number of legacy dependencies that we need to sign. I am
> trying to cache those that are not signed into an internal repository to
> reduce build time.
>
> So I created another project to sig
We have a large number of legacy dependencies that we need to sign. I am
trying to cache those that are not signed into an internal repository to
reduce build time.
So I created another project to sign them and load them into our private
repository. I am using a classifier to indicate the signed
On 15.12.23 18:01, David Hoffer wrote:
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
Op 15-12-2023 om 18:01 schreef David Hoffer:
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?
E.g. I have the plugin configured like this:
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
management, along with the POM it comes from—even
with line numbers. Nice!
And (drumroll …) it looks like
`biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1` is coming from
`org.apache.logging:logging-parent:10.1.1`.
And `org.mockito:mockito-inline:4.8.1` was getting in because one of my
own dependencies
In my Maven project (an aggregate project with child projects) I issue
> the following command for the Versions Maven Plugin:
>
> mvn versions:display-dependency-updates
>
> There are a couple of outdated dependencies I'm not sure where are
> coming from:
>
> [IN
> Garret
>
> > On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson
> > wrote:
> >
> >> In my Maven project (an aggregate project with child projects) I issue
> >> the following command for the Versions Maven Plugin:
> >>
> >> mvn
:04 PM Garret Wilson
wrote:
In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:
mvn versions:display-dependency-updates
There are a couple of outdated dependencies I'm not sure where are
coming from:
[INFO
Plugin:
>
> mvn versions:display-dependency-updates
>
> There are a couple of outdated dependencies I'm not sure where are
> coming from:
>
> [INFO] The following dependencies in Dependency Management have newer
> versions:
> [INFO] biz.aQute.bnd:biz.aQute.bnd.
In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:
mvn versions:display-dependency-updates
There are a couple of outdated dependencies I'm not sure where are
coming from:
[INFO] The following dependencies
Hello Siddharth
Le 2023-10-13 à 00 h 02, Siddharth Jain a écrit :
IIUC, this is a separate issue. At minimum we need to make the
behavior of compile vs. testCompile consistent. Currently it is not.
Understood, but what I think is the common point is that Maven currently
uses heuristic rules
s put in its
own module and namespace (package name) with dependencies on the main
module and junit etc.
>
>
> > I see during the test-compile phase the plugin is putting all the
> > dependencies on the module-path whereas during the main compilation it
> > only puts t
is to
duplicate the module-info.java file in the test directory [1], but this
is not the only way.
I see during the test-compile phase the plugin is putting all the
dependencies on the module-path whereas during the main compilation it
only puts those dependencies on the module-path
the plugin is putting all the dependencies on the
module-path whereas during the main compilation it only puts those
dependencies on the module-path that are declared in module-info.java; the
rest are on the classpath (which is the correct behavior). I am using
latest version of the plugin 3.11.0
I have a legacy project that requires many third party dependencies. Those
dependencies need to be signed. The resulting dependencies along with the
swing project, are to be served through a JNLP file. The fact that we need
to resign all these dependencies with every build, adds a lot of overhead
Wed, 4 Oct 2023 15:52:14 +, /Joseph Kesselman/:
My only other real gripe with Maven at the moment is that I haven't
yet found a way to tell the javadoc plugin "Yes, I know there's lots
that can be improved, but for now please consider that a Warning
rather than an Error."
If I'm not
Oh. Duh.
com.sun
tools
1.6.0
system
${toolsjar}
On 10/3/2023 10:04 PM, Alexander Kriegisch wrote:
Hi Joseph.
I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your
ext Ribbon Campaign
/\ Stamp out HTML mail!
From: Alexander Kriegisch
Sent: Tuesday, October 3, 2023 10:04:33 PM
To: users@maven.apache.org
Subject: Re: "First time caller..." javadoc taglet dependencies?
Hi Joseph.
I think you uncovered a bug in Mav
Hi Joseph.
I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your behalf.
As a workaround for the non-functioning 'tagletpath' option, I recommend
to separately publish the taglet library as a Maven artifact, which then
you
Hi, folks. I'm in the process of trying to port the Apache Xalan build
from Ant to Maven. It's close to usable, but I'm still struggling with a
few odd corners.
One of the odder corners: The Xalan documentation uses a javadoc taglet,
@xsl.usage, to indicate whether a method is intended only
s, exclusions, scope filtering, etc)
> * artifacts are resolved ("resolve" step), basically each artifact at the
> end points to one File in local repo
> * the graph is being transformed into List (or directly into
> List)
>
> So far we can see that the graph is somewhat af
ins, exclusions, scope filtering, etc)
* artifacts are resolved ("resolve" step), basically each artifact at the
end points to one File in local repo
* the graph is being transformed into List (or directly into
List)
So far we can see that the graph is somewhat affected by ordering in the
e of our transient dependencies has a conflict
> with another transient dependency, as it has several FQCNs that are
> identical to ones in the second artifact, but with different content. In
> most of those services, the first artifact ended up in the classpath after
> the second artifact,
I support a large number of SpringBoot services built with Maven.
I recently noticed that one of our transient dependencies has a conflict
with another transient dependency, as it has several FQCNs that are
identical to ones in the second artifact, but with different content. In
most of those
cü a écrit :
> Hello,
>
> Is it considered good practice to reference optional dependencies in BOM
> files?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
I would say yes.
My reasoning: BOM is bill of materials, ANY materials potentially needed
for a library.
Otoh, optional dependencies have to be explicitly listed by consumers (POM
consuming your library).
Hence, you will help your consumer by giving them predefined version to
use
Hi, Ceki.
My understanding is that, yes, if they are part of the main library
(i.e. not transitive dependencies from some other library), then they
should also be included in the BOM.
The BOM is usually imported under the `` section,
which is simply the place where you are managing which
On 6/17/2023 9:32 PM, Ceki Gülcü wrote:
>
> Hello,
>
> Is it considered good practice to reference optional dependencies in BOM
> files?
My question is probably silly as BOM files are reserved for declaring
artifacts a project builds itself and not for dependencies, option
Hello,
Is it considered good practice to reference optional dependencies in BOM
files?
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
-
To unsubscribe, e-mail: users-unsubscr
ou
want the Maven version without running a build.
> (1) IntelliJ is caching the JARs it uses for a project somewhere. And giving
> it the commands to reload dependencies or the POM fail if the version number
> has not changed... since I am seeing a file from January. Also, the Intelli
d deleted everything
> > from there.
> >
> > - Then I rebuilt in order. This included app1 and app2 (that has app1
> > as one of its dependencies) which showed up in the local repository
> > folder. Obviously, both generated snapshot jars had a timestamp of
> > yester
en repository of every single one of my
> projects, literally went in the folder net/myorg and deleted everything
> from there.
>
> - Then I rebuilt in order. This included app1 and app2 (that has app1
> as one of its dependencies) which showed up in the local repository
> f
its dependencies) which showed up in the local repository
folder. Obviously, both generated snapshot jars had a timestamp of
yesterday.
- Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
app1-0.0.1-SNAPSHOT.jar file. I expected to see yesterday's timestamp
on the JAR file since I
is the current latest release [0].
To avoid having to manually update dependencies my team has a scheduled task to
run Renovate [1] in our applications' CI pipelines to check for dependency
updates. Renovate automatically creates a branch and a merge request whenever a
dependency update is found
I apologize for the length of this email, I could not think of a shorter
way to present the issue/questions that is clear enough.
---
My environment involves the usual many open source dependencies (which I
control by specifying the versions to use in a master POM), but also a
large number
aim is not to include Jackson and other classes from transitive
> dependencies of Avro but that the pom file for the new jar would include
> the transitive dependencies from Avro.
>
> My PR is at https://github.com/apache/hadoop-thirdparty/pull/21
>
> Neither the pom.xml nor the depende
ing to shade Apache Avro jar, relocating the
> avro classes to a new package name.
> This new jar would be published to Maven Central and used by Hadoop.
> The aim is not to include Jackson and other classes from transitive
> dependencies of Avro but that the pom file for t
is not to include Jackson and other classes from transitive
dependencies of Avro but that the pom file for the new jar would include the
transitive dependencies from Avro.
My PR is at https://github.com/apache/hadoop-thirdparty/pull/21
Neither the pom.xml nor the dependency-reduced-pom.xml have
Hello,
*Here's the background to my problem: *
Ive created an open source library for automating salesforce tests (
www.testzeus.com) and packaged it as a maven jar (
https://ossindex.sonatype.org/component/pkg:maven/com.testzeus/Test_Zeus@1.0.1)
.
*Here's the problem statement : *
When a user
> I do not understand what you are trying to explain here.
Sorry I was not clear at all ! I was trying to say that in a multimodule
build, if you have a module shaded with the shade plugin, my rule of thumb
is to NEVER have another module listing this shaded module in its
dependencies.
S
Hi,
On Fri, Jul 8, 2022 at 5:43 PM Francois Marot
wrote:
> I believe you used the shade maven plugin or equivalent.
Yes
> I faced this
> problem multiple times and to my knowledge, there is no "good" solution.
>
I was afraid of that.
> The problem is that Maven computes the dependency
d-reads (essentially replacing the additional
> > "requires")
> >
> >
> > On 7/2/22, 4:46 PM, "Stanimir Stamenkov"
> wrote:
> >
> > I can't figure out what's the b
Hi,
If I set these dependencies to 'provided' I have not been able to ensure
they are actually inserted (and relocated) into the final shaded jar file.
Niels
On Fri, Jul 8, 2022 at 6:36 PM Jörg Schaible wrote:
> Hi,
>
> simply declare the dependency with scope "provided&q
n, module MUST NOT depend onto a
> shaded module. They must be considered as 'final' modules.
>
> I hope this may help
> François
>
>
> *- - - - -François Marot06 50 91 96 38*
>
> Le ven. 8 juil. 2022 à 16:51, Niels Basjes a écrit :
> > Hi,
> >
> > I have a
e a library project that uses dependencies that are prone to cause
> conflicts when another project wants to use my software.
> Antlr4 is a common example because it enforces the versions of the
> generated code and the runtime to be an exact match.
>
> In my maven project I have a m
Hi,
I have a library project that uses dependencies that are prone to cause
conflicts when another project wants to use my software.
Antlr4 is a common example because it enforces the versions of the
generated code and the runtime to be an exact match.
In my maven project I have a main library
the additional
"requires")
On 7/2/22, 4:46 PM, "Stanimir Stamenkov" wrote:
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those
2, 4:46 PM, "Stanimir Stamenkov" wrote:
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those of the main sources.
I have the following bas
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those of the main sources.
I have the following basic project structure:
pom.xml
src/
├─ main/
│ └─ java
On Sun, Jun 26, 2022 at 9:49 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:
>
> Firstly, you are not crerating a test JAR but a regular JAR with
> application classes, so of course test-scoped dependencies like JUnit
> are not going to be contained in the uber
> I get a build success, but when I inspect the generated jar, I don’t
> see the junit classes
Firstly, you are not crerating a test JAR but a regular JAR with
application classes, so of course test-scoped dependencies like JUnit
are not going to be contained in the uber JAR.
Secondl
I am trying to use maven-shade-plugin for the first time to create an uber-jar
and I can’t even get the simplest example to work.
For example, I created a simple pom based on the example at the top of this
page:
aven, I just told you what my own practice is.
And my suggestion was more about logically separating things, for
extensions is a must (technical reasons), while for "annotation case" is as
you correctly see: dependencies from plugin configurations are "not
visible" for Maven proj
On Fri, May 6, 2022 at 12:29 PM Tamás Cservenák wrote:
> Howdy,
>
> no, not my memory, I rely on my "daily routine": I use Maven Repository
> Manager, I regularly nuke my local repo, regularly execute `git clean -fdx`
> on my checkout, and on checkout/branch change regularly do "quick-build"
>
On Fri, May 6, 2022 at 1:24 PM Tamás Cservenák wrote:
> Hm, I need to look more into MCOMPILER-496, as I found a m-compiler-p IT
> that does exactly what Thomas described:
>
> https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-203-processorpath
>
> 3 module multi module
should manage those "helpers" as a separate
project with its own release cycle, and deploy the artifacts to a repo for
consumption by the "real" project.
What about cases where you want to test-drive a change with a "real"
project? It could (should?) be as easy a creating a
r' in your project list: 'mvn -pl whatever -am verify' won't
>> build
>> 'processor', you have to use 'mvn -pl processor,whatever -am verify'. I
>> would infer Maven's behavior for reactor ordering as taking the
>> declaration order by default, when there's no depend
Howdy,
no, not my memory, I rely on my "daily routine": I use Maven Repository
Manager, I regularly nuke my local repo, regularly execute `git clean -fdx`
on my checkout, and on checkout/branch change regularly do "quick-build"
`mvn clean install` (usually `mvn clean install -Dtest=void`) as very
ve
> 'processor' from the reactor build; change the order are declared
> and *kaboom*; in the end it does work only "by accident" (or "by chance" if
> you prefer).
> I wouldn't say the maven-compiler-plugin is "broken", it's just another
> Maven limita
On Thu, May 5, 2022 at 10:22 PM Tamás Cservenák wrote:
> IMHO the antipattern here is the idea that "mvn install" is bad.
>
> But let's take it step by step. For simplicity sake, let's ignore remote
> deploys/downloads for now.
> Also, let's assume a developer workstation for the same reason
>
ot; if
you prefer).
I wouldn't say the maven-compiler-plugin is "broken", it's just another
Maven limitation: it has no way of knowing that the
actually lists dependencies that could come from
the reactor build and that it would take them into account for determining
which modules to bu
e.
> > > Maven CLI will basically complain that it cannot resolve the module
> > needed
> > > by the plugin and fail, even if I explicitly list that module in the
> > > project list.
> > >
> > > That occurs both with Maven 3 and 4.
> >
t cannot resolve the module
> > needed
> > > by the plugin and fail, even if I explicitly list that module in the
> > > project list.
> > >
> > > That occurs both with Maven 3 and 4.
> > >
> > > The obvious workaround is to install the required module first and then
> > run
> > > the plugin but I'm trying to get rid of the need for `mvn install`
> > > entirely.
> > >
> > > Is there a particular reason plugin dependencies are not considered by
> > > Maven Reactor?
> > > Is module-as-plugin-dependency a Maven antipattern?
> > >
> > > Thanks a lot for your help!
> > > Florent
> > >
> >
>
and then run
> the plugin but I'm trying to get rid of the need for `mvn install`
> entirely.
>
> Is there a particular reason plugin dependencies are not considered by
> Maven Reactor?
> Is module-as-plugin-dependency a Maven antipattern?
>
> Thanks a lot for your help!
> Florent
>
gt; >
> > The obvious workaround is to install the required module first and then
> run
> > the plugin but I'm trying to get rid of the need for `mvn install`
> > entirely.
> >
> > Is there a particular reason plugin dependencies are not considered by
> > Maven Reactor?
> > Is module-as-plugin-dependency a Maven antipattern?
> >
> > Thanks a lot for your help!
> > Florent
> >
>
t; That occurs both with Maven 3 and 4.
>
> The obvious workaround is to install the required module first and then run
> the plugin but I'm trying to get rid of the need for `mvn install`
> entirely.
>
> Is there a particular reason plugin dependencies are not considered by
> Maven Rea
ven if I explicitly list that module in the
> project list.
>
> That occurs both with Maven 3 and 4.
>
> The obvious workaround is to install the required module first and then run
> the plugin but I'm trying to get rid of the need for `mvn install`
> entirely.
>
> Is t
is to install the required module first and then run
the plugin but I'm trying to get rid of the need for `mvn install` entirely.
Is there a particular reason plugin dependencies are not considered by
Maven Reactor?
Is module-as-plugin-dependency a Maven antipattern?
Thanks a lot for your help!
Florent
Great link, thanks you so much
From: Shipp, Scott
Sent: Tuesday, April 19, 2022 8:55 AM
To: Maven Users List
Subject: Re: Determine Maven Dependencies after a build
I also wanted to add that there is a reproducible builds guide at
https://maven.apache.org/guides/mini/guide-reproducible
, 2022 at 8:10 AM
To: Maven Users List
Subject: RE: Determine Maven Dependencies after a build
External Email
Is there a drawback to simply running resolve-ranges before official builds to
ensure the pom has static versions? That seems like it would resolve having
published poms with version ranges
sions
that were tested.
- One concrete issue we saw early on what a spring related dependency
that we had locked down, but that dependency itself had an open range
dependency on spring with something like [2.0.0,] - when spring 3 was
released, those dependencies got pulled int
, April 13, 2022 4:49 PM
To: Maven Users List
Subject: Re: Determine Maven Dependencies after a build
I don’t believe there currently is a way for this is native maven.
We ended up writing a custom tool/mojo for resolution management using a
DSL like:
repository https://repo1.maven.org/maven2/<ht
--
http://bernd.eckenfels.net
Von: Creager, Greg
Gesendet: Thursday, April 14, 2022 5:37:21 PM
An: Maven Users List
Betreff: RE: Determine Maven Dependencies after a build
Another question, if the published pom has a range:
Published pom
1 - 100 of 5936 matches
Mail list logo
