Re: enforcing class path order using maven enforcer
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 the future and if you need any help with that, please let me know. With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:27, wrote: > I don't dare :) > Just the ones I can list from memory are already too much for comfort > > -Original Message- > From: Nick Stolwijk > Sent: Friday, July 28, 2023 7:19 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 attachments, or > respond unless you recognize the sender and can validate the content is > safe. > 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] > https://clicktime.symantec.com/15sTvFHt6HgTZp6KnaRhz?h=l9TEufbiFltxRHDE0oErZ-X_ox0Rd1Y39CsqW75o5ME=&u=https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 01:13, > wrote: > > > 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 attachments, or > > respond unless you recognize the sender and can validate the content is > > safe. > > 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 it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk > > wrote: > > > > > I shamelessly copied it from stackoverflow, but here is a blogpost > > > explaining it better: > > > > > > https://clicktime.symantec.com/15tB9ZbM7fEjPnvVhz6WJ?h=-9MCeGkLCSU_WckipmaNUaXUCoq3OyZhZ8uCvSKGrPo=&u=https://clicktime.symantec.com/15sTRG8BLbau698nXE2pG?h=KHDhmLvf7F62Ny9vKCu4YVPvjny9jRYdJm76hKvDVck=&u=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 artifact once to > the > > > repository" way, but that depends on how much control you have over > your > > > repository. > > > > > > Hth, > > > > > > Nick Stolwijk > > > > > > ~~~ Try to leave this world a little better than you found it and, when > > > your turn comes to die, you can die happy in feeling that at any rate > you > > > have not wasted your time but have done your best ~~~ > > > > > > Lord Baden-Powell > > > > > > > > > On Sat, 29 Jul 2023 at 01:02, > > > wrote: > > > > > >> 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 think I get it. T
Re: enforcing class path order using maven enforcer
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] https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:13, wrote: > 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 attachments, or > respond unless you recognize the sender and can validate the content is > safe. > 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 it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk > wrote: > > > I shamelessly copied it from stackoverflow, but here is a blogpost > > explaining it better: > > > https://clicktime.symantec.com/15tB9ZbM7fEjPnvVhz6WJ?h=-9MCeGkLCSU_WckipmaNUaXUCoq3OyZhZ8uCvSKGrPo=&u=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 artifact once to the > > repository" way, but that depends on how much control you have over your > > repository. > > > > Hth, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Sat, 29 Jul 2023 at 01:02, > > wrote: > > > >> 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 think I get it. The destination directory is not arbitrary! > >> Instead, you unpack the dependency exactly where maven intends to put > >> compiled class files. > >> Okay, wow. That is hacky. And seriously clever. Is this a standard > >> trick or did you think of this just now? > >> > >> Re: how long to support this: probably pretty long. > >> > >> -Original Message- > >> From: Nick Stolwijk > >> Sent: Friday, July 28, 2023 6:47 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 attachments, or > >> respond unless you recognize the sender and can validate the content is > >> safe. > >> 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 to your own artifact repository and start > >> using > >> that version in your project. > >> > >> It all depends on how long you are expecting to support the solution. > >> > >> Nick Stolwijk > >> > >> ~~~ Try to leave this world a little better than you found it and, when > >> your turn comes to die, you can die happy in feeling that at any rate > you > >> have not wasted your time but have done your best ~~~ > >> > >> Lord Ba
RE: enforcing class path order using maven enforcer
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 attachments, or respond unless you recognize the sender and can validate the content is safe. 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 it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk wrote: > I shamelessly copied it from stackoverflow, but here is a blogpost > explaining it better: > https://clicktime.symantec.com/15tB9ZbM7fEjPnvVhz6WJ?h=-9MCeGkLCSU_WckipmaNUaXUCoq3OyZhZ8uCvSKGrPo=&u=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 artifact once to the > repository" way, but that depends on how much control you have over your > repository. > > Hth, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 01:02, > wrote: > >> 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 think I get it. The destination directory is not arbitrary! >> Instead, you unpack the dependency exactly where maven intends to put >> compiled class files. >> Okay, wow. That is hacky. And seriously clever. Is this a standard >> trick or did you think of this just now? >> >> Re: how long to support this: probably pretty long. >> >> -Original Message- >> From: Nick Stolwijk >> Sent: Friday, July 28, 2023 6:47 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 attachments, or >> respond unless you recognize the sender and can validate the content is >> safe. >> 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 to your own artifact repository and start >> using >> that version in your project. >> >> It all depends on how long you are expecting to support the solution. >> >> Nick Stolwijk >> >> ~~~ Try to leave this world a little better than you found it and, when >> your turn comes to die, you can die happy in feeling that at any rate you >> have not wasted your time but have done your best ~~~ >> >> Lord Baden-Powell >> >> >> On Sat, 29 Jul 2023 at 00:43, >> wrote: >> >> > 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 from outside our organisation - >> > nick.stolw...@gmail.com Do not click on links, open attachments, or >> > respond unless you recognize the sender and can validate the content is >> > safe. >> > 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 >> >
RE: enforcing class path order using maven enforcer
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 order using maven enforcer CAUTION: This email originated from outside our organisation - nick.stolw...@gmail.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. I shamelessly copied it from stackoverflow, but here is a blogpost explaining it better: https://clicktime.symantec.com/15tB9ZbM5BfychLbVR9NN?h=5UUQrRV1gNe3jx94XNoB8DTPasrbH9f1706lgdhIUBI=&u=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 artifact once to the repository" way, but that depends on how much control you have over your repository. Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:02, wrote: > 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 think I get it. The destination directory is not arbitrary! > Instead, you unpack the dependency exactly where maven intends to put > compiled class files. > Okay, wow. That is hacky. And seriously clever. Is this a standard > trick or did you think of this just now? > > Re: how long to support this: probably pretty long. > > -Original Message- > From: Nick Stolwijk > Sent: Friday, July 28, 2023 6:47 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 attachments, or > respond unless you recognize the sender and can validate the content is > safe. > 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 to your own artifact repository and start using > that version in your project. > > It all depends on how long you are expecting to support the solution. > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 00:43, > wrote: > > > 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 from outside our organisation - > > nick.stolw...@gmail.com Do not click on links, open attachments, or > > respond unless you recognize the sender and can validate the content is > > safe. > > 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 the BBED. > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Sat, 29 Jul 2023 at 00:33, > > wrote: > > > > > 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 und
Re: enforcing class path order using maven enforcer
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 it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk wrote: > 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 artifact once to the > repository" way, but that depends on how much control you have over your > repository. > > Hth, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 01:02, > wrote: > >> 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 think I get it. The destination directory is not arbitrary! >> Instead, you unpack the dependency exactly where maven intends to put >> compiled class files. >> Okay, wow. That is hacky. And seriously clever. Is this a standard >> trick or did you think of this just now? >> >> Re: how long to support this: probably pretty long. >> >> -Original Message- >> From: Nick Stolwijk >> Sent: Friday, July 28, 2023 6:47 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 attachments, or >> respond unless you recognize the sender and can validate the content is >> safe. >> 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 to your own artifact repository and start >> using >> that version in your project. >> >> It all depends on how long you are expecting to support the solution. >> >> Nick Stolwijk >> >> ~~~ Try to leave this world a little better than you found it and, when >> your turn comes to die, you can die happy in feeling that at any rate you >> have not wasted your time but have done your best ~~~ >> >> Lord Baden-Powell >> >> >> On Sat, 29 Jul 2023 at 00:43, >> wrote: >> >> > 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 from outside our organisation - >> > nick.stolw...@gmail.com Do not click on links, open attachments, or >> > respond unless you recognize the sender and can validate the content is >> > safe. >> > 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 the BBED. >> > >> > Nick Stolwijk >> > >> > ~~~ Try to leave this world a little better than you found it and, when >> > your turn comes to die, you can die happy in feeling that at any rate >> you >> > have not wasted your time but have done your best ~~~ >> > >> > Lord Baden-Powell >> > >> > >> > On Sat, 29 Jul 2023 at 00:33, >> > wrote
Re: enforcing class path order using maven enforcer
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 artifact once to the repository" way, but that depends on how much control you have over your repository. Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:02, wrote: > 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 think I get it. The destination directory is not arbitrary! > Instead, you unpack the dependency exactly where maven intends to put > compiled class files. > Okay, wow. That is hacky. And seriously clever. Is this a standard > trick or did you think of this just now? > > Re: how long to support this: probably pretty long. > > -Original Message- > From: Nick Stolwijk > Sent: Friday, July 28, 2023 6:47 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 attachments, or > respond unless you recognize the sender and can validate the content is > safe. > 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 to your own artifact repository and start using > that version in your project. > > It all depends on how long you are expecting to support the solution. > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 00:43, > wrote: > > > 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 from outside our organisation - > > nick.stolw...@gmail.com Do not click on links, open attachments, or > > respond unless you recognize the sender and can validate the content is > > safe. > > 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 the BBED. > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Sat, 29 Jul 2023 at 00:33, > > wrote: > > > > > 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 this > > > is for the small module to actually absorb the entire third-party > module. > > > But if that's what you mean, then why are we doing weird stuff in the > > > process-resources phase? > > > > > > -Original Message- > > > From: Nick Stolwijk > > > Sent: Friday, July 28, 2023 6:24 PM > > > To: Maven Users List > > > Subject: Re: enforcing class path order using maven enforcer > > > > > > > > > CAUTION: This email originated from outside ou
RE: enforcing class path order using maven enforcer
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 think I get it. The destination directory is not arbitrary!
Instead, you unpack the dependency exactly where maven intends to put compiled
class files.
Okay, wow. That is hacky. And seriously clever. Is this a standard trick or
did you think of this just now?
Re: how long to support this: probably pretty long.
-Original Message-
From: Nick Stolwijk
Sent: Friday, July 28, 2023 6:47 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 attachments, or respond
unless you recognize the sender and can validate the content is safe.
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 to your own artifact repository and start using
that version in your project.
It all depends on how long you are expecting to support the solution.
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:43, wrote:
> 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 from outside our organisation -
> nick.stolw...@gmail.com Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> 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 the BBED.
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:33,
> wrote:
>
> > 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 this
> > is for the small module to actually absorb the entire third-party module.
> > But if that's what you mean, then why are we doing weird stuff in the
> > process-resources phase?
> >
> > -Original Message-
> > From: Nick Stolwijk
> > Sent: Friday, July 28, 2023 6:24 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 attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > 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 the dependency with the Maven dependency plugin and
> > repackage it with your own classes.
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> >
> >
> >
> >process-resources
> >
> >unpack
> >
> >
> >
> >
> >commons-lang
> >commons-lang
> >2.6
> >
> >
> >
> > ${project.build.outputDirectory}
> >
Re: enforcing class path order using maven enforcer
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 to your own artifact repository and start using
that version in your project.
It all depends on how long you are expecting to support the solution.
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:43, wrote:
> 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 from outside our organisation -
> nick.stolw...@gmail.com Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> 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 the BBED.
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:33,
> wrote:
>
> > 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 this
> > is for the small module to actually absorb the entire third-party module.
> > But if that's what you mean, then why are we doing weird stuff in the
> > process-resources phase?
> >
> > -Original Message-
> > From: Nick Stolwijk
> > Sent: Friday, July 28, 2023 6:24 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 attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > 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 the dependency with the Maven dependency plugin and
> > repackage it with your own classes.
> >
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> >
> >
> >
> >process-resources
> >
> >unpack
> >
> >
> >
> >
> >commons-lang
> >commons-lang
> >2.6
> >
> >
> >
> > ${project.build.outputDirectory}
> >
> >
> >
> >
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and,
> > when your turn comes to die, you can die happy in feeling that at any
> > rate you have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Sat, 29 Jul 2023 at 00:16,
> > wrote:
> >
> > > 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.
> > >
> > > -Original Message-
> > > From: Nick Stolwijk
> > > Sent: Friday, July 28, 2023 6:10 PM
> > > To:
RE: enforcing class path order using maven enforcer
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 from outside our organisation -
nick.stolw...@gmail.com Do not click on links, open attachments, or respond
unless you recognize the sender and can validate the content is safe.
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 the BBED.
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when your
turn comes to die, you can die happy in feeling that at any rate you have not
wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:33, wrote:
> 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 this
> is for the small module to actually absorb the entire third-party module.
> But if that's what you mean, then why are we doing weird stuff in the
> process-resources phase?
>
> -Original Message-
> From: Nick Stolwijk
> Sent: Friday, July 28, 2023 6:24 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 attachments, or
> respond unless you recognize the sender and can validate the content
> is safe.
> 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 the dependency with the Maven dependency plugin and
> repackage it with your own classes.
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
>
>process-resources
>
>unpack
>
>
>
>
>commons-lang
>commons-lang
>2.6
>
>
>
> ${project.build.outputDirectory}
>
>
>
>
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and,
> when your turn comes to die, you can die happy in feeling that at any
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:16,
> wrote:
>
> > 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.
> >
> > -Original Message-
> > From: Nick Stolwijk
> > Sent: Friday, July 28, 2023 6: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 attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > 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 with an clause.
> >
> > And, of course, try to push your change upstream as soon as
> > possible, so you don't have to maintain this dependency hell forever.
> >
> > Hth,
> >
> > [1]
> > https://clicktime.symantec.com/15sMb6WJh8RM5WXFcSr6B?h=R4_565lG5nlvP
> > 2DLXCqnUIqZca7taYsicdvaaAfAjwM=&u=https://clicktime.symantec.com/15s
> > Mqb69g4ndT6CkJRSfW?h%3DWpHk9xFV9vRGzKQ
> > LbhSmi7KXJ9z78ttlOaGHNvrUkDE=&u=https://clicktime.s
Re: enforcing class path order using maven enforcer
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 the BBED.
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:33, wrote:
> 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 this is
> for the small module to actually absorb the entire third-party module.
> But if that's what you mean, then why are we doing weird stuff in the
> process-resources phase?
>
> -Original Message-
> From: Nick Stolwijk
> Sent: Friday, July 28, 2023 6:24 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 attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> 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 the dependency with the Maven dependency plugin and
> repackage it with your own classes.
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
>
>process-resources
>
>unpack
>
>
>
>
>commons-lang
>commons-lang
>2.6
>
>
>
> ${project.build.outputDirectory}
>
>
>
>
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:16,
> wrote:
>
> > 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.
> >
> > -Original Message-
> > From: Nick Stolwijk
> > Sent: Friday, July 28, 2023 6: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 attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > 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 with an clause.
> >
> > And, of course, try to push your change upstream as soon as possible,
> > so you don't have to maintain this dependency hell forever.
> >
> > Hth,
> >
> > [1]
> > https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQ
> > LbhSmi7KXJ9z78ttlOaGHNvrUkDE=&u=https://clicktime.symantec.com/15t7uA1
> > Gc7vLAPeBMLGEi?h=blO9yaZi0bbl5JQdo9BJpLSvyl-Jm4359goetQrNQJA=&u=https:
> > //maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and,
> > when your turn comes to die, you can die happy in feeling that at any
> > rate you have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Fri, 28 Jul 2023 at 23:53,
> > wrote:
> >
> > > I'd like to clarify one point about w
RE: enforcing class path order using maven enforcer
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 this is for the
small module to actually absorb the entire third-party module.
But if that's what you mean, then why are we doing weird stuff in the
process-resources phase?
-Original Message-
From: Nick Stolwijk
Sent: Friday, July 28, 2023 6:24 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 attachments, or respond
unless you recognize the sender and can validate the content is safe.
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 the dependency with the Maven dependency plugin and repackage it
with your own classes.
org.apache.maven.plugins
maven-dependency-plugin
2.8
process-resources
unpack
commons-lang
commons-lang
2.6
${project.build.outputDirectory}
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when your
turn comes to die, you can die happy in feeling that at any rate you have not
wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:16, wrote:
> 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.
>
> -Original Message-
> From: Nick Stolwijk
> Sent: Friday, July 28, 2023 6: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 attachments, or
> respond unless you recognize the sender and can validate the content
> is safe.
> 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 with an clause.
>
> And, of course, try to push your change upstream as soon as possible,
> so you don't have to maintain this dependency hell forever.
>
> Hth,
>
> [1]
> https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQ
> LbhSmi7KXJ9z78ttlOaGHNvrUkDE=&u=https://clicktime.symantec.com/15t7uA1
> Gc7vLAPeBMLGEi?h=blO9yaZi0bbl5JQdo9BJpLSvyl-Jm4359goetQrNQJA=&u=https:
> //maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and,
> when your turn comes to die, you can die happy in feeling that at any
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Fri, 28 Jul 2023 at 23:53,
> wrote:
>
> > 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 that my version gets picked up!
> >
> > -Original Message-
> > From: Tamás Cservenák
> > Sent: Friday, July 28, 2023 5:29 PM
> > To: Maven Users List
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > ta...@cservenak.net Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content
> > is
> safe.
> > 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 tha
Re: enforcing class path order using maven enforcer
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 the dependency with the Maven dependency plugin and
repackage it with your own classes.
org.apache.maven.plugins
maven-dependency-plugin
2.8
process-resources
unpack
commons-lang
commons-lang
2.6
${project.build.outputDirectory}
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 00:16, wrote:
> 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.
>
> -Original Message-
> From: Nick Stolwijk
> Sent: Friday, July 28, 2023 6: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 attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> 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
> with an clause.
>
> And, of course, try to push your change upstream as soon as possible, so
> you don't have to maintain this dependency hell forever.
>
> Hth,
>
> [1]
> https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQLbhSmi7KXJ9z78ttlOaGHNvrUkDE=&u=https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Fri, 28 Jul 2023 at 23:53,
> wrote:
>
> > 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 that my version gets picked up!
> >
> > -Original Message-
> > From: Tamás Cservenák
> > Sent: Friday, July 28, 2023 5:29 PM
> > To: Maven Users List
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > ta...@cservenak.net Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content is
> safe.
> > 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 level dependency (ie.if you consider a pom
> > with 2 dependencies, 1st dep nth level transitive dependency may
> > "shadow" your 2nd direct dependency).
> >
> > Thanks
> > T
> >
> > On Fri, Jul 28, 2023, 23:14 Nick Stolwijk
> wrote:
> >
> > > 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 first give warnings about duplicate classes and later
> > > in a project (when (almost) every duplicate was solved) to start
> > > failing the build
RE: enforcing class path order using maven enforcer
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. -Original Message- From: Nick Stolwijk Sent: Friday, July 28, 2023 6: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 attachments, or respond unless you recognize the sender and can validate the content is safe. 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 with an clause. And, of course, try to push your change upstream as soon as possible, so you don't have to maintain this dependency hell forever. Hth, [1] https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQLbhSmi7KXJ9z78ttlOaGHNvrUkDE=&u=https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Fri, 28 Jul 2023 at 23:53, wrote: > 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 that my version gets picked up! > > -Original Message- > From: Tamás Cservenák > Sent: Friday, July 28, 2023 5:29 PM > To: Maven Users List > Subject: Re: enforcing class path order using maven enforcer > > > CAUTION: This email originated from outside our organisation - > ta...@cservenak.net Do not click on links, open attachments, or > respond unless you recognize the sender and can validate the content is safe. > 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 level dependency (ie.if you consider a pom > with 2 dependencies, 1st dep nth level transitive dependency may > "shadow" your 2nd direct dependency). > > Thanks > T > > On Fri, Jul 28, 2023, 23:14 Nick Stolwijk wrote: > > > 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 first give warnings about duplicate classes and later > > in a project (when (almost) every duplicate was solved) to start > > failing the build if someone introduced a new duplicate. > > > > I have seen a lot of "strange" behaviour because the IDE used a > > different ordering than Maven did, and don't start about the runtime. > > If you have duplicate classes and Maven "behaves", who says that the > > runtime behaves in the same way? > > > > I would make it a bigger issue that you have duplicate classes, > > instead of trying to live with those duplicates. > > > > With regards, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, > > when your turn comes to die, you can die happy in feeling that at > > any rate you have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák > wrote: > > > > > 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://clicktime.symantec.com/15sM67LbYXeHjamSQPrKv?h=vxZZY3izFeq > > > lPG2oAGQqqxxfPZSoaeUZH6mYPCPUQ5E=&u=https://clic
Re: enforcing class path order using maven enforcer
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 with an clause. And, of course, try to push your change upstream as soon as possible, so you don't have to maintain this dependency hell forever. Hth, [1] https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Fri, 28 Jul 2023 at 23:53, wrote: > 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 that my version gets picked up! > > -Original Message- > From: Tamás Cservenák > Sent: Friday, July 28, 2023 5:29 PM > To: Maven Users List > Subject: Re: enforcing class path order using maven enforcer > > > CAUTION: This email originated from outside our organisation - > ta...@cservenak.net Do not click on links, open attachments, or respond > unless you recognize the sender and can validate the content is safe. > 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 level dependency (ie.if you consider a pom with 2 > dependencies, 1st dep nth level transitive dependency may "shadow" your 2nd > direct dependency). > > Thanks > T > > On Fri, Jul 28, 2023, 23:14 Nick Stolwijk wrote: > > > 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 first give warnings about duplicate classes and later in > > a project (when (almost) every duplicate was solved) to start failing > > the build if someone introduced a new duplicate. > > > > I have seen a lot of "strange" behaviour because the IDE used a > > different ordering than Maven did, and don't start about the runtime. > > If you have duplicate classes and Maven "behaves", who says that the > > runtime behaves in the same way? > > > > I would make it a bigger issue that you have duplicate classes, > > instead of trying to live with those duplicates. > > > > With regards, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, > > when your turn comes to die, you can die happy in feeling that at any > > rate you have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák > wrote: > > > > > 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://clicktime.symantec.com/15t5jYwsx6K5Z7UziRch6?h=VKa9Ey2evQPqt > > > ITYTqeL8EywPKBX_Y4PmejsjmKDpPE=&u=https://lists.apache.org/thread/16 > > > 055md5s2d5fqch5t4vkn13j7czfybr > > > > > > But in short: > > > - since 2.0.9 dependencies ARE ordered in deterministic way (unsure > > > how), but since Maven 3+ they are pre-order (graph "flattened" into > > > list, that > > is > > > then used to create CP and similar things) > > > - the plugins are ordered as well (and Maven 4 got or is about to > > > get > > even > > > finer solution) > > > - and in above mentioned thread, this is where we at > > > > > > > > https://clicktime.symantec.com/15t5eikbVUdV9Af5AsDYU?h=sAaRELxca8Z4PlY > > jvO260Lq5WEBvkad0aTt_3p0wSb0=&u=https://issues.apache.org/jira/browse/ > > MNG-6357?focusedCommentId%3D17748655%26pag
Re: enforcing class path order using maven enforcer
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 to perform key things, instead to "mimic" it (or deeply integrate it) and end up with totally different result. T On Fri, Jul 28, 2023, 23:14 Nick Stolwijk wrote: > 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 first > give warnings about duplicate classes and later in a project (when (almost) > every duplicate was solved) to start failing the build if someone > introduced a new duplicate. > > I have seen a lot of "strange" behaviour because the IDE used a different > ordering than Maven did, and don't start about the runtime. If you have > duplicate classes and Maven "behaves", who says that the runtime behaves in > the same way? > > I would make it a bigger issue that you have duplicate classes, instead of > trying to live with those duplicates. > > With regards, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák wrote: > > > 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 ordered in deterministic way (unsure how), > > but since Maven 3+ they are pre-order (graph "flattened" into list, that > is > > then used to create CP and similar things) > > - the plugins are ordered as well (and Maven 4 got or is about to get > even > > finer solution) > > - and in above mentioned thread, this is where we at > > > > > https://issues.apache.org/jira/browse/MNG-6357?focusedCommentId=17748655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17748655 > > - for the rest (overlapping classes) I do agree fully, but life is > life... > > > > HTH > > T > > > > On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk > > wrote: > > > > > 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 in the same phase in a lifecycle, of course). The only thing > > > ordered are the phases in the lifecycle. > > > > > > I think it would be more feasible to make sure you don't have > > dependencies > > > with overlapping classes (you can use the Maven Enforcer Plugin for > > > that[1]). If you really need those 2 dependencies on the classpath, > maybe > > > you can try something with the Maven Shade Plugin, to give one of those > > > dependencies their unique package names[2]. > > > > > > [1] > > https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html > > > [2] > > > > > > > > > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > > > > > Hth, > > > > > > Nick Stolwijk > > > > > > ~~~ Try to leave this world a little better than you found it and, when > > > your turn comes to die, you can die happy in feeling that at any rate > you > > > have not wasted your time but have done your best ~~~ > > > > > > Lord Baden-Powell > > > > > > > > > On Fri, 28 Jul 2023 at 21:25, > > > wrote: > > > > > > > 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 maven enforcer to ensure that > I > > > > don't accidentally swap the order sometime in the future? > > > > > > > > Copied from here: > > > > > > > > > > > > > > https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order > > > > > > > > > > > > This message is for information purposes only. It is not a > > > recommendation, > > > > advice, offer or solicitation to buy or sell a product or service, > nor > > an > > > > official confirmation of any transaction. It is directed at persons > who > > > are > > > > professionals and is intended for the recipient(s) only
RE: enforcing class path order using maven enforcer
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 that my version gets picked up! -Original Message- From: Tamás Cservenák Sent: Friday, July 28, 2023 5:29 PM To: Maven Users List Subject: Re: enforcing class path order using maven enforcer CAUTION: This email originated from outside our organisation - ta...@cservenak.net Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. 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 level dependency (ie.if you consider a pom with 2 dependencies, 1st dep nth level transitive dependency may "shadow" your 2nd direct dependency). Thanks T On Fri, Jul 28, 2023, 23:14 Nick Stolwijk wrote: > 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 first give warnings about duplicate classes and later in > a project (when (almost) every duplicate was solved) to start failing > the build if someone introduced a new duplicate. > > I have seen a lot of "strange" behaviour because the IDE used a > different ordering than Maven did, and don't start about the runtime. > If you have duplicate classes and Maven "behaves", who says that the > runtime behaves in the same way? > > I would make it a bigger issue that you have duplicate classes, > instead of trying to live with those duplicates. > > With regards, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, > when your turn comes to die, you can die happy in feeling that at any > rate you have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák wrote: > > > 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://clicktime.symantec.com/15t5jYwsx6K5Z7UziRch6?h=VKa9Ey2evQPqt > > ITYTqeL8EywPKBX_Y4PmejsjmKDpPE=&u=https://lists.apache.org/thread/16 > > 055md5s2d5fqch5t4vkn13j7czfybr > > > > But in short: > > - since 2.0.9 dependencies ARE ordered in deterministic way (unsure > > how), but since Maven 3+ they are pre-order (graph "flattened" into > > list, that > is > > then used to create CP and similar things) > > - the plugins are ordered as well (and Maven 4 got or is about to > > get > even > > finer solution) > > - and in above mentioned thread, this is where we at > > > > > https://clicktime.symantec.com/15t5eikbVUdV9Af5AsDYU?h=sAaRELxca8Z4PlY > jvO260Lq5WEBvkad0aTt_3p0wSb0=&u=https://issues.apache.org/jira/browse/ > MNG-6357?focusedCommentId%3D17748655%26page%3Dcom.atlassian.jira.plugi > n.system.issuetabpanels%253Acomment-tabpanel%23comment-17748655 > > - for the rest (overlapping classes) I do agree fully, but life is > life... > > > > HTH > > T > > > > On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk > > > > wrote: > > > > > 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 in the same phase in a lifecycle, of course). The only > > > thing ordered are the phases in the lifecycle. > > > > > > I think it would be more feasible to make sure you don't have > > dependencies > > > with overlapping classes (you can use the Maven Enforcer Plugin > > > for that[1]). If you really need those 2 dependencies on the > > > classpath, > maybe > > > you can try something with t
Re: enforcing class path order using maven enforcer
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 level dependency (ie.if you consider a pom with 2 dependencies, 1st dep nth level transitive dependency may "shadow" your 2nd direct dependency). Thanks T On Fri, Jul 28, 2023, 23:14 Nick Stolwijk wrote: > 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 first > give warnings about duplicate classes and later in a project (when (almost) > every duplicate was solved) to start failing the build if someone > introduced a new duplicate. > > I have seen a lot of "strange" behaviour because the IDE used a different > ordering than Maven did, and don't start about the runtime. If you have > duplicate classes and Maven "behaves", who says that the runtime behaves in > the same way? > > I would make it a bigger issue that you have duplicate classes, instead of > trying to live with those duplicates. > > With regards, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák wrote: > > > 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 ordered in deterministic way (unsure how), > > but since Maven 3+ they are pre-order (graph "flattened" into list, that > is > > then used to create CP and similar things) > > - the plugins are ordered as well (and Maven 4 got or is about to get > even > > finer solution) > > - and in above mentioned thread, this is where we at > > > > > https://issues.apache.org/jira/browse/MNG-6357?focusedCommentId=17748655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17748655 > > - for the rest (overlapping classes) I do agree fully, but life is > life... > > > > HTH > > T > > > > On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk > > wrote: > > > > > 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 in the same phase in a lifecycle, of course). The only thing > > > ordered are the phases in the lifecycle. > > > > > > I think it would be more feasible to make sure you don't have > > dependencies > > > with overlapping classes (you can use the Maven Enforcer Plugin for > > > that[1]). If you really need those 2 dependencies on the classpath, > maybe > > > you can try something with the Maven Shade Plugin, to give one of those > > > dependencies their unique package names[2]. > > > > > > [1] > > https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html > > > [2] > > > > > > > > > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > > > > > Hth, > > > > > > Nick Stolwijk > > > > > > ~~~ Try to leave this world a little better than you found it and, when > > > your turn comes to die, you can die happy in feeling that at any rate > you > > > have not wasted your time but have done your best ~~~ > > > > > > Lord Baden-Powell > > > > > > > > > On Fri, 28 Jul 2023 at 21:25, > > > wrote: > > > > > > > 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 maven enforcer to ensure that > I > > > > don't accidentally swap the order sometime in the future? > > > > > > > > Copied from here: > > > > > > > > > > > > > > https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order > > > > > > > > > > > > This message is for information purposes only. It is not a > > > recommendation, > > > > advice, offer or solicitation to buy or sell a product or service, > nor > > an > > > > official confirmation of any transaction. It is directed at persons > who > > > are > > > > professionals
Re: enforcing class path order using maven enforcer
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 first give warnings about duplicate classes and later in a project (when (almost) every duplicate was solved) to start failing the build if someone introduced a new duplicate. I have seen a lot of "strange" behaviour because the IDE used a different ordering than Maven did, and don't start about the runtime. If you have duplicate classes and Maven "behaves", who says that the runtime behaves in the same way? I would make it a bigger issue that you have duplicate classes, instead of trying to live with those duplicates. With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák wrote: > 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 ordered in deterministic way (unsure how), > but since Maven 3+ they are pre-order (graph "flattened" into list, that is > then used to create CP and similar things) > - the plugins are ordered as well (and Maven 4 got or is about to get even > finer solution) > - and in above mentioned thread, this is where we at > > https://issues.apache.org/jira/browse/MNG-6357?focusedCommentId=17748655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17748655 > - for the rest (overlapping classes) I do agree fully, but life is life... > > HTH > T > > On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk > wrote: > > > 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 in the same phase in a lifecycle, of course). The only thing > > ordered are the phases in the lifecycle. > > > > I think it would be more feasible to make sure you don't have > dependencies > > with overlapping classes (you can use the Maven Enforcer Plugin for > > that[1]). If you really need those 2 dependencies on the classpath, maybe > > you can try something with the Maven Shade Plugin, to give one of those > > dependencies their unique package names[2]. > > > > [1] > https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html > > [2] > > > > > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > > > Hth, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Fri, 28 Jul 2023 at 21:25, > > wrote: > > > > > 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 maven enforcer to ensure that I > > > don't accidentally swap the order sometime in the future? > > > > > > Copied from here: > > > > > > > > > https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order > > > > > > > > > This message is for information purposes only. It is not a > > recommendation, > > > advice, offer or solicitation to buy or sell a product or service, nor > an > > > official confirmation of any transaction. It is directed at persons who > > are > > > professionals and is intended for the recipient(s) only. It is not > > directed > > > at retail customers. This message is subject to the terms at: > > > https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > > > > > For important disclosures, please see: > > > https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html > > > regarding marketing commentary from Barclays Sales and/or Trading > desks, > > > who are active market participants; > > > > > > https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html > > > regarding our standard terms for Barclays Corporate and Investment Bank > > > where we trade with you in principal-to-principal wholesale markets > > > transactions; and in respect to Barclays Researc
Re: enforcing class path order using maven enforcer
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 ordered in deterministic way (unsure how), but since Maven 3+ they are pre-order (graph "flattened" into list, that is then used to create CP and similar things) - the plugins are ordered as well (and Maven 4 got or is about to get even finer solution) - and in above mentioned thread, this is where we at https://issues.apache.org/jira/browse/MNG-6357?focusedCommentId=17748655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17748655 - for the rest (overlapping classes) I do agree fully, but life is life... HTH T On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk wrote: > 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 in the same phase in a lifecycle, of course). The only thing > ordered are the phases in the lifecycle. > > I think it would be more feasible to make sure you don't have dependencies > with overlapping classes (you can use the Maven Enforcer Plugin for > that[1]). If you really need those 2 dependencies on the classpath, maybe > you can try something with the Maven Shade Plugin, to give one of those > dependencies their unique package names[2]. > > [1] https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html > [2] > > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > Hth, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Fri, 28 Jul 2023 at 21:25, > wrote: > > > 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 maven enforcer to ensure that I > > don't accidentally swap the order sometime in the future? > > > > Copied from here: > > > > > https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order > > > > > > This message is for information purposes only. It is not a > recommendation, > > advice, offer or solicitation to buy or sell a product or service, nor an > > official confirmation of any transaction. It is directed at persons who > are > > professionals and is intended for the recipient(s) only. It is not > directed > > at retail customers. This message is subject to the terms at: > > https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > > > For important disclosures, please see: > > https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html > > regarding marketing commentary from Barclays Sales and/or Trading desks, > > who are active market participants; > > > https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html > > regarding our standard terms for Barclays Corporate and Investment Bank > > where we trade with you in principal-to-principal wholesale markets > > transactions; and in respect to Barclays Research, including disclosures > > relating to specific issuers, see: http://publicresearch.barclays.com. > > > __ > > > > If you are incorporated or operating in Australia, read these important > > disclosures: > > > https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html > > . > > > > > __ > > For more details about how we use personal information, see our privacy > > notice: > https://www.cib.barclays/disclosures/personal-information-use.html. > > > > > > > __ > > >
Re: enforcing class path order using maven enforcer
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 in the same phase in a lifecycle, of course). The only thing ordered are the phases in the lifecycle. I think it would be more feasible to make sure you don't have dependencies with overlapping classes (you can use the Maven Enforcer Plugin for that[1]). If you really need those 2 dependencies on the classpath, maybe you can try something with the Maven Shade Plugin, to give one of those dependencies their unique package names[2]. [1] https://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html [2] https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Fri, 28 Jul 2023 at 21:25, wrote: > 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 maven enforcer to ensure that I > don't accidentally swap the order sometime in the future? > > Copied from here: > > https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order > > > This message is for information purposes only. It is not a recommendation, > advice, offer or solicitation to buy or sell a product or service, nor an > official confirmation of any transaction. It is directed at persons who are > professionals and is intended for the recipient(s) only. It is not directed > at retail customers. This message is subject to the terms at: > https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. > > For important disclosures, please see: > https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html > regarding marketing commentary from Barclays Sales and/or Trading desks, > who are active market participants; > https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html > regarding our standard terms for Barclays Corporate and Investment Bank > where we trade with you in principal-to-principal wholesale markets > transactions; and in respect to Barclays Research, including disclosures > relating to specific issuers, see: http://publicresearch.barclays.com. > __ > > If you are incorporated or operating in Australia, read these important > disclosures: > https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html > . > > __ > For more details about how we use personal information, see our privacy > notice: https://www.cib.barclays/disclosures/personal-information-use.html. > > > __ >
enforcing class path order using maven enforcer
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 maven enforcer to ensure that I don't accidentally swap the order sometime in the future? Copied from here: https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __
