Re: Confused about how to override a transient artifact version
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 hierarchical output > from these, I find determining the actual details of where dependencies are > coming from is very mystifying. I recommend using the effective-pom goal of the maven-help-plugin [0] to get information about the effective POM that Maven ‘sees’, and if you enable verbose output there will be comments telling you where everything came from: mvn help:effective-pom -Dverbose=true I don’t use Eclipse, but in IntelliJ IDEA there are icons in the gutter of the editor that jump to the place where a versionless dependency‘s version is declared, which can be helpful too. I don’t know if there is a similar feature in Eclipse. (The Maven Helper plugin [1] for IntelliJ IDEA is also nice as an interactive and easier to read alternative to dependency:tree, including a filtering option.) Nils. [0] https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html [1] https://plugins.jetbrains.com/plugin/7179-maven-helper
Re: Confused about how to override a transient artifact version
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 think this will work. Thanks. On Fri, Jul 28, 2023 at 5:21 PM Nick Stolwijk wrote: > 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 > Test > > > > > com.fasterxml.jackson > jackson-bom > 2.13.5 > pom > import > > > > > > > [1] https://www.baeldung.com/spring-maven-bom > 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:29, David Karr > wrote: > > > 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 in our parent pom, so I don't have to specify the version in that > > dependency. > > > > This works fine, if I do this exclusion and inclusion in the overall > "child > > pom". > > > > However, I maintain the parent pom and platform, and there will be dozens > > of "child poms" that will need to do this. I would much rather do this > > "fixup" in the poms for the libraries in our platform. Those poms > specify > > the dependencies whose versions I need to control. > > > > 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 hierarchical output > > from these, I find determining the actual details of where dependencies > are > > coming from is very mystifying. > > > > To get down to actual details, my problem is that I'm ending up with > > different versions of "jackson-core" and "jackson-databind". I need to > > ensure that I have the same versions of both. I am getting v2.14.1 of > > jackson-databind and v2.13.5 of jackson-core. We are specifying v2.13.5 > in > > our parent pom, but somehow something in the tree is giving us v2.14.1 of > > jackson-databind. > > > > I'm going to include here a small excerpt of the "dependency:tree" output > > for our child pom: > > > > com.att.idp:RiskAssessmentMS:jar:2.8.0 > > +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile > > +- org.jasypt:jasypt:jar:1.9.3:compile > > +- com.io7m.xom:xom:jar:1.2.10:compile > > +- com.att.idp:idp-health:jar:2.8.0:compile > > | +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile > > | +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected > from > > constraint [2.8.0,2.8.100)) > > | | \- ch.qos.logback:logback-core:jar:1.2.9:compile > > | +- redis.clients:jedis:jar:3.8.0:compile > > | | \- org.apache.commons:commons-pool2:jar:2.11.1:compile > > | +- com.github.fppt:jedis-mock:jar:0.1.23:compile > > | | \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile > > | \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile > > +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile > > +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile > > > > The "idp-health" library is one of our wrapper libraries. That specifies > > dependencies that pull in jackson-databind, and in those dependencies I > > have excluded jackson-databind and included a specific dependency for > > jackson-databind. As the bom imported from the parent pom specifies > v2.13.5 > > for that, I would expect I would get jackson-databind v2.13.5, but I'm > > still getting v2.14.1. > > > > I'm very confused. > > > > I think I remember seeing discussions in the dev list about improving the > > output of dependency:tree to be clearer, I don't know if there's been any > > progress on that. > > >
Re: Confused about how to override a transient artifact version
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 Test com.fasterxml.jackson jackson-bom 2.13.5 pom import [1] https://www.baeldung.com/spring-maven-bom 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:29, David Karr wrote: > 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 in our parent pom, so I don't have to specify the version in that > dependency. > > This works fine, if I do this exclusion and inclusion in the overall "child > pom". > > However, I maintain the parent pom and platform, and there will be dozens > of "child poms" that will need to do this. I would much rather do this > "fixup" in the poms for the libraries in our platform. Those poms specify > the dependencies whose versions I need to control. > > 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 hierarchical output > from these, I find determining the actual details of where dependencies are > coming from is very mystifying. > > To get down to actual details, my problem is that I'm ending up with > different versions of "jackson-core" and "jackson-databind". I need to > ensure that I have the same versions of both. I am getting v2.14.1 of > jackson-databind and v2.13.5 of jackson-core. We are specifying v2.13.5 in > our parent pom, but somehow something in the tree is giving us v2.14.1 of > jackson-databind. > > I'm going to include here a small excerpt of the "dependency:tree" output > for our child pom: > > com.att.idp:RiskAssessmentMS:jar:2.8.0 > +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile > +- org.jasypt:jasypt:jar:1.9.3:compile > +- com.io7m.xom:xom:jar:1.2.10:compile > +- com.att.idp:idp-health:jar:2.8.0:compile > | +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile > | +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected from > constraint [2.8.0,2.8.100)) > | | \- ch.qos.logback:logback-core:jar:1.2.9:compile > | +- redis.clients:jedis:jar:3.8.0:compile > | | \- org.apache.commons:commons-pool2:jar:2.11.1:compile > | +- com.github.fppt:jedis-mock:jar:0.1.23:compile > | | \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile > | \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile > +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile > +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile > > The "idp-health" library is one of our wrapper libraries. That specifies > dependencies that pull in jackson-databind, and in those dependencies I > have excluded jackson-databind and included a specific dependency for > jackson-databind. As the bom imported from the parent pom specifies v2.13.5 > for that, I would expect I would get jackson-databind v2.13.5, but I'm > still getting v2.14.1. > > I'm very confused. > > I think I remember seeing discussions in the dev list about improving the > output of dependency:tree to be clearer, I don't know if there's been any > progress on that. >
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. 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 clic
Confused about how to override a transient artifact version
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 in our parent pom, so I don't have to specify the version in that dependency. This works fine, if I do this exclusion and inclusion in the overall "child pom". However, I maintain the parent pom and platform, and there will be dozens of "child poms" that will need to do this. I would much rather do this "fixup" in the poms for the libraries in our platform. Those poms specify the dependencies whose versions I need to control. 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 hierarchical output from these, I find determining the actual details of where dependencies are coming from is very mystifying. To get down to actual details, my problem is that I'm ending up with different versions of "jackson-core" and "jackson-databind". I need to ensure that I have the same versions of both. I am getting v2.14.1 of jackson-databind and v2.13.5 of jackson-core. We are specifying v2.13.5 in our parent pom, but somehow something in the tree is giving us v2.14.1 of jackson-databind. I'm going to include here a small excerpt of the "dependency:tree" output for our child pom: com.att.idp:RiskAssessmentMS:jar:2.8.0 +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile +- org.jasypt:jasypt:jar:1.9.3:compile +- com.io7m.xom:xom:jar:1.2.10:compile +- com.att.idp:idp-health:jar:2.8.0:compile | +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile | +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected from constraint [2.8.0,2.8.100)) | | \- ch.qos.logback:logback-core:jar:1.2.9:compile | +- redis.clients:jedis:jar:3.8.0:compile | | \- org.apache.commons:commons-pool2:jar:2.11.1:compile | +- com.github.fppt:jedis-mock:jar:0.1.23:compile | | \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile | \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile The "idp-health" library is one of our wrapper libraries. That specifies dependencies that pull in jackson-databind, and in those dependencies I have excluded jackson-databind and included a specific dependency for jackson-databind. As the bom imported from the parent pom specifies v2.13.5 for that, I would expect I would get jackson-databind v2.13.5, but I'm still getting v2.14.1. I'm very confused. I think I remember seeing discussions in the dev list about improving the output of dependency:tree to be clearer, I don't know if there's been any progress on that.
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 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
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 >> > 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 wi
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 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 us
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: >> > >> > > 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: enforci
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 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 dependenc
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}
> >
> >
> >
> >
> >
> > 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. Si
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: 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 viol
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.symantec.com/15sPv
> > MxFYMXxdyf6r62FZ?h=hLzdx-yh9f9YhEz85mXZRk7Eb5LWmOEajf8lPKAsH8k=&u=ht
> > tps://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 b
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 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
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 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
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 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 tha
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://clicktime.symantec.com > > > /15t5jYwsx6K5Z7UziRch6?h%3DVKa9Ey2evQPqt > > > ITYTqeL8EywPKBX_Y4PmejsjmKDpPE=&u=https://clicktime.symantec.com/1 > > > 5sMkktsDT7339Npks3Wt?h=yuPM_pKiMhcXrkpDfmfCxN_suUc5M9SM7Jm7p9i18k4 > > > =&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
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%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 > > > > t
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 the Maven Shade Plugin, to give one of > > > those dependencies their unique package names[2]. > > > > > > [1] > > https://clicktime.symantec.com/15t6QCW9d1mprg6P4tot4?h=37l3X1rUMHCNa > > zx5tx73nMPMatZatBRkIVE73EVfz5s=&u=https://www.mojohaus.org/extra-enf > > orcer-rules/banDuplicateClasses.html > > > [2] > > > > > > > > > https://clicktime.symantec.com/15t5pP9AQhzfy4JvFz1qi?h=454YA129nQl0eUE > Uetl13kca-YVeudTafYsvmeO1vd0=&u=https://maven.apache.org/plugins/maven > -shade-plugin/examples/class-relocation.html > > > > > > Hth, > > > > > > Nick Stolwijk > > > > > > ~~~ Tr
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. __
