David Karr wrote:
> I've been struggling with trying to do this, along with trying to
> understand the output of "mvn dependency:tree" and the apparently
> functionally similar output in the "Dependency Hierarchy" view in Eclipse
> using the m2e plugin. Although I can loosely see the
We actually already use several different BOMs, both internal and external.
It didn't occur to me to look for a jackson-bom, and that's a good idea.
However, I assumed that would just be a cosmetic change, but on the first
try it seemed like that made it work. I need to do some cleanup, but I
Hi David,
You could try to add the Jackson BOM in the parent dependencyManagement.
That would override all versions in the (transitive) dependencies of the
child modules. For a nice explanation of BOM files, see Baeldungs blog post
[1].
4.0.0
baeldung
Test
0.0.1-SNAPSHOT
pom
Start here: https://www.youtube.com/watch?v=2HyGxtsDf60
And then convince your team that your build "code" is as important as your
production code. Yes, the pom is also code, so if you follow "clean code"
conventions, you should also apply those to your build code.
I wish you a better build in
In general, I know how to override transient artifact versions. You add an
"exclusion" for the artifact on the dependency that is including that
dependency, and then you manually add that dependency in the same pom where
you added the exclusion. In my case, the version I want is defined in a
bom
I has been building a lot of projects in the past with a lot of duplicate
classes (with different versions). It might be enlightening to run your
build once with the 'ban duplicate classes' rule of the enforcer plugin[1]
to see on how much luck your application is running. ;-)
[1]
Nice catch!
-Original Message-
From: Nick Stolwijk
Sent: Friday, July 28, 2023 7:10 PM
To: Maven Users List
Subject: Re: enforcing class path order using maven enforcer
CAUTION: This email originated from outside our organisation -
nick.stolw...@gmail.com Do not click on links, open
We have enough control that it's doable, but little enough that I'm reluctant
to bother.
Thanks again for everything, things make much more sense now!
-Original Message-
From: Nick Stolwijk
Sent: Friday, July 28, 2023 7:06 PM
To: Maven Users List
Subject: Re: enforcing class path
I see there is one little mistake in that blogpost.
You should add the original dependency with provided to
prevent it from entering the classpath, or else you still end up with both
dependencies on your classpath.
Hth,
Nick Stolwijk
~~~ Try to leave this world a little better than you found
I shamelessly copied it from stackoverflow, but here is a blogpost
explaining it better:
https://gochev.blogspot.com/2014/07/patching-maven-library-with-your-custom.html
And I have used this hack in the past, but in the end I found it was more
easy to go with the "upload your own version of the
Thanks! That makes sense. Ideally don't want to slow down the build.
Actually, on second thought, it doesn't quite make sense.
Suppose I were willing to slow down the build.
How does unpacking help me with ... wait!
Okay, I just read the pom.xml fragment you posted much more carefully.
Now I
That is indeed one way of doing it, quick, easy, but costly for every build.
Another solution is to clone the upstream repository and checkout the
version you are on. Then fix the class and change the version of the
artifact to something you recognize, like -barclay-1.
Then upload the result once
Oh, I see, you're suggesting doing that as part of every build, instead of
once, statically?
-Original Message-
From: Nick Stolwijk
Sent: Friday, July 28, 2023 6:40 PM
To: Maven Users List
Subject: Re: enforcing class path order using maven enforcer
CAUTION: This email originated
I admit it is a trick to not have duplicate classes on your classpath and I
think you understood what I meant.
In your small module you unpack the Big Bad Evil Dependency and overwrite
one of the classes with your own. Then you repackage the whole thing and
use that in your project, instead of
I think I'm missing something. Currently there is a big module on maven
central with many classes, including one called TextFormat.
In my project there is a small maven module with just ONE class: a tweaked
version of TextFormat.
If I understand you correctly (doubt it), the "right" way to do
I was in the understanding you already had your own Maven artifact, as you
were talking about two different dependencies. It doesn't have to be a new
artifact in the sense that it has to live in a different repository, you
can also have this artifact as a module in your project.
You can unpack
I see, so the "proper" way to do this is to create a brand new maven artifact.
Sigh. That is more trouble than I was hoping for.
Re: upstream: they've already learned their lesson and newer versions don't
have this issue.
But they're also not backwards compatible with the version we're on.
Ah, that sounds like a good usecase to fix in your own dependency. Unpack
the "faulty" dependency there, overwrite it with your own implementation
and repackage it again. Then in your consuming project forbid the use of
the "faulty" dependency, using the Maven Enforcer[1] and fix any violation
As for IDEs, all those that try to "be caliph instead of caliph" (see
https://en.wikipedia.org/wiki/Iznogoud) IMHO are doing wrong.
Maven is Maven, everything else is just trying to be it. Good example of
IDE is Netbeans, an IDE that does not tries to reinvent things, and just
delegate to Maven
I'd like to clarify one point about why I care about order:
I have a class name which clashes on purpose!
That is, I have a third-party dependency from maven central that does the Wrong
Thing in one of its classes.
I have my own "fork" of that class which does the Right Thing.
I want to make sure
Yup,
My "coinciding" work was not to fix people depending in cp ordering, but
was more related to my guts telling that "level order" (introduced in
experiment PR) is more correct than "pre order".
Latter may cause that your 3rd or 4th level transitive dep be enlisted on
CP before your 2nd first
Hi Tamás,
Thanks for the corrections! I was still in the belief that it wasn't
explicitly ordered, but it seems that changed in the years. I still think
it is easier to reason about your application if you don't depend on the
order of dependencies. I have always used the Enforcer plugin to at
Nick,
I have to correct you, as what you wrote is not true (anymore). But first,
I think this mail was on hold by moderator, as we had a same/similar
discussion already on this thread:
https://lists.apache.org/thread/16055md5s2d5fqch5t4vkn13j7czfybr
But in short:
- since 2.0.9 dependencies ARE
Hi Mark,
I don't think there is any guarantee for ordering in Maven. The
dependencies are not ordered, the plugins in the build section are not
ordered. I remember that with a Java upgrade the plugins were executed in a
different ordering due to a new implementation of HashMap. (Only the
plugins
I already asked this question on Stack Overflow but got no takers so I'm trying
again here:
Suppose I have a maven module M which declares a direct dependency on modules X
and Y.
I want the classes from X to come before classes from Y in the class path.
Is there any easy way to add a rule in
25 matches
Mail list logo
