Re: elegant way to disable Nexus staging/deployment in child POMs
I took a quick look at the Maven-Nexus-plugin and there is an option to disable it (skipNexusStagingDeployMojo), so I would start there. 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 Mon, 31 Jul 2023 at 01:50, Garret Wilson wrote: > How is the best way you would recommend to turn off publishing in parent B? > > Garret > > On 7/30/2023 8:47 PM, Nick Stolwijk wrote: > > In that case I would publish your parent with all the Good Stuff (parent > A) > > in the central repository, and have a second parent inheriting Parent A > > where publishing is turned off. So your super secret, multi gazillion > > project can inherit from parent B and so no publishing is going on, > unless > > they turn on the maven-flatten-plugin and a publish plugin. > > > > 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 Mon, 31 Jul 2023 at 01:30, Garret Wilson > wrote: > > > >> On 7/30/2023 8:16 PM, Nils Breunese wrote: > >>> … > >>> Can I ask why you publish this root POM as a public artifact to Maven > >> Central? > >> > >> 1. To be a good open-source citizen and help others with all the goodies > >> this POM provides (many of them which should be in Maven by default but > >> are not). > >> > >> 2. To provide a standard baseline for expectations for all of our > >> projects (e.g. build properties that are populated), including our > >> open-source projects and our hypothetical super-secret > >> multi-million-dollar projects. > >> > >>> If you’re using it to build super-secret million-dollar projects that > >> shouldn’t be published publicly, it might be safer to publish this root > POM > >> to an internal Maven repository as well (as I suppose you already do for > >> the projects that inherit from this root POM)? > >> > >> But the error lies in conflating the two conceptually. > >> > >> The child project is what is super-secret and multi-gazillion dollars > >> worth. The parent project is just a tool; it is not super-secret nor > >> worth multi-gazillion dollars. > >> > >> You realize that Maven comes with its own super POM, right? So we could > >> ask the same question: if I'm building a super-secret gazillion-dollar > >> project, might not it be safer to find out how to disable Maven's own > >> super POM? But of course we know that's a silly question. > >> > >> One should have nothing at all to with the other. The super POM just > >> sets up some common properties that everyone can use. My root POM just > >> sets up some common properties that everyone can use. I should be able > >> to publish my root POM and easily disable publishing for its children. > >> > >> This is one of Maven's drawbacks: inheriting too much from the POM. For > >> example if you publish a parent POM that has one license (e.g. Apache > >> 2.0), suddenly all its children inherit the same license (although most > >> people aren't aware of this) without specific overriding. See my Stack > >> Overflow question [Publish open-source Maven parent POM without > >> inheriting ``](https://stackoverflow.com/q/73239332) and > >> [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). > >> > >> The central issue in both cases is that the Maven designers in general > >> seemed not to have realized the need to distinguish between "information > >> related to publication of this POM" with "information that is to be > >> inherited to child POMs". > >> > >> Garret > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
In that case I would publish your parent with all the Good Stuff (parent A) in the central repository, and have a second parent inheriting Parent A where publishing is turned off. So your super secret, multi gazillion project can inherit from parent B and so no publishing is going on, unless they turn on the maven-flatten-plugin and a publish plugin. 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 Mon, 31 Jul 2023 at 01:30, Garret Wilson wrote: > On 7/30/2023 8:16 PM, Nils Breunese wrote: > > … > > Can I ask why you publish this root POM as a public artifact to Maven > Central? > > 1. To be a good open-source citizen and help others with all the goodies > this POM provides (many of them which should be in Maven by default but > are not). > > 2. To provide a standard baseline for expectations for all of our > projects (e.g. build properties that are populated), including our > open-source projects and our hypothetical super-secret > multi-million-dollar projects. > > > If you’re using it to build super-secret million-dollar projects that > shouldn’t be published publicly, it might be safer to publish this root POM > to an internal Maven repository as well (as I suppose you already do for > the projects that inherit from this root POM)? > > But the error lies in conflating the two conceptually. > > The child project is what is super-secret and multi-gazillion dollars > worth. The parent project is just a tool; it is not super-secret nor > worth multi-gazillion dollars. > > You realize that Maven comes with its own super POM, right? So we could > ask the same question: if I'm building a super-secret gazillion-dollar > project, might not it be safer to find out how to disable Maven's own > super POM? But of course we know that's a silly question. > > One should have nothing at all to with the other. The super POM just > sets up some common properties that everyone can use. My root POM just > sets up some common properties that everyone can use. I should be able > to publish my root POM and easily disable publishing for its children. > > This is one of Maven's drawbacks: inheriting too much from the POM. For > example if you publish a parent POM that has one license (e.g. Apache > 2.0), suddenly all its children inherit the same license (although most > people aren't aware of this) without specific overriding. See my Stack > Overflow question [Publish open-source Maven parent POM without > inheriting ``](https://stackoverflow.com/q/73239332) and > [MNG-7562](https://issues.apache.org/jira/browse/MNG-7562). > > The central issue in both cases is that the Maven designers in general > seemed not to have realized the need to distinguish between "information > related to publication of this POM" with "information that is to be > inherited to child POMs". > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
I think the idea of the flatten-maven-plugin is a Good Idea. It removes any inheritance in the POM structure before publishing to a repository. It is a "weak" implementation of the consumer POM that Maven is working towards. It doesn't change your artifacts, it just flattens the POM so it isn't dependending on any parent when published. I use it in a lot of projects which only publish some of the modules and I don't like the parent to be published. When you publish your parent, you have to take responsibility for it. I only publish the modules I would like to share, without inheritance. It also makes it easier with dependency management, the reasoning about which import takes preference with an inherited parent import is really hard to understand. Take a look at it, and maybe it will solve your problem. 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 Mon, 31 Jul 2023 at 00:45, Garret Wilson wrote: > On 7/30/2023 7:34 PM, Nick Stolwijk wrote: > > I am missing the purpose of publishing the parent pom. Is it because > other > > projects can inherit of it, > > Yes. > > > or is it because your own projects (that you > > want to be published) are inherited from it? > > Yes. > > > In the second case, you can use the maven-flatten-plugin to have the > > published projects not be dependent on your parent project. In that case > > you can use the parent projects to setup the > > configuration and activate it in the child modules in the build section. > If > > you enable the maven-flatten-plugin in the parent project for each child > > project there is no project inheritance anymore in the published > artifacts, > > so there is no need to publish your parent pom. > > I confess I don't know much about the Maven Flatten Plugin, but it > sounds suspiciously like the Maven Shade Plugin, which Seemed Like A > Good Idea At The Time To Muck With Everything, but from much personal > experience the details bring nothing but pain and suffering. > > So if I flatten everything, how do I publish a BOM of my multimodule > aggregate subprojects without bringing in project-specific dependencies > that shouldn't go in the BOM? > > I don't want to dismiss suggestions too quickly if I don't fully > understand them, but sincerely, just the idea sound like it would bring > lots of tears for years and years. > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: elegant way to disable Nexus staging/deployment in child POMs
I am missing the purpose of publishing the parent pom. Is it because other projects can inherit of it, or is it because your own projects (that you want to be published) are inherited from it? In the second case, you can use the maven-flatten-plugin to have the published projects not be dependent on your parent project. In that case you can use the parent projects to setup the configuration and activate it in the child modules in the build section. If you enable the maven-flatten-plugin in the parent project for each child project there is no project inheritance anymore in the published artifacts, so there is no need to publish your parent pom. Maybe this is the solution you are looking for. 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 Sun, 30 Jul 2023 at 23:50, Garret Wilson wrote: > I think we'll have to "agree to disagree" on this one. > > But I'll note that by following the same logic presented below, > CloudFormation and Terraform would require the developer to log into the > AWS console to finalize a deployment. That similarly would be > unacceptable to me. > > Thanks for pointing out that this plugin is end-of-life and explaining > the implications of dropping it. > > Garret > > On 7/30/2023 6:44 PM, Tamás Cservenák wrote: > > Well, I disagree: > > The App UI you are staging to will show you: > > - who staged, > > - what is staged > > - in case or error (ie. signature mismatch or checksum mismatch) where > are > > the problems > > - etc > > > > Is not prone to errors, as you do not modify content at all by doing that > > (Maven did deliver it already), reproducibility really depends only on > your > > build, not this 3rd party service (they blindly accepts bytes and just > > checks some rules "ok"/"not ok"), as for security you already provided > > credentials while staging. > > > > Given the "stability" history of oss or s01, I have to say that it is > even > > _desirable_ to be able to use UI for these steps, as otherwise you are > just > > "burning" versions (failed releases) for reasons totally unrelated to > > Maven, but for some 3rd party service that provides you "way" to get > > something to Central. > > > > Unless... we talk about some private Nx instance? Or Sonatype oss one? As > > in that case scripting would work for it. > > After all, this is proprietary software (they call it "oss" but is more > > like "free"), with its own proprietary REST API... > > > > T > > > > On Sun, Jul 30, 2023 at 11:37 PM Garret Wilson > > wrote: > > > >> On 7/30/2023 6:32 PM, Tamás Cservenák wrote: > >>> There is no need for another plugin... well, let me explain: > >>> all the "vanilla" plugins of Maven (install, deploy, release) support > >>> everything that aforementioned plugin does: install at end, deploy at > >> end, > >>> stage/deploy, there is ONLY two things they cannot do: "close" and > >>> "release" (the staging repo). > >>> > >>> For those two things, you'd need to use the browser, navigate to oss or > >> s01 > >>> server, log in, and using Nexus UI close or release your staging > >> repository. > >>> If this is acceptable to you, you should just drop the use of that > >> plugin. > >> > >> Requiring me to use my browser and log into a site and muck around with > >> a mouse just to release software is not acceptable. > >> > >> That might have been acceptable in 2003. > >> > >> We just don't do things like that nowadays. It's not just for > >> convenience. It's bad practice, prone to errors, hard to reproduce, > >> introduces security issues, unwieldy to maintain, and a general > >> infrastructure-as-code anti-pattern for 100 reasons, which you can > >> probably recite as well as I can. > >> > >> Garret > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
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==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==https://clicktime.symantec.com/15sTRG8BLbau698nXE2pG?h=KHDhmLvf7F62Ny9vKCu4YVPvjny9jRYdJm76hKvDVck==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!
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==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 > >>
Re: enforcing class path order using maven enforcer
I see there is one little mistake in that blogpost. You should add the original dependency with provided to prevent it from entering the classpath, or else you still end up with both dependencies on your classpath. Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk wrote: > I shamelessly copied it from stackoverflow, but here is a blogpost > explaining it better: > https://gochev.blogspot.com/2014/07/patching-maven-library-with-your-custom.html > > And I have used this hack in the past, but in the end I found it was more > easy to go with the "upload your own version of the artifact once to the > repository" way, but that depends on how much control you have over your > repository. > > Hth, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 01:02, > wrote: > >> Thanks! That makes sense. Ideally don't want to slow down the build. >> Actually, on second thought, it doesn't quite make sense. >> Suppose I were willing to slow down the build. >> How does unpacking help me with ... wait! >> Okay, I just read the pom.xml fragment you posted much more carefully. >> Now I think I get it. The destination directory is not arbitrary! >> Instead, you unpack the dependency exactly where maven intends to put >> compiled class files. >> Okay, wow. That is hacky. And seriously clever. Is this a standard >> trick or did you think of this just now? >> >> Re: how long to support this: probably pretty long. >> >> -Original Message- >> From: Nick Stolwijk >> Sent: Friday, July 28, 2023 6:47 PM >> To: Maven Users List >> Subject: Re: enforcing class path order using maven enforcer >> >> >> CAUTION: This email originated from outside our organisation - >> nick.stolw...@gmail.com Do not click on links, open attachments, or >> respond unless you recognize the sender and can validate the content is >> safe. >> That is indeed one way of doing it, quick, easy, but costly for every >> build. >> >> Another solution is to clone the upstream repository and checkout the >> version you are on. Then fix the class and change the version of the >> artifact to something you recognize, like -barclay-1. >> Then upload the result once to your own artifact repository and start >> using >> that version in your project. >> >> It all depends on how long you are expecting to support the solution. >> >> Nick Stolwijk >> >> ~~~ Try to leave this world a little better than you found it and, when >> your turn comes to die, you can die happy in feeling that at any rate you >> have not wasted your time but have done your best ~~~ >> >> Lord Baden-Powell >> >> >> On Sat, 29 Jul 2023 at 00:43, >> wrote: >> >> > Oh, I see, you're suggesting doing that as part of every build, instead >> of >> > once, statically? >> > >> > -Original Message- >> > From: Nick Stolwijk >> > Sent: Friday, July 28, 2023 6:40 PM >> > To: Maven Users List >> > Subject: Re: enforcing class path order using maven enforcer >> > >> > >> > CAUTION: This email originated from outside our organisation - >> > nick.stolw...@gmail.com Do not click on links, open attachments, or >> > respond unless you recognize the sender and can validate the content is >> > safe. >> > I admit it is a trick to not have duplicate classes on your classpath >> and >> > I think you understood what I meant. >> > >> > In your small module you unpack the Big Bad Evil Dependency and >> overwrite >> > one of the classes with your own. Then you repackage the whole thing and >> > use that in your project, instead of the BBED. >> > >> > Nick Stolwijk >> > >> > ~~~ Try to leave this world a little better than you found it and, when >> > your turn comes to die, you can die happy in feeling that at any rate >> you >> > have not wasted your time but have done your best ~~~ >> > >> > Lord Baden-Powell >> > >> > >> > On Sat, 29 Jul 2023 at 00:33, >> > wrote: >> >
Re: enforcing class path order using maven enforcer
I shamelessly copied it from stackoverflow, but here is a blogpost explaining it better: https://gochev.blogspot.com/2014/07/patching-maven-library-with-your-custom.html And I have used this hack in the past, but in the end I found it was more easy to go with the "upload your own version of the artifact once to the repository" way, but that depends on how much control you have over your repository. Hth, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Sat, 29 Jul 2023 at 01:02, wrote: > Thanks! That makes sense. Ideally don't want to slow down the build. > Actually, on second thought, it doesn't quite make sense. > Suppose I were willing to slow down the build. > How does unpacking help me with ... wait! > Okay, I just read the pom.xml fragment you posted much more carefully. > Now I think I get it. The destination directory is not arbitrary! > Instead, you unpack the dependency exactly where maven intends to put > compiled class files. > Okay, wow. That is hacky. And seriously clever. Is this a standard > trick or did you think of this just now? > > Re: how long to support this: probably pretty long. > > -Original Message- > From: Nick Stolwijk > Sent: Friday, July 28, 2023 6:47 PM > To: Maven Users List > Subject: Re: enforcing class path order using maven enforcer > > > CAUTION: This email originated from outside our organisation - > nick.stolw...@gmail.com Do not click on links, open attachments, or > respond unless you recognize the sender and can validate the content is > safe. > That is indeed one way of doing it, quick, easy, but costly for every > build. > > Another solution is to clone the upstream repository and checkout the > version you are on. Then fix the class and change the version of the > artifact to something you recognize, like -barclay-1. > Then upload the result once to your own artifact repository and start using > that version in your project. > > It all depends on how long you are expecting to support the solution. > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > > > On Sat, 29 Jul 2023 at 00:43, > wrote: > > > Oh, I see, you're suggesting doing that as part of every build, instead > of > > once, statically? > > > > -Original Message- > > From: Nick Stolwijk > > Sent: Friday, July 28, 2023 6:40 PM > > To: Maven Users List > > Subject: Re: enforcing class path order using maven enforcer > > > > > > CAUTION: This email originated from outside our organisation - > > nick.stolw...@gmail.com Do not click on links, open attachments, or > > respond unless you recognize the sender and can validate the content is > > safe. > > I admit it is a trick to not have duplicate classes on your classpath and > > I think you understood what I meant. > > > > In your small module you unpack the Big Bad Evil Dependency and overwrite > > one of the classes with your own. Then you repackage the whole thing and > > use that in your project, instead of the BBED. > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > > On Sat, 29 Jul 2023 at 00:33, > > wrote: > > > > > I think I'm missing something. Currently there is a big module on > > > maven central with many classes, including one called TextFormat. > > > In my project there is a small maven module with just ONE class: a > > > tweaked version of TextFormat. > > > If I understand you correctly (doubt it), the "right" way to do this > > > is for the small module to actually absorb the entire third-party > module. > > > But if that's what you mean, then why are we doing weird stuff in the > > > process-resources phase? > > > > > > -Original Message- > > > From: Nick Stolwijk > > > Sent: Friday, July 28, 2023 6:24 PM > > > To: Maven Users List > > > Subject: Re: enforcing class path order using maven enforcer > > > > > > > > > CAUTION: This email originated from outside our organisation - > >
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
> > > Subjec
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==https://clicktime.symantec.com/15t7uA1
> > Gc7vLAPeBMLGEi?h=blO9yaZi0bbl5JQdo9BJpLSvyl-Jm4359goetQrNQJA==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
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==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.
> > >
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==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==https://issues.apache.org/jira/browse/ > > MNG-6357?focusedCommentId%3D17748655%26page%3Dcom.atlassian.jira.plugi >
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=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. > > &
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. > > > __ >
Re: What steps will install dependent artifacts in local maven repo
You are right, I forgot that that still exists. :-S I do think that that way of dependency management is highly discouraged and IMNSHO should be discarded in your build as a first step. 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 Wed, Mar 23, 2022 at 12:05 AM Thomas Broyer wrote: > Le mar. 22 mars 2022 à 23:37, Nick Stolwijk a > écrit : > > > Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in > > Maven Central. > > > > Yes it is: > https://search.maven.org/artifact/org.codehaus.groovy/groovy-eclipse-batch > > About the RELEASE version: > https://www.baeldung.com/maven-dependency-latest-version >
Re: What steps will install dependent artifacts in local maven repo
As far as I can see is the support for Java 8 not yet dropped from Groovy
Eclipse. Also, org.codehaus.groovy:groovy-eclipse-batch:RELEASE is not in
Maven Central. Could it be that someone built it locally and uploaded that
artifact to your repository? Maybe you can better rely on the artifacts
provided by Maven Central instead of artifacts built internally?
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 Tue, Mar 22, 2022 at 11:30 PM KARR, DAVID wrote:
> And I also determined that groovy-eclipse v4.0.1 was released on 3/6/22,
> so it just took a few days to get to our intranet repo. I don't see any
> statement about it being built with Java 11, but it appears that's what
> happened.
>
> > -Original Message-
> > From: KARR, DAVID
> > Sent: Tuesday, March 22, 2022 12:15 PM
> > To: Maven Users List
> > Subject: RE: What steps will install dependent artifacts in local maven
> > repo
> >
> > *** Security Advisory: This Message Originated Outside of AT ***.
> > Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> > information.
> >
> > Here is the maven-compiler-plugin block:
> >
> >
> >
> maven-compiler-plugin
> >
> ${maven.compiler.plugin.version}
> >
> >
> > compile
> >
> >
> >
> >
> >
> org.codehaus.groovy
> > groovy-eclipse-
> > compiler
> > 3.7.0
> >
> >
> >
> org.codehaus.groovy
> > groovy-eclipse-
> > batch
> > RELEASE
> >
> >
> >
> > groovy-eclipse-
> > compiler
> >
> >
> > --
> >
> > I think in the limited circumstances I've been able to figure out, this
> > is essentially caused by specifying version "RELEASE", which means it
> > will use the latest released version. If we had specified version
> > 3.0.8, we wouldn't have seen this problem. What I still don't
> > understand is why the 4.x versions are compiled with Java 11. Our
> > intranet repo does have a record of who the uploader was, although I
> > wouldn't be at all surprised if that person says he has no idea why his
> > name would be attached to that. I will pursue that.
> >
> > > -Original Message-
> > > From: Thomas Broyer
> > > Sent: Tuesday, March 22, 2022 11:56 AM
> > > To: Maven Users List
> > > Subject: Re: What steps will install dependent artifacts in local
> > > maven repo
> > >
> > > This is totally unexpected behavior to me: an external artifact whose
> > > content would be different depending on which JDK downloaded it.
> > >
> > > Would you mind sharing the maven-compiler-plugin declaration with the
> > > ecj dependency? (to try replicating the issue and understand it)
> > >
> > > Le mar. 22 mars 2022 à 19:20, KARR, DAVID a écrit :
> > >
> > > > Self-replying from my alter ego.
> > > >
> > > > I have verified that if I remove the "ecj" tree from my local repo,
> > > > then build one service with Java 11, with just "mvn package", then
> > > > run a build of a different service with Java 8, it will get the
> > > > given error. I can verify that the ecj artifact is now reinstalled
> > > > into my
> > > local maven repo.
> > > > What's odd is that when I use "javap" to inspect the BatchCompiler
> > > > class file, it says it is version 50, not 55.
> > > >
> > > > I think I'm heading towards having each build, or at least each
> > > > build with a specific Java version, use a separate localRepository.
> > > > That is set in the settings.xml, and that path would be local to the
Should the includes option of RequireUpperBoundDeps match wildcards
Hi, I was playing around with the RequireUpperBoundDeps includes option to only fail the build on some specific artifacts. I wanted to include a bom artifact, but found out that didn't match the filtering. Second attempt was to filter out with a wildcard, but that also didn't match. Are wildcard / bom resolution a good idea for the includes? Wildcard looks a lot simpler to implement. Examples: software.amazon.awssdk:bom software.amazon.awssdk:* What do you think? 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
Re: Best practice to update dependency versions for *many* projects to the current version
Another way of doing this is with automation. There are various tools that
update a dependency, run the build and create a PR (or automerge).
If you are using Github, you can take a look at dependabot, but if you use
standalone tools (like bitbucket and Jenkins) you can look at renovate.
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 Thu, Sep 2, 2021 at 5:41 PM Mantas Gridinas wrote:
> You might be interested in running the POM per application rather than
> some global singular POM, since you should retain the ability to
> update a single application's dependencies without breaking other
> applications' behavior. I agree that this approach is the more time
> consuming than having some company wide common dependency list, but it
> all boils down to if you have an extensive test suite and if you are
> willing to redeploy all the applications when that super-pom (or BOM)
> is changed.
>
> "Maven dependency mechanism" is a good read in general. The only thing
> I disagree with is using properties for versions of artifacts.
>
> Since you're also migrating existing applications, I suppose you have
> some JAR folder that you (or it was done for you) copy over by hand.
> To prevent breakage when using external versions of said JARs you
> might want to use install plugin's install-file
> (
> https://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
> )
> goal to copy those files over into the common .m2 repository and then
> isolate your builds from network by either using private nexus or
> using offline mode.
>
> On Thu, Sep 2, 2021 at 6:07 PM Nils Breunese wrote:
> >
> > Another option is creating an artifact of type ‘pom’ that consists of
> just a pom.xml with a section and optionally
> properties for the versions (so they can easily be overridden when needed),
> and importing this BOM (bill of materials) artifact in your applications.
> >
> > See spring-boot-dependencies for an example:
> https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.5.4/pom
> >
> > You can use such an artifact as the parent of your applications
> (especially handy if you also want to centralize plugin configurations,
> etc.), or import its dependency management like this:
> >
> >
> >
> >
> > com.example
> > example-dependencies
> > 1.0.0
> > pom
> > import
> >
> >
> >
> >
> >
> > com.example
> > example-artifact
> >
> >
> >
> >
> > See
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> for more information about BOM POMs.
> >
> > Nils.
> >
> > > Op 2 sep. 2021, om 16:52 heeft Delany
> het volgende geschreven:
> > >
> > > Hi Bruno,
> > >
> > > You can define a property in a project all projects inherit from
> > >
> > >
> > > 3.2.4
> > >
> > > Then add a dependencyManagement section that sections the version
> > >
> > >
> > >
> > >
> > >cglib
> > >cglib
> > >${dep.cglib.cglib}
> > >
> > > And use this plugin to check for updates etc
> > > https://www.mojohaus.org/versions-maven-plugin/
> > >
> > > Delany
> > >
> > > On Thu, 2 Sept 2021 at 16:40, Bruno wrote:
> > >
> > >> I have been developing in Java almost from the beginning, but have not
> > >> used Maven for much more than a few personal test apps. I am now about
> > >> to migrate nearly 100 applications to Maven and I am a bit concerned
> > >> about how to manage dependency versions across that many projects in
> the
> > >> future.
> > >>
> > >> For a single app it is simple, go into the POM, modify the version of
> > >> the dependency, then verify that nothing broke due to newly
> unsupported
> > >> methods and fix the issues.
> > >>
> > >> But if you have a lot of applications, the above method becomes very
> > >> time consuming and manual.
> > >>
> > >> QUESTION: Is there a best practice (or perhaps tools that help) for
> how
> > >> to handle updating the dependency versions for that many applications?
> > >>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: users-h...@maven.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> --
> // Mantas
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Questions on what xml tags to use for pom.xml file for downloading isos
Hi,
I think you need to fix the parameter resolution: ${depStagingArea/pcs}
should be ${depStagingArea}/pcs
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 Mon, Jul 26, 2021 at 9:28 PM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:
>
>
> Hi, first post here. I'm new to Maven and its been quite some time since
> I've used XML.
>
> We are trying to using Maven to either upload and download artifacts from
> a Nexus repository Vs doing it manually.
>
> I've been trying various things, until I got the following to finally work
> for a multi iso download from a Nexus repo that we have inhouse:
>
>
>
>
> http://maven.apache.org/POM/4.0.0
> xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
> xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd<
> http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0.xsd
> >>
>
> 4.0.0
>
> Software_Release_Here
> Software_Program_Here
> Version_Number_Here
>
>
>
> /dropbox/
> 1st_ISO_here.iso
> 2nd_ISO_here.iso
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
>
>
>
> ${project.groupId}
> 1st_ISO_here.iso
> ${project.version}
> iso
> iso
> ${depStagingArea/pcs}
> ${downloadFilename1}
>
>
> ${project.groupId}
> 2nd_ISO_here.iso
> ${project.version}
> iso
> iso
> ${depStagingArea/pcs}
> ${downloadFilename2}
>
>
>
>
>
>
>
>
>
>
>
> Also, when I run this, the isos are downloaded to ~/software/xml/poms,
> when I've specified markup tags for
> /dropbox/. Not sure why its working like
> this.
>
> Thanks
>
>
>
>
Re: Plugin execution order in same phase + profiles
Hervé, > What you can also do is look at "mvn help:effective-pom -Dverbose" also to see > the result without executing Do you know if the order that shows with `mvn fr.jcgay.maven.plugins:buildplan-maven-plugin:list`[1] is also the guaranteed* execution order? * guaranteed for that Maven version and activated profiles [1] https://github.com/jcgay/buildplan-maven-plugin 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, May 7, 2021 at 7:56 AM Hervé BOUTEMY wrote: > > Can anybody enlighten me on what is happening here and if this behaviour > > is documented anywhere? Or is this just the "read the freakin' source > > code, pal" kind of detail? > order in the same phase is not expected to be guaranteed: that's a design > choice (even if "choice" is not the best term IMHO: see below). > Then there can't be any formal documentation: it's just what it is on each > Maven release (and maybe has changed over time). > see https://issues.apache.org/jira/browse/MNG-5987 > > On design "choice": > I worked on it in the past to see if we could change that "choice", and > it's > more complex than what people think: > - impact of profile injection, and if you want to control order, key > question: > in your case, do you prefer injecting profile-defined plugins before or > after? > - mix of plugins/goals and executions: in fact, we talk about plugins > order, > but what you need is goal execution order. And de-facto, given multiple > goals > executions are associated to one unique plugin definition during model > building > (that one is a design decision), you can't influence order at goal > execution > level but only full plugin > > You can read Model Builder documentation and code if you want, this is > where > you'll find the details: > https://maven.apache.org/ref/current/maven-model-builder/ > But stability over multiple Maven version remains not guaranteed. > > > > HTH > > Hervé > > Le vendredi 7 mai 2021, 01:13:53 CEST Alexander Kriegisch a écrit : > > I notices an unexpected thing about plugin execution order: If I have > > several plugins running in the same phase, normally they are executed in > > the lexical order in which they appear in the POM. But there is a case > > in which this can change. Schematically, it looks like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My expectation was that the execution order in phase X would be plugin > > A, then B. This is true sometimes, depending on which build other > > profiles are active. I mean completely unrelated profiles defined in > > other Maven modules. In my specific case, without specifying any other > > profiles (P is auto-activated bases on non-existence of a file), the > > order was B, A. If I manually activated any other profile or > > de-activated a profile which otherwise would be active automatically, > > the order changed to A, B. > > > > In my case, I had the option of moving plugin B to a later phase, which > > settled the issue for me, but that is not always possible. > > > > Can anybody enlighten me on what is happening here and if this behaviour > > is documented anywhere? Or is this just the "read the freakin' source > > code, pal" kind of detail? > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Trying out new verbose dependency tree: very slow result
Sorry for the double post, but I also see that strange jaspersoft repository in Andy's debug log. EBUG] Writing tracking file /Users/andyf/.m2/repository/xm l-apis/xml-apis/1.3.02/_remote.repositories [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://repository.apache.org/snapshots [DEBUG] Using transporter WagonTransporter with priority -1.0 for http://www.jasperforge.org/maven2 [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://repo.maven.apache.org/maven2 [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://oss.sonatype.org/content/repositories/snapshots [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://repo.maven.apache.org/maven2 [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for http://www.jasperforge.org/maven2 [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://repository.apache.org/snapshots [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://oss.sonatype.org/content/repositories/snapshots [DEBUG] Redirect requested to location ' https://www.jasperforge.org/maven2/eclipse/jdtcore/maven-metadata.xml' 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 Mon, May 3, 2021 at 9:50 PM Nick Stolwijk wrote: > And when I look at the dependency tree of the maven-dependency-plugin I > don't see the dependencies that are checked there. > > > [DEBUG] Writing tracking file /Users/andyf/.m2/repository/xa > lan/xalan/2.7.0/_remote.repositories > > [DEBUG] Verifying availability of > > /Users/andyf/.m2/repository/xalan/xalan/2.7.2/xalan-2.7.2.pom > from > > mvn dependency:tree -Dincludes=xalan > [INFO] Scanning for projects... > [INFO] > [INFO] --< org.apache.maven.plugins:maven-dependency-plugin > >-- > [INFO] Building Apache Maven Dependency Plugin 3.1.4-SNAPSHOT > [INFO] [ maven-plugin > ] > [INFO] > [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ > maven-dependency-plugin --- > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 1.917 s > [INFO] Finished at: 2021-05-03T21:47:34+02:00 > > So why is the new SNAPSHOT of the Maven Dependency Tree checking > dependencies that are not in the dependency tree? > > 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 Mon, May 3, 2021 at 9:38 PM Andy Feldman wrote: > >> I'm seeing the slowness as well. To avoid confusion about whether my own >> repos have some unusual configuration, I ran it against the >> maven-dependency-plugin repo itself, as cloned today. The debug logs (-X) >> contained many entries like this: >> >> [...] >> [DEBUG] Using transporter WagonTransporter with priority -1.0 for >> https://repo.maven.apache.org/maven2 >> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for >> https://repo.maven.apache.org/maven2 >> [DEBUG] Writing tracking file >> /Users/andyf/.m2/repository/xalan/xalan/2.7.0/_remote.repositories >> [DEBUG] Verifying availability of >> /Users/andyf/.m2/repository/xalan/xalan/2.7.2/xalan-2.7.2.pom from >> [apache.snapshots (https://repository.apache.org/snapshots, default, >> snapshots), central (https://repo.maven.apache.org/maven2, default, >> releases), sonatype-nexus-snapshots ( >> https://oss.sonatype.org/content/repositories/snapshots, default, >> snapshots), jaspersoft (http://www.jasperforge.org/maven2, default, >> releases+snapshots)] >> [DEBUG] Using transporter WagonTransporter with priority -1.0 for >> https://repo.maven.apache.org/maven2 >> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for >> https://repo.maven.apache.org/maven2 >> [DEBUG] Writing tracking file >> /Users/andyf/.m2/repository/xalan/xalan/2.7.2/_remote.repositories >> [DEBUG] Verifying availability of >> /Users/andyf/.m2/repository/xalan/serializer/2.7.2/serializer-2.7.2.pom >> from [apache.snapshots (https://repository.apache.org/snapshots, default, >> snapshots), central (https://repo.maven.apache.org/maven2, default, >> releases), sonatype-nexus-snapshots ( >> https://oss.s
Re: Trying out new verbose dependency tree: very slow result
And when I look at the dependency tree of the maven-dependency-plugin I don't see the dependencies that are checked there. > [DEBUG] Writing tracking file /Users/andyf/.m2/repository/xa lan/xalan/2.7.0/_remote.repositories > [DEBUG] Verifying availability of > /Users/andyf/.m2/repository/xalan/xalan/2.7.2/xalan-2.7.2.pom from mvn dependency:tree -Dincludes=xalan [INFO] Scanning for projects... [INFO] [INFO] --< org.apache.maven.plugins:maven-dependency-plugin >-- [INFO] Building Apache Maven Dependency Plugin 3.1.4-SNAPSHOT [INFO] [ maven-plugin ] [INFO] [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ maven-dependency-plugin --- [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 1.917 s [INFO] Finished at: 2021-05-03T21:47:34+02:00 So why is the new SNAPSHOT of the Maven Dependency Tree checking dependencies that are not in the dependency tree? 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 Mon, May 3, 2021 at 9:38 PM Andy Feldman wrote: > I'm seeing the slowness as well. To avoid confusion about whether my own > repos have some unusual configuration, I ran it against the > maven-dependency-plugin repo itself, as cloned today. The debug logs (-X) > contained many entries like this: > > [...] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Writing tracking file > /Users/andyf/.m2/repository/xalan/xalan/2.7.0/_remote.repositories > [DEBUG] Verifying availability of > /Users/andyf/.m2/repository/xalan/xalan/2.7.2/xalan-2.7.2.pom from > [apache.snapshots (https://repository.apache.org/snapshots, default, > snapshots), central (https://repo.maven.apache.org/maven2, default, > releases), sonatype-nexus-snapshots ( > https://oss.sonatype.org/content/repositories/snapshots, default, > snapshots), jaspersoft (http://www.jasperforge.org/maven2, default, > releases+snapshots)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Writing tracking file > /Users/andyf/.m2/repository/xalan/xalan/2.7.2/_remote.repositories > [DEBUG] Verifying availability of > /Users/andyf/.m2/repository/xalan/serializer/2.7.2/serializer-2.7.2.pom > from [apache.snapshots (https://repository.apache.org/snapshots, default, > snapshots), central (https://repo.maven.apache.org/maven2, default, > releases), sonatype-nexus-snapshots ( > https://oss.sonatype.org/content/repositories/snapshots, default, > snapshots), jaspersoft (http://www.jasperforge.org/maven2, default, > releases+snapshots)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Writing tracking file > /Users/andyf/.m2/repository/xalan/serializer/2.7.2/_remote.repositories > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Writing tracking file > /Users/andyf/.m2/repository/xml-apis/xml-apis/1.3.02/_remote.repositories > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repository.apache.org/snapshots > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > http://www.jasperforge.org/maven2 > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://oss.sonatype.org/content/repositories/snapshots > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > http://www.jasperforge.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repository.apache.org/snapshots > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://oss.sonatype.org/content/repositories/snapshots > [DEBUG] Redire
Re: Trying out new verbose dependency tree: very slow result
li) on project commons-lang: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree failed: Malformed \u encoding. at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) ...Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-dependency-plugin:3.1.4-SNAPSHOT:tree failed: Malformed \u encoding. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) ...Caused by: java.lang.IllegalArgumentException: Malformed \u encoding. at java.util.Properties.loadConvert (Properties.java:672) at java.util.Properties.load0 (Properties.java:455) at java.util.Properties.load (Properties.java:408) at org.eclipse.aether.internal.impl.TrackingFileManager.read (TrackingFileManager.java:56) at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read (DefaultUpdateCheckManager.java:511) at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata (DefaultUpdateCheckManager.java:250) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve (DefaultMetadataResolver.java:302) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata (DefaultMetadataResolver.java:181) at org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions (DefaultVersionRangeResolver.java:198) at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange (DefaultVersionRangeResolver.java:148) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.cachedResolveRangeResult (DefaultDependencyCollector.java:619) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:392) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362) ...at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies (DefaultRepositorySystem.java:284) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:169) at org.apache.maven.plugins.dependency.tree.VerboseDependencyGraphBuilder.buildVerboseGraph (VerboseDependencyGraphBuilder.java:93) at org.apache.maven.plugins.dependency.tree.TreeMojo.execute (TreeMojo.java:276) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) 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 Mon, May 3, 2021 at 2:33 PM Enrico Olivelli wrote: > Il giorno lun 3 mag 2021 alle ore 14:14 Nick Stolwijk > ha scritto: > > > > Hi Enrico, > > > > I did a search and replace on our domain name. The Nexus instance at our > > company is a mirror for Maven Central. > > > > And it is the only repository used in the build. See the output for > > list-repositories in the last mail. > > I also see these repo: > http://www.jasperforge.org/maven2 > https://repository.apache.org/snapshots > https://community.jaspersoft.com/maven2 > > off topic: you can try to upgrade to Maven 3.8.1 in order to skip > accesses to non-https repositories and to pick up a few enhancements > about Repository management. > &
Re: Trying out new verbose dependency tree: very slow result
Hi Enrico,
I did a search and replace on our domain name. The Nexus instance at our
company is a mirror for Maven Central.
And it is the only repository used in the build. See the output for
list-repositories in the last mail.
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 Mon, May 3, 2021 at 2:02 PM Enrico Olivelli wrote:
> Il giorno lun 3 mag 2021 alle ore 13:56 Nick Stolwijk
> ha scritto:
> >
> > Hi Enrico,
> >
> > It looks like it is trying to update the world while using repositories I
> > can't explain. ;-)
>
> Do you have references to several third party repositories ?
>
> it looks like https://nexus.example.com is not a good repo
>
> Enrico
>
> >
> > [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:list-repositories
> > (default-cli) @ commons-lang ---
> > Downloading from public_nx3:
> >
> https://nexus.example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> > Downloaded from public_nx3: https://nexus.
> >
> example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> > (1.7 kB at 1.9 kB/s)
> > [INFO] Repositories used by this build:
> > [INFO]id: public_nx3
> > url: https://nexus.example.com/repository/public/
> >layout: default
> > snapshots: [enabled => true, update => daily]
> > releases: [enabled => true, update => daily]
> >
> > Output of Maven debug:
> >
> > [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @
> > commons-lang ---
> > [DEBUG] Using mirror public_nx3 (
> > https://nexus.example.com/repository/public/) for apache.snapshots (
> > http://people.apache.org/maven-snapshot-repository).
> > [DEBUG] Using mirror public_nx3 (
> > https://nexus.example.com/repository/public/) for ow2-snapshot (
> > http://repository.ow2.org/nexus/content/repositories/snapshots).
> > [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=569300,
> > ConflictMarker.markTime=273500, ConflictMarker.nodeCount=434,
> > ConflictIdSorter.graphTime=329300, ConflictIdSorter.topsortTime=63200,
> > ConflictIdSorter.conflictIdCount=93,
> > ConflictIdSorter.conflictIdCycleCount=0,
> > ConflictResolver.totalTime=2936900,
> ConflictResolver.conflictItemCount=194,
> > DefaultDependencyCollector.collectTime=347565200,
> > DefaultDependencyCollector.transformTime=4219500}
> > [DEBUG]
> org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.4-SNAPSHOT
> > [DEBUG]org.apache.maven:maven-artifact:jar:3.1.1:compile
> > [DEBUG]org.apache.maven:maven-plugin-api:jar:3.1.1:compile
> > [DEBUG]
> org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
> > [DEBUG] javax.enterprise:cdi-api:jar:1.0:compile
> > [DEBUG] javax.annotation:jsr250-api:jar:1.0:compile
> > [DEBUG] javax.inject:javax.inject:jar:1:compile
> > [DEBUG] com.google.guava:guava:jar:10.0.1:compile
> > [DEBUG] com.google.code.findbugs:jsr305:jar:1.3.9:compile
> > [DEBUG] org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
> > [DEBUG] aopalliance:aopalliance:jar:1.0:compile
> > [DEBUG]
> > org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
> > [DEBUG]org.apache.maven:maven-model:jar:3.1.1:compile
> > [DEBUG]org.apache.maven:maven-core:jar:3.1.1:compile
> > [DEBUG] org.apache.maven:maven-settings-builder:jar:3.1.1:compile
> > [DEBUG] org.apache.maven:maven-model-builder:jar:3.1.1:compile
> > [DEBUG] org.eclipse.aether:aether-impl:jar:0.9.0.M2:compile
> > [DEBUG] org.codehaus.plexus:plexus-interpolation:jar:1.19:compile
> > [DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile
> > [DEBUG]
> > org.codehaus.plexus:plexus-component-annotations:jar:2.0.0:compile
> (version
> > managed from default)
> > [DEBUG] org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> > [DEBUG] org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> > [DEBUG]org.apache.maven:maven-repository-metadata:jar:3.1.1:compile
> > [DEBUG]org.apache.maven:maven-settings:jar:3.1.1:compile
> > [DEBUG]org.apache.maven:maven-aether-provider:jar:3.1.1:compile
> > [DEBUG] org.eclipse.aether:aether-spi:jar:0.9.0.M2:compile
> > [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> > [DEB
Re: Trying out new verbose dependency tree: very slow result
Hi Enrico,
It looks like it is trying to update the world while using repositories I
can't explain. ;-)
[INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:list-repositories
(default-cli) @ commons-lang ---
Downloading from public_nx3:
https://nexus.example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
Downloaded from public_nx3: https://nexus.
example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
(1.7 kB at 1.9 kB/s)
[INFO] Repositories used by this build:
[INFO]id: public_nx3
url: https://nexus.example.com/repository/public/
layout: default
snapshots: [enabled => true, update => daily]
releases: [enabled => true, update => daily]
Output of Maven debug:
[INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @
commons-lang ---
[DEBUG] Using mirror public_nx3 (
https://nexus.example.com/repository/public/) for apache.snapshots (
http://people.apache.org/maven-snapshot-repository).
[DEBUG] Using mirror public_nx3 (
https://nexus.example.com/repository/public/) for ow2-snapshot (
http://repository.ow2.org/nexus/content/repositories/snapshots).
[DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=569300,
ConflictMarker.markTime=273500, ConflictMarker.nodeCount=434,
ConflictIdSorter.graphTime=329300, ConflictIdSorter.topsortTime=63200,
ConflictIdSorter.conflictIdCount=93,
ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=2936900, ConflictResolver.conflictItemCount=194,
DefaultDependencyCollector.collectTime=347565200,
DefaultDependencyCollector.transformTime=4219500}
[DEBUG] org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.4-SNAPSHOT
[DEBUG]org.apache.maven:maven-artifact:jar:3.1.1:compile
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.1.1:compile
[DEBUG] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
[DEBUG] javax.enterprise:cdi-api:jar:1.0:compile
[DEBUG] javax.annotation:jsr250-api:jar:1.0:compile
[DEBUG] javax.inject:javax.inject:jar:1:compile
[DEBUG] com.google.guava:guava:jar:10.0.1:compile
[DEBUG] com.google.code.findbugs:jsr305:jar:1.3.9:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
[DEBUG] aopalliance:aopalliance:jar:1.0:compile
[DEBUG]
org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
[DEBUG]org.apache.maven:maven-model:jar:3.1.1:compile
[DEBUG]org.apache.maven:maven-core:jar:3.1.1:compile
[DEBUG] org.apache.maven:maven-settings-builder:jar:3.1.1:compile
[DEBUG] org.apache.maven:maven-model-builder:jar:3.1.1:compile
[DEBUG] org.eclipse.aether:aether-impl:jar:0.9.0.M2:compile
[DEBUG] org.codehaus.plexus:plexus-interpolation:jar:1.19:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:2.0.0:compile (version
managed from default)
[DEBUG] org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[DEBUG] org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[DEBUG]org.apache.maven:maven-repository-metadata:jar:3.1.1:compile
[DEBUG]org.apache.maven:maven-settings:jar:3.1.1:compile
[DEBUG]org.apache.maven:maven-aether-provider:jar:3.1.1:compile
[DEBUG] org.eclipse.aether:aether-spi:jar:0.9.0.M2:compile
[DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
[DEBUG]org.apache.maven.reporting:maven-reporting-impl:jar:3.0.0:compile
[DEBUG]
org.apache.maven.doxia:doxia-decoration-model:jar:1.7.4:compile
[DEBUG]commons-io:commons-io:jar:2.6:compile
[DEBUG]org.apache.maven.doxia:doxia-sink-api:jar:1.9.1:compile
[DEBUG] org.apache.maven.doxia:doxia-logging-api:jar:1.9.1:compile
[DEBUG]org.apache.maven.doxia:doxia-core:jar:1.9.1:compile
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile
[DEBUG] org.apache.xbean:xbean-reflect:jar:3.7:compile
[DEBUG] com.google.collections:google-collections:jar:1.0:compile
[DEBUG] org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[DEBUG] commons-logging:commons-logging:jar:1.2:compile
[DEBUG] commons-codec:commons-codec:jar:1.11:compile
[DEBUG] org.apache.httpcomponents:httpcore:jar:4.4.11:compile
[DEBUG]org.apache.maven.doxia:doxia-site-renderer:jar:1.9.2:compile
[DEBUG] org.apache.maven.doxia:doxia-skin-model:jar:1.9.2:compile
[DEBUG] org.apache.maven.doxia:doxia-module-xhtml:jar:1.9.1:compile
[DEBUG] org.apache.maven.doxia:doxia-module-xhtml5:jar:1.9.1:compile
[DEBUG] org.codehaus.plexus:plexus-i18n:jar:1.0-beta-10:compile
[DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.2:compile
[DEBUG] org.apache.velocity:velocity:jar:1.7:compile
[DEBUG] commons-lang:commons-lang:jar:2.4:compile
[DEBUG] org.apache.velocity:velocity-tools:jar:2.0:compile
Trying out new verbose dependency tree: very slow result
Hi folks, I was curious about the new verbose functionality in the maven-dependency-plugin.[1] I cloned the repository and built a local snapshot of master. Even on a very simple project building the verbose dependency tree took 30 minutes! I am using Maven 3.8.1 and Java 16. Is this a known issue? Is there something wrong with my local setup? Can I do something to analyse this? [INFO] Scanning for projects... [INFO] [INFO] < com.example.bibliotheek.utilities:commons-lang >- [INFO] Building Bibliotheek - Commons-Lang 1.5.2-SNAPSHOT [INFO] ---[ bundle ]--- [INFO] [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @ commons-lang --- [INFO] com.example.bibliotheek.utilities:commons-lang:bundle:1.5.2-SNAPSHOT [INFO] +- org.apache.commons:commons-lang3:jar:3.12.0:compile [INFO] +- org.junit.jupiter:junit-jupiter-api:jar:5.7.1:test [INFO] +- org.assertj:assertj-core:jar:3.19.0:test [INFO] \- nl.jqno.equalsverifier:equalsverifier:jar:3.5.4:test [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 31:47 min [INFO] Finished at: 2021-05-03T12:51:06+02:00 [INFO] [1] https://issues.apache.org/jira/browse/MDEP-644 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
Re: Getting version upgrade advise to upgrade a BOM..
To update the BOM dependencies you can use the Maven versions plugin: mvn versions:use-latest-versions versions:update-properties -DgenerateBackupPoms=false 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 Sun, May 2, 2021 at 3:12 PM Niels Basjes wrote: > Hi, > > Thanks for the suggestion. > Apparently the "standard" maven versions plugin does not do this correctly > yet. > > I was looking at this renovate tool yet what I found is that it seems to > only support creating pull/merge requests. > This is very nice but not what I want right now. > Is there a way to run it locally (without any github/gitlab/... system) and > generate a patch file or just a list of problematic versions? > > Niels Basjes > > > On Fri, Apr 30, 2021 at 3:40 AM Tomo Suzuki > wrote: > > > Hi Niels, > > (Thank you for using the libraries-bom! I'm one of the maintainers of the > > BOM.) > > > > I don't know how to do it in Maven. However, I often see people using > > dependabot or > > renovatebot integrated with their repositories. > > An example pull request by renovatebot: > > https://github.com/googleapis/java-securitycenter/pull/472 > > > > Note that RenovateBot doesn't require GitHub.com repository: > > https://github.com/renovatebot/renovate#self-hosting > > > > > > > > > > On Thu, Apr 29, 2021 at 5:12 PM Delany > wrote: > > > > > Is it this > https://github.com/mojohaus/versions-maven-plugin/issues/395 > > > Regards, > > > Delany > > > > > > > > > On Thu, 29 Apr 2021, 22:22 Niels Basjes, wrote: > > > > > > > Hi, > > > > > > > > I see quite a few situations where the dependencies for toolkit are > > > > provided in the form of a dependency you must "import" in > > > > the dependencyManagement section. > > > > They provide this to ensure you always have a working combination > for a > > > lot > > > > of closely related dependencies. > > > > > > > > To illustrate the problem I ran into I created this minimal pom.xml: > > > > > > > > > > > > http://maven.apache.org/POM/4.0.0; > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > > > > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > > > > http://maven.apache.org/xsd/maven-4.0.0.xsd;> > > > > 4.0.0 > > > > > > > > nl.basjes.example > > > > dependency-version-test > > > > 0.1-SNAPSHOT > > > > jar > > > > > > > > > > > > > > > > > > > > > > > > com.google.cloud > > > > libraries-bom > > > > 19.0.0 > > > > pom > > > > import > > > > > > > > > > > > > > > > > > > > > > > > > > > > com.google.cloud > > > > google-cloud-pubsub > > > > > > > > > > > > > > > > > > > > > > > > Now for this example the 19.0.0 is a valid version and absolutely not > > the > > > > latest version. > > > > What I'm looking for is a command that will give me the advice to > > update > > > > the 19.0.0 to whatever is currently the latest version. > > > > If I put this in an empty directory and try to get insight in what I > > need > > > > to upgrade I do this: > > > > > > > > mvn versions:display-dependency-updates > > > > > > > > > > > > The output I get from this is the full list of all underlying > > > dependencies > > > > for which an update is available; yet no mention of the libraries-bom > > > that > > > > is in need of an update. > > > > > > > > What I would like is a list of the things for which an update is > > > available; > > > > yet here I effectively want the opposite of what I get from this > > plugin: > > > I > > > > only want (should?) get the suggestion to update the libraries-bom > and > > > not > > > > the full list of the versions defined in there. > > > > > > > > Is there a way to achieve this? > > > > > > > > -- > > > > Best regards / Met vriendelijke groeten, > > > > > > > > Niels Basjes > > > > > > > > > > > > > -- > > Regards, > > Tomo > > > > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes >
Re: Renaming Dependencies
You could upload a relocation pom[1] or create a list of old and new groupId/ArtifactId combinations and use the oga-maven-plugin[2] to convert each project. Unfortunately that plugin only can fail your build and not output a warning. [1] https://maven.apache.org/guides/mini/guide-relocation.html [2] https://github.com/jonathanlermitage/oga-maven-plugin 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, Mar 26, 2021 at 9:38 PM Martin Bradley wrote: > Hi Folks, > > A large company moved to Maven and uploaded many of their non public jars > into the private company repository. Many of these dependencies were > uploaded without using standard group/artifact id. This is not easily > fixed > because many projects reference those group/artifact coordinates, changing > the > names needs much management and coordination across teams. > > The problem currently is the group/artifact ids are not following the > correct > convention of reverse dns name like com.someenterprise.dept. Therefore it > is > not easy to identify all the private jars under some particular folder > under ~/.m2/repo since they are scattered everywhere. > > Looking for how to build new versions of these jars and upload with a > corrected > group/artifact. While continuing to upload with the with the original > group/artifact id. A deadline for projects to switch to the corrected > group/artifact can be set. After the deadline we would just update the pom > to > use the corrected group/artifact and remove mentions of the old > coordinates. > > I had a look over various plugins but could not see a good way to handle > this. > > thanks. > Martin >
Re: Maven goes to repository for a dependency from reactor
Hi Anton, I have taken a look at the issues fixed in 3.0.1 and I think you'll find the information you need in MDEP-409[1]. [1] https://issues.apache.org/jira/browse/MDEP-409 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, Nov 28, 2020 at 6:46 AM Anton Vodonosov wrote: > Falko, thank you for the response. It works indeed. > > However, the case with maven-dependency-plugin is a simplification of my > case. > > I actually faced this error first in the plugin I develop (since it was > reproducible also > with the more well known dependency plugin I mentioned only it in email). > > My plugin builds dependency tree using the DependencyGraphBuilder injected > into the plugin when it's loaded by maven: > > > https://github.com/avodonosov/hashver-maven-plugin/blob/master/src/main/java/pro/avodonosov/mvnhashver/HashVerMojo.java#L99 > > Can you tell what is secret in the dependency plugin 3.0.1+ that makes it > work? > What should I fix in my plugin, in other words. > > Best regards, > - Anton > > 27.11.2020, 00:15, "Falko Modler" : > > Try: mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:tree > > > > I'll actually work with 3.0.1+ but not with 2.8 which is the default for > > that repo. > > > > Am 25.11.2020 um 22:18 schrieb Anton Vodonosov: > >> When I run `mvn -X dependency:tree` in the root directory > >> of redisson (https://github.com/redisson/redisson), I get the below > error. > >> > >> Question: why does maven tries to resolve the `redisson` dependency > >> of the `redisson-all` module using a remote repository, when `redisson` > >> is a part of the reactor? > >> > https://github.com/redisson/redisson/blob/683b0dfce2c97c576722176019f14404d1bf7223/pom.xml#L55 > >> > https://github.com/redisson/redisson/blob/683b0dfce2c97c576722176019f14404d1bf7223/redisson-all/pom.xml#L77 > >> > >> [ERROR] Failed to execute goal on project redisson-all: Could not > resolve dependencies for project > org.redisson:redisson-all:jar:3.14.1-SNAPSHOT: Failure to find > org.redisson:redisson:jar:3.14.1-SNAPSHOT in > https://oss.sonatype.org/content/repositories/snapshots was cached in the > local repository, resolution will not be reattempted until the update > interval of snapshots-repo has elapsed or updates are forced -> [Help 1] > >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal on project redisson-all: Could not resolve dependencies for > project org.redisson:redisson-all:jar:3.14.1-SNAPSHOT: Failure to find > org.redisson:redisson:jar:3.14.1-SNAPSHOT in > https://oss.sonatype.org/content/repositories/snapshots was cached in the > local repository, resolution will not be reattempted until the update > interval of snapshots-repo has elapsed or updates are forced > >> at > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:221) > >> at > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) > >> at > org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:245) > >> at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) > >> at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > >> at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > >> at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > >> at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > >> at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > >> at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) > >> at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) > >> at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > >> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > >> at org.apache.maven.cli.MavenCli.doMain(
Re: Preferred way to execute Maven goals/phases from Maven plugins
Hi Karl, Unfortunately, the Maven-Release-Plugin doesn't cut it for us. 1. It doesn't support Tycho builds with regard to versions [1] 2. We do use release branches on our products (Eclipse RCP and docker containers) to do some acceptance testing. That's why we used to use the Atlassian Gitflow plugin (alas, they didn't support Tycho either) and are now migrating to the aforementioned plugin. [1] https://www.eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/set-version-mojo.html 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 Mon, Nov 2, 2020 at 2:00 PM Karl Heinz Marbaise wrote: > Hi, > > On 02.11.20 11:27, Nick Stolwijk wrote: > > Hi folks, > > > > We are struggling with our buildserver (Jenkins) and the Git-Flow Maven > > Plugin[1] with regards to execute the Maven executable to run specific > > goals and phases during release (i.e. run versions plugin to change > version > > or run `mvn verify` to check project). > > In Jenkins you should run simple things like: > > mvn clean verify > > or if you deploy your artifacts to a repository manager: > > mvn clean deploy > > And check if your Jenkins uses the correct settings.xml (can be handled > via config-file-provider plugin in Jenkins). > > If you like to make a release in Jenkins use a freestyle job to execute > that... via `mvn release:prepare release:perform` > > I doubt that it would be a good idea to use git-flow-maven-plugin to > create a release ... Apart from that I think that git-flow is to complex > cause usually you don't need git flow with the complex branching model... > > Kind regards > Karl Heinz Marbaise > > > > > The gitflow-m-p uses a flag to set the executable which needs to know if > it > > is on Linux (run mvn) or Windows (run mvn.cmd). > > > > I was wondering what is the 'right' way to execute Maven from a plugin. > > I've taken a look at the Maven Release Plugin and that one uses an > internal > > Executor framework. I have thought about Toolchain, but I didn't find an > > example of a toolchain with Maven itself. > > > > Can anyone enlighten me? > > > > [1] https://github.com/aleksandr-m/gitflow-maven-plugin > > > > 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 > > >
Re: Preferred way to execute Maven goals/phases from Maven plugins
Thanks, I looked at the Maven Release Plugin and I see that the logic of where Maven is installed is not in the Maven-Invoker, but in the release plugin [1]. There is some logic on how to 'find' Maven, using environment variables like 'maven.home', 'MAVEN_HOME' and 'M2_HOME'. Does this mean that the choice of which setting is used and in which order is still the responsibility of the calling plugin? Or is there some standard for that? [1] https://github.com/apache/maven-release/blob/dbdf3a4a8cb8db51fa73963912555be4f39a89b8/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/InvokerMavenExecutor.java#L318 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 Mon, Nov 2, 2020 at 12:27 PM Thomas Broyer wrote: > Maybe have a look at Maven Invoker: > https://maven.apache.org/shared/maven-invoker/ > (it's what the Maven Invoker Plugin and Maven Release Plugin use) > > On Mon, Nov 2, 2020 at 11:28 AM Nick Stolwijk > wrote: > > > Hi folks, > > > > We are struggling with our buildserver (Jenkins) and the Git-Flow Maven > > Plugin[1] with regards to execute the Maven executable to run specific > > goals and phases during release (i.e. run versions plugin to change > version > > or run `mvn verify` to check project). > > > > The gitflow-m-p uses a flag to set the executable which needs to know if > it > > is on Linux (run mvn) or Windows (run mvn.cmd). > > > > I was wondering what is the 'right' way to execute Maven from a plugin. > > I've taken a look at the Maven Release Plugin and that one uses an > internal > > Executor framework. I have thought about Toolchain, but I didn't find an > > example of a toolchain with Maven itself. > > > > Can anyone enlighten me? > > > > [1] https://github.com/aleksandr-m/gitflow-maven-plugin > > > > 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 > > > > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> < > http://xn--nna.ma.xn--bwa-xxb.je/> >
Preferred way to execute Maven goals/phases from Maven plugins
Hi folks, We are struggling with our buildserver (Jenkins) and the Git-Flow Maven Plugin[1] with regards to execute the Maven executable to run specific goals and phases during release (i.e. run versions plugin to change version or run `mvn verify` to check project). The gitflow-m-p uses a flag to set the executable which needs to know if it is on Linux (run mvn) or Windows (run mvn.cmd). I was wondering what is the 'right' way to execute Maven from a plugin. I've taken a look at the Maven Release Plugin and that one uses an internal Executor framework. I have thought about Toolchain, but I didn't find an example of a toolchain with Maven itself. Can anyone enlighten me? [1] https://github.com/aleksandr-m/gitflow-maven-plugin 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
Re: Maven versions plugin check far too many versions
As far as I know you should use use-latest-versions, which does checks if you use the latest version of the imported pom and not the latest versions of the imported dependencies. With regard, 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 Wed, Oct 14, 2020 at 12:10 PM Matthieu BROUILLARD wrote: > You can filter the dependencies to look at using > > https://www.mojohaus.org/versions-maven-plugin/use-latest-releases-mojo.html#includesList > . > > Hope it helps. > > Matthieu > > On Wed, Oct 14, 2020 at 12:47 AM > wrote: > > > When I run "mvn versions:use-latest-releases" it checks for example for > > versions of the following: > > > > > > > > [INFO] artifact io.dropwizard.metrics:metrics-ehcache: checking for > updates > > from central > > > > [INFO] artifact io.dropwizard.metrics:metrics-ehcache: checking for > updates > > from snapshots > > > > [INFO] artifact io.dropwizard.metrics:metrics-graphite: checking for > > updates > > from central > > > > [INFO] artifact io.dropwizard.metrics:metrics-graphite: checking for > > updates > > from snapshots > > > > > > > > The lists goes on and on and on - but the problems is that my project > does > > not use this dependencies - although it does include spring-parent as > > dependency and these packages are declared here. Is there a way to tell > the > > plugin not to check for dependencies from some pom? My projects uses five > > dependencies and waiting 20 minutes (!) for these checks to be complete > is > > an absolute waste of time. > > > > > > > > JD > > > > > > > > >
Re: Maven Versions Plugin scans whole Maven repository
I had the same issue a while back [1]. We now use use-latest-versions and no longer use properties for versions most of the time. Hth, [1] https://www.mail-archive.com/users@maven.apache.org/msg142064.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 Wed, Jul 22, 2020 at 2:27 PM Dennis Lundberg wrote: > Hi, > > This is most likely due to a dependency on something from Spring Boot. I > have seen this as well. In many of the Spring Boot POMs they declare a ton > of dependencies in dependency management, to make sure all their components > use the same versions. The versions-maven-plugin might go through all of > them, because they are transitive dependencies of Spring Boot, depending on > how the dependency on Spring Boot artifact is declared and which Spring > Boot artifact it is. > > -- > Dennis Lundberg > > > Den lör 11 juli 2020 kl 08:39 skrev Lukáš Satin : > > > Hi, > > > > Maven Versions Plugin scans whole Maven repository. > > > > It takes about 1 hour and scans everything from com.google.* and > > org.springframework.* plus other packages while they are nowhere in the > > pom.xml! There is only org.springbootframework.boot, org.apache.commons, > > com.oracle! > > > > I read all articles, FAQ. > > > > Why is this behavior? How to make it update only actual dependencies > > present in pom.xml and not some transitive stuff? > > > > [INFO] artifact com.google.api.grpc:proto-google-cloud-bigtable-v2: > > checking for updates from snapshots > > [INFO] artifact com.google.api.grpc:proto-google-cloud-billing-v1: > checking > > for updates from central > > [INFO] artifact com.google.api.grpc:proto-google-cloud-billing-v1: > checking > > for updates from snapshots > > [INFO] artifact com.google.api.grpc:grpc-google-cloud-billing-v1: > checking > > for updates from central > > [INFO] artifact com.google.api.grpc:grpc-google-cloud-billing-v1: > checking > > for updates from snapshots > > [INFO] artifact com.google.cloud:google-cloud-billing: checking for > updates > > from central > > [INFO] artifact com.google.cloud:google-cloud-billing: checking for > updates > > from snapshots > > [INFO] artifact > > com.google.api.grpc:grpc-google-cloud-billingbudgets-v1beta1: checking > for > > updates from central > > [INFO] artifact > > com.google.api.grpc:grpc-google-cloud-billingbudgets-v1beta1: checking > for > > updates from snapshots > > [INFO] artifact > > com.google.api.grpc:proto-google-cloud-billingbudgets-v1beta1: checking > for > > updates from central > > [INFO] artifact > > com.google.api.grpc:proto-google-cloud-billingbudgets-v1beta1: checking > for > > updates from snapshots > > [INFO] artifact com.google.cloud:google-cloud-billingbudgets: checking > for > > updates from central > > [INFO] artifact com.google.cloud:google-cloud-billingbudgets: checking > for > > updates from snapshots > > [INFO] artifact com.google.api.grpc:grpc-google-cloud-build-v1: checking > > for updates from central > > [INFO] artifact com.google.api.grpc:grpc-google-cloud-build-v1: checking > > for updates from snapshots > > [INFO] artifact com.google.api.grpc:proto-google-cloud-build-v1: checking > > for updates from central > > [INFO] artifact com.google.api.grpc:proto-google-cloud-build-v1: checking > > for updates from snapshots > > [INFO] artifact com.google.cloud:google-cloud-build: checking for updates > > from central > > >
Re: dependency:tree without building the project (why does dependency:tree needs project artifacts installed?)
Hi, If you run maven dependency:tree, which version of the maven-dependency-plugin do you see? (Look for something like: [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ your-module ) And if it is something other than 3.1.2: * Why aren't you using the latest version? * Why don't you specify the plugins you are using in the pluginManagement section of your company pom? Ensuring the build environment is consistent is critical. Use the pluginManagement section in the parent POM to declare explicit plugin versions. This will nail down the plugin environment, removing potential future conflicts. It’s still good practice to regularly check for and update to the latest versions. 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 Thu, Jul 9, 2020 at 12:37 AM Anton Vodonosov wrote: > Hi, thank you for the responses. > > Currently I was trying on a multi-module project, and > > mvn dependency:tree > > fails complaining about the impossibility to find artifact for one of the > reactor modules, but > > mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:tree > > works. I've tried to debut a little but was unable to understand the > reason. > > So you say it should work for the whole project, but can fail if we > specify a subset of modules? > > In the past me and my colleagues were always building the project when > studying the dependency tree. > I don't remember when it failed, for the whole project or maybe we > encountered failures > when specifying specific modules using the -pl option. > > I will follow up if I have more info. > > Best regards, > - Anton > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: dependency:tree without building the project (why does dependency:tree needs project artifacts installed?)
That was not a workaround, but me trying to reproduce the problem. I wasn't able to reproduce it. All the artifacts in the reactor could be found without building them. Are you maybe trying to only build one module instead of the reactor? 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 Tue, Jul 7, 2020 at 9:17 PM Francois Marot wrote: > Hello, > > maybe the workaround indicated here will help you: > > http://maven.40175.n5.nabble.com/Finding-SNAPSHOT-dependencies-without-compiling-first-td5998636.html#a5998639 > But I'm not confident on the rasons why it works like this... > > > *- - - - -François Marot* > > > On Mon, 6 Jul 2020 at 23:16, Anton Vodonosov wrote: > > > Hello, > > > > Can anyone explain why "mvn dependency:tree" fails if the project > > artifacts are absent in ~/.m2? > > > > Also, if I place an empty, dummy file in place of the artifact in ~/.m2 > > dependency:tree starts working. > > This means the artifact content is not needed for that operation. > > > > Can this be worked around somehow, to allow producing project dependency > > without building the project? > > > > Best regards, > > - Anton > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: Maven brings “test” transitive dependency as “compile”
The verbose flag was removed in newer versions of the plugin. You could try an old pluginversion: mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree -Dverbose 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, May 23, 2020 at 7:53 PM Debraj Manna wrote: > Yes I saw the documentation. It is not behaving as expected. > > Can you let me know what is the alternative for maven dependency:tree > -Dverbose ? If I get the verbose mode for dependency:tree then I think > that will provide us more information. > > On Sat, May 23, 2020 at 6:09 PM Tomo Suzuki > wrote: > > > Debraj, > > > > I couldn't reproduce the problem in my setting. Netty-common appears as > > test scope. > > https://gist.github.com/suztomo/69f854bddd102b3fe83eae8f0720c494 > > > > Would you be willing to create a minimum reproducible project? > > Hopefully it builds only artifacts available on the public Internet (no > > artifactory.arkin.local:8000). > > > > BTW, this is the documentation I think your Maven tree is not behaving as > > documented: > > > > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope > > > > > > > > > > On Sat, May 23, 2020 at 12:40 AM Debraj Manna > > wrote: > > > > > Thanks Andy for replying. > > > > > > maven dependency:tree -Dverbose does not seem to work for me. It gives > me > > > the below message > > > > > > ... > > > [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ delete > --- > > > [INFO] Verbose not supported since maven-dependency-plugin 3.0 > > > [INFO] com.vnera:delete:jar:0.001-SNAPSHOT > > > ... > > > > > > If I just exclude netty-common from apache-bookkeeper then netty-common > > > 4.1.32 does not show up in the dependency tree. > > > > > > > > > On Sat, May 23, 2020 at 3:57 AM Andy Feldman > > > wrote: > > > > > > > On Fri, May 22, 2020 at 6:31 AM Debraj Manna < > subharaj.ma...@gmail.com > > > > > > > wrote: > > > > > > > > > bookkeeper-common is in test scope but still netty-common is > showing > > up > > > > as > > > > > compile dependency. > > > > > > > > > > > > > Is it possible that netty-common is a transitive dependency of > another > > > > dependency as well? Running dependency:tree does not show all paths > to > > > each > > > > dependency. > > > > > > > > You can try running dependency:tree with the verbose flag to see more > > > > branches of the tree, although the documentation says it is not > > > guaranteed > > > > to work properly with Maven 3. > > > > > > > > > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose > > > > > > > > You can also try removing the dependency on bookkeeper-common and > > running > > > > dependency:tree again to see if netty-common still shows up. > > > > > > > > -- > > > > Andy Feldman > > > > Wealthfront > > > > > > > > > > > > > -- > > Regards, > > Tomo > > >
Re: Finding SNAPSHOT dependencies without compiling first
Hello, I don't think I can reproduce your problem. I've tried this on one of my multimodules. 1. Remove everything of the multimodule from the local repository. 2. Run mvn dependency:tree -Dincludes=*:*:*:*-SNAPSHOT Output: https://gist.github.com/nickstolwijk/4042c9ca4a71bc4886ac528b6621e5c6 3. Check local repository, nothing of my project is there. My output shows SNAPSHOT dependencies inside my project. 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 Wed, May 6, 2020 at 11:14 AM Francois MAROT wrote: > Hello all, > > I have a simple requirement: I would like to determine very fast if my > multi-module project has any SNAPSHOT dependency. > > First try was with the /mvn dependency:tree / command and grepping for the > word SNAPSHOT. But the dependency plugin seems to use the repository > dependencies, so it is not able to resolve inter-module dependencies > without > first having to INSTALL the dependencies. > > A workaround is to use: > /mvn compile dependency:tree -Dmaven.main.skip=true/ > It seems this command initializes enough of the build plan so that Maven is > able to resolve internal (inter-modules) dependencies. The > "/maven.main.skip/" is used to optimize the speed by skipping the actual > compilation. In my case I had to also add a /-DskipSourceGeneration=true/ > because a source generation step was relying on the source being compiled. > > I also tried with the enforcer plugin which now allows rules to be passed > on > the command line. But the result is the same, the build plan seems not to > be > build hence dependency resolution is done through the repository and fails > if all jars are not INSTALLED first. As previously the workaround is to > force a fake "compile" step: > > /mvn clean compile > org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M3:enforce > -Drules=requireReleaseDeps -Dmaven.main.skip=true > -DskipSourceGeneration=true/ > > So the question is: is there really no way to have the full dependency > graph > without all those hacks ? > > > > -- > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Best Practice for distributing test utilities?
Put the testutils and the tests in the same project as foo in src/test/java and make the tests package private (JUnit Jupiter). Other projects can depend on the test artifact of foo and only use the test-utils. 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, Mar 13, 2020 at 12:01 PM Zak Mc Kracken wrote: > On 12/03/2020 13:55, Andreas Sewe wrote: > > If the test utilities are simple enough and are somehow specific to foo, > I would put them into foo, under src/main/java, in a package like > com.foo.testing. If they are more general, so that they could be used to > write tests for some other package not related to foo, I would create a > test-utils module. For instance, a utility to verify that an SQL string > parameter yields a given result parameter would go into such a module. > > If the test utils so complex that foo would become too big and would > drag too many not-often-used dependencies, but they're foo-specific, I > would create the module foo-test-utils and both foo and foo-testing > would depend on it. This is similar to creating test-utils. > > Option 3 creates a circular dependency and it's not to clean anyway > (even if you had a way to remove the circularity from the technical > point of view, it would remain at conceptual level). Attaching tests > seems to be less clear and forces a dependant to link all the tests just > to be able to include some utility. I happened to do it only for already > existing and hard-to-refactor projects, and only for the purpose making > the dependant extract some common files inside test/resources. > > Hope it helps, > Marco > > > Hi, > > > > I am struggling to figure out what the Maven Way is for distributing > > test utils. > > > > Say I have a project "foo" along with some unit tests for it. Moreover, > > I have some utilities that help in testing "foo" (e.g., test data > > builders or test fixtures). These utilities are used by the unit tests > > for "foo", but may also be useful to projects depending on "foo" (e.g., > > a FooTestDataBuilder that produces Foo instances could also be used in > > the tests of a dependent project "bar"). > > > > The question is where to place these test utilities and how to depend on > > them. > > > > 1. I could follow the "guide to using attached tests" [1], place the > > test utilizes in foo/src/test/java, and attach the test-jar to "foo". > > Then, a dependent project "bar" could depend on the test-jar in its test > > scope. Alas, as the test scope is not transitive, I would need to > > declare all test-dependencies of "foo" again in "bar", even though I may > > not even use them directly (e.g., if the FooTestDataBuilder uses them > > only internally). > > > > 2. I could split "foo" into three projects: "foo", "foo-test-utils", and > > "foo-tests", with the latter depending on both "foo-test-utils" and > > "foo-tests". A project "bar" would then simply depend on "foo" in > > compile scope and "foo-test-utils" in test scope. This would make all > > dependencies explicit, but would result in some oddities, e.g., > > foo-tests/src/main/java being empty, as all tests need to be placed in > > tests/src/test/java to be picked up by Surefire. > > > > 3. I could split "foo" into just two projects, "foo" and "foo-testing". > > foo-testing/src/main/java would the contain the test utilities for > > "foo", whereas foo-testing/src/test/java would contain the actual tests. > > This is again somewhat odd, as the tests in foo-testing/src/test/java > > are not testing "foo-testing" but "foo". > > > > 4. Option 4 is the most natural way, but unfortunately it doesn't work, > > because it introduces a cyclic dependency: Have "foo" and > > "foo-test-utils" and let the tests of "foo" depend on "foo-test-utils". > > > > Am I missing something? In particular, why is [1] apparently the > > recommended approach, even though it requires you to duplicate > > dependency information? > > > > Any suggestions are greatly appreciated. > > > > Best wishes, > > > > Andreas > > > > [1] <https://maven.apache.org/guides/mini/guide-attached-tests.html> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Use latest versions vs use latest releases
We are trying to upgrade the dependencies of our projects by using the Maven Versions plugin. I read the page at the Maven Versions plugin[1] and I am confused. The goal description for use-latest-releases reads: `searches the pom for all non-SNAPSHOT versions` while the table reads that only -SNAPSHOT dependencies are considered. On the other hand there is the use-latest-versions goal which says: `searches the pom for all versions which have been a newer version` and considers release and snapshot versions according to the table. Based on that information I think I need use-latest-versions. Am I correct? There is only a problem with use-latest-versions. It replaces properties and instead using the versions itself[2]. Although that issue is closed as won't fix. If I use use-latest-releases I stumble upon issue 346[3], which has a fix in a fork, but isn't yet merged. Which goal is the correct goal, which issues are still open issues and what is needed to make this more clear? [1] https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html [2] https://github.com/mojohaus/versions-maven-plugin/issues/109 [3] https://github.com/mojohaus/versions-maven-plugin/issues/346 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
Maven Pom Property replacement - possible bug?
Hi list,
I've seen some strange behavior with pom property replacement and I was
wondering if this is a bug or expected behaviour.
I have a sample project[1] with the build-helper-maven-plugin which I try
to configure to use the regex-property goal.
Since Java 7 the Regexp matcher of Java understands named groups, but they
use the same notation as Maven properties, i.e. ${name}
I tried:
org.codehaus.mojo
build-helper-maven-plugin
${regexVersion}${regexGroupId}
I expected Maven to not touch my variables if it couldn't replace them. So
I was a little confused when I executed mvn -X and saw the following output:
[DEBUG] (f) replacement = ${regexVersion}null
It looks like Maven didn't touch the first variable but it replaced the
second with null.
First question: is this expected behaviour?
Second question: how can I escape variables so that Maven doesn't try to
escape them?
[1] https://github.com/nickstolwijk/MavenPropReplacement.git
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
Re: Why is Maven calling nonexistent Artifactory?
Hi Roger, As far as I know there is no other repository then Maven Central baked into Maven. I guess it is configured somewhere in your settings or pom structure. You can take a good look at the settings Maven use by using the Maven Help plugin. Try executing mvn help:effective-pom and mvn help:effective-settings and take a look at the output to see if it is your settings or your pom files that add that repository. If it is in your settings it should be in ~/.m2/settings.xml or MAVEN_HOME/conf/settings.xml, otherwise if it is in your project configuration (pom.xml) it is in your pom or in any of the parent poms of your project. 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 Wed, Jan 15, 2020 at 11:15 PM Worden, Roger wrote: > New install of Maven 3.6.3 on Mac Mojave. Trying to build a local copy of > a third-party vendor’s app. Command is: > > mvn dependency:tree -DoutputType=dot --file="pom.xml" > > Maven says the following for many objects: > > Downloading from vendor-repo: > http://192.168.2.57:8081/artifactory/ProjectLibs/it/vendor/Filters/6.6.1/Filters-6.6.1.pom > > and then often: > > Transfer failed for http://192.168.2.57:8081/artifactory … > /maven-metadata.xml > > I do not have Artifactory on my Mac. > I have searched all through the Maven config and other files and can find > no reference to Artifactory. > I have searched all through the vendor files and can find no reference to > Artifactory. > > Is this some default built into Maven? A “strings” search of man did not > find any reference to Artifactory. > > I’ve tried to add repository info to my settings.xml to disable it, but > have not succeeded. > > Thanks in advance. >
Publishing Maven site as an docker image
Hi folks, Has anyone tried to publish the site generated by Maven as a docker image? Are there examples of such a setup? 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
Re: Using Maven outside of L/M/WAMP environment
> > 2. Can Maven be used outside of a *AMP environment? I may be > misinterpreting > the use of Maven in this way but with it being a part of the Apache > Project, > I’m assuming a *AMP server is required to create a system with Maven as a > part of it. The Apache Software Foundation (ASF, apache.org) is housing multiple projects. The Apache HTTP server in AMP is only one of those projects, others are for example, are Maven, but also Subversion.[1] SO, no, you don't need Maven to run Apache HTTP server. You can use Maven to build your Java projects, or even other types of projects. It is only unfortunately so, that the ASF and Apache HTTP server are both called 'apache'. With regards, Nick Stolwijk [1] https://projects.apache.org/projects.html ~~~ 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 Wed, Oct 30, 2019 at 10:27 PM New_Tech wrote: > I am a new programmer and have started the “on paper” design of my first > project. While reading a tutorial on linking a Java program to a MySQL DB, > I was introduced to Maven as part of the conduit between Java and the DB. I > have a couple of questions about this. > > 1. Is Maven an absolute requirement to allow communication between those > two > entities? > > > > If this is the wrong place for this post please direct me to the correct > area. Any helpful resources to understand Maven’s purpose and necessity are > much appreciated. > > Thank you > > > > -- > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Company-wide pom and dependency management best practices
Thanks Tomo, > I use "mvn dependency:tree -Dverbose=true" to get the detail of tree. It shows unselected nodes. The only problem with the verbose route is that it can show wrong results on Maven 3[1][2]. I was hoping for a non-deprecated solution. [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose [2] http://maven.apache.org/shared/maven-dependency-tree/ > I would also take your approach of "a dependency management pom" (BOM, bill of materials) to control transitive dependencies. Yeah, it seems that would be the best option. 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 Tue, Aug 6, 2019 at 4:40 PM Tomo Suzuki wrote: > Hi Nick, > > > I see where the different versions for a dependency are coming from? > > I use "mvn dependency:tree -Dverbose=true" to get the detail of tree. It > shows unselected nodes. > > > how can I make sure that the dependencies in the Spring Boot import take > preference over the other dependency imports > > I would also take your approach of "a dependency management pom" (BOM, bill > of materials) to control transitive dependencies. > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management > > > On Tue, Aug 6, 2019 at 10:31 AM Nick Stolwijk > wrote: > > > Hi all, > > > > We have a company-wide pom for specific applications. In our case for > > Spring Boot applications. In this pom some of the stuff is for the build > > (plugin management, deployment management) and some for the dependencies > > (scope import for dependencyManagement). > > > > We had a buildproblem where one of the Spring Boot dependencies had the > > wrong version. It turned out the version of one of the dependencies for > > Spring Boot was overridden by another dependencyManagement import. > > > > The first question is, how can I see where the different versions for a > > dependency are coming from? I know of the dependency:tree, but that only > > shows the resolved version and not all the version options. > > > > The second question is, how can I make sure that the dependencies in the > > Spring Boot import take preference over the other dependency imports. My > > idea is to break apart the Spring Boot parent we have into a build pom > and > > a dependency management pom and require that every application import the > > dependency import pom as first dependency under dependency management. > > Would this work or am I missing something? > > > > Is there any documentation about the best practices for inheriting build > > configuration and dependency management? > > > > 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 > > > > > -- > Regards, > Tomo >
Company-wide pom and dependency management best practices
Hi all, We have a company-wide pom for specific applications. In our case for Spring Boot applications. In this pom some of the stuff is for the build (plugin management, deployment management) and some for the dependencies (scope import for dependencyManagement). We had a buildproblem where one of the Spring Boot dependencies had the wrong version. It turned out the version of one of the dependencies for Spring Boot was overridden by another dependencyManagement import. The first question is, how can I see where the different versions for a dependency are coming from? I know of the dependency:tree, but that only shows the resolved version and not all the version options. The second question is, how can I make sure that the dependencies in the Spring Boot import take preference over the other dependency imports. My idea is to break apart the Spring Boot parent we have into a build pom and a dependency management pom and require that every application import the dependency import pom as first dependency under dependency management. Would this work or am I missing something? Is there any documentation about the best practices for inheriting build configuration and dependency management? 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
Re: Maven Versions plugin transitive dependency updates
Hi all, I don't see much progress on this issue: [1] & [2]. Are there any good reasons not to use this flag, since it is still experimental? I want to take a shot at implementing this in the display-dependency-updates goal, and was wondering if anyone has a good opinion about using/not using this flag. [1] https://github.com/mojohaus/versions-maven-plugin/issues/291 [2] https://github.com/mojohaus/versions-maven-plugin/issues/267 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 Wed, Sep 5, 2018 at 11:48 AM Nick Stolwijk wrote: > Hi, > > I was wondering why the parameter processDependencyManagementTransitive is > available on the dependency-updates-report goal[1] of the Versions Maven > Plugin but isn't available on its counter-part display-dependency-updates > [2] > ? > > > With regards, > > Nick Stolwijk > > [1] > https://www.mojohaus.org/versions-maven-plugin/dependency-updates-report-mojo.html > [2] > https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html > > > ~~~ 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 >
Re: Build using toolchains version, but run unit tests against various JDKs?
Hello, I found this old mail about running test multiple times with different JDK's. Has there been any work done to make this possible? Or is the best possible solution to use the CI server to run multiple runs with different JDK's, perhaps using toolchain. 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, Mar 4, 2017 at 3:31 AM Hervé BOUTEMY wrote: > yes, using the JDK selected by the toolchain plugin was until recently the > intent of toolchain-plugin: help being consistent in every plugin > requiring to > use a JDK that is different from the JRE used to launch Maven > > now that it works as expected, there are new use cases arising where the > toolchain mechanism is not seen any more as a way to easily *consistently* > select a jdk, but to easily switch between multiple JDKs *differently in > some > plugins executions* > > This is not the same use case: the toolchain definition mecanism > (toolchain.xml) is the same, but selection algorithm is different. > > There was already MNG-5755 [1] implemented in Maven 3.3.1 to prepare hooks > in > Maven core and explain some use cases. > Since then, I know some use cases have been implemented but others not > yet: > I'll try to link related issues in plugins that use the feature. > > In your use case, there is one additional issue: you want to run unit > tests > multiple times, each time with a different JDK configuration. > This will require new feature in Surefire plugin, with extra care on > usability > issues to be sure the new configuration can be understood by normal people. > > Currently, there is a lot of work ongoing on Surefire: this new feature > probably won't be first priority, but in the future, why not. > > Regards, > > Hervé > > > [1] https://issues.apache.org/jira/browse/MNG-5755 > > Le vendredi 3 mars 2017, 07:42:45 CET Russell Gold a écrit : > > I am using the toolchains plugin to ensure that the jars are produced > with > > the correct JDK version; however, I want to be able to unit test against > > both that version and later versions. Is there a way to do that? The > > surefire plugin just selects the same version as was used to build. > > > > Thanks, > > Russ > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Enforce no local versions
If that's the case then maybe take a look at the analyze-dep-mgt goal of the dependency plugin.[1] Hth, Nick Stolwijk [1] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt-mojo.html ~~~ 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 Tue, Jan 29, 2019 at 11:42 AM Mikael Åsberg wrote: > He wants to ensure that no managed versions I are overridden. > > On Jan 29, 2019 11:40, "Tamás Cservenák" wrote: > > So, if I understand correctly: to enforce there is no reactor project in > depMgt section of child modules? > > On Tue, Jan 29, 2019 at 12:48 AM Jörg Schaible > wrote: > > > > On Mon, 28 Jan 2019 22:34:56 +0100 Harald Wellmann wrote: > > > > > Do you mean a rule to enforce no snapshot dependencies? In that case, > > > there is a rule called "requireReleaseDeps". > > > > No. > > > > > "No local versions" does not really make sense to me, because any > remote > > > dependency will first be downloaded to your local repository. > > > > It has nothing to do with repositories. We manage versions in a depMgmt > > section the parent of a multi- > > project and no-one should declare own versions for his dependencies in > the > > sub projects. > > > > Regards, > > Jörg > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Maven Versions plugin transitive dependency updates
Hi, I was wondering why the parameter processDependencyManagementTransitive is available on the dependency-updates-report goal[1] of the Versions Maven Plugin but isn't available on its counter-part display-dependency-updates [2] ? With regards, Nick Stolwijk [1] https://www.mojohaus.org/versions-maven-plugin/dependency-updates-report-mojo.html [2] https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html ~~~ 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
Re: Problem with Maven Tutorial
You can add the properties tag directly under the root element () of your POM[1] file. 1. 2. 1.8 3. 1.8 4. [1] Project Object Model The default source level is still at 1.5, due to backward compatibility issues. 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 Thu, Jul 26, 2018 at 10:09 PM Scott Miller wrote: > Hi, > > I am trying to use Maven for the first time. I have it installed and was > working on this tutorial: > > https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html > > I got to this step: > > >1. mvn package > > Where I got the following error: > > BUILD FAILURE > [INFO] > > [INFO] Total time: 3.123 s > [INFO] Finished at: 2018-07-26T08:30:10-07:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.1:compile > (default-compile) on project my-app: Compilation failure: Compilation > failure: > [ERROR] Source option 5 is no longer supported. Use 6 or later. > [ERROR] Target option 1.5 is no longer supported. Use 1.6 or later. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > My research about this error led me to this page: > > > https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html > > Now I am stuck. Where do I find these files? Is there any more information > to be gleaned of exactly what my edits should be? > > I am assuming I am doing something wrong because I would expect the Maven > tutorial has been tested. > > TIA > > Scott >
Re: How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?
You can ban duplicate classes with the enforcer plugin [1]. [1] http://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.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 Wed, Apr 11, 2018 at 10:39 AM Debraj Manna <subharaj.ma...@gmail.com> wrote: > I have seen a similar question being answered in stackoverflow > > > https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infamous-multiple-bindings-warning-at-build-time > > Is it possible achieve something like this via maven build also ? >
Re: Compile scope dependency, used as runtime scope transitively
But I think that he wants it transitive, but only at runtime scope instead of compile time. I also wondered a while ago if this was possible. It would be nice to keep clean projects clean. (As in, declared all compile time dependencies instead of relying on transitive compile time dependencies.) Would implementing this be an addition to the dependencies plugin? (crossing fingers, I guess this is done in Maven itself and not in a plugin). 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 Wed, Dec 27, 2017 at 10:54 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > So you could have scope=compile=true (which means the dep is > non-transitive) > > On Wed 27 Dec 2017 at 00:26, Andy Feldman <an...@wealthfront.com> wrote: > > > On Dec 26, 2017 11:34, "Stephen Connolly" <stephen.alan.connolly@gmail. > com > > > > > wrote: > > > > On Sun 24 Dec 2017 at 18:01, Andy Feldman <an...@wealthfront.com> wrote: > > > > > Assuming I have a dependency relationship of "my-project -> my-library > -> > > > upstream-library", with each dependency in compile scope, I know that > > > my-project transitively picks up a compile scope dependency on > > > upstream-library. Reading the documentation at > > > > > > https://maven.apache.org/guides/introduction/ > introduction-to-dependency- > > mechanism.html > > <https://maven.apache.org/guides/introduction/ > introduction-to-dependency-mechanism.html> > > > I see a note about this transitive dependency: > > > > > > "(*) Note: it is intended that this should be runtime scope instead, so > > > that all compile dependencies must be explicitly listed - however, > there > > is > > > the case where the library you depend on extends a class from another > > > library, forcing you to have available at compile time. For this > reason, > > > compile time dependencies remain as compile scope even when they are > > > transitive." > > > > > > If I know that my-library does not have this issue, is there any way to > > > declare the dependencies such that I can get the intended behavior? I > > want > > > upstream-library to be picked up as runtime scope for my-project, not > as > > > compile scope. > > > > > > Declare it with scope “runtime”? > > > > > > It needs to be compile scope in my-library since my-library uses classes > > from upstream-library. I'd like to avoid declaring upstream-library at > all > > in my-project if possible, since my-project has nothing to do with > > upstream-library. > > > > > > > > > > > > > Thanks, > > > -- > > > Andy Feldman > > > > > -- > > Sent from my phone > > > -- > Sent from my phone >
Re: "Perhaps you are running on a JRE rather than a JDK?" error building with maven.
On Fri, Feb 26, 2016 at 3:24 PM, Gintare Ragaisiene < gintare.ragaisi...@gmail.com> wrote: > Java home: /home/user/ProgramFiles/jdk1.8.0_71/jre > You are using the JRE which is delivered with the JDK. Try setting your JAVA_HOME and your PATH variables to the JDK bin directory instead of the JRE bin directory. 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
Re: mvn -nsu (--no-snapshot-updates) is still downloading SNAPSHOT versions
Maven is not downloading updates, but only the SNAPSHOTS it is missing. If you build another time it won't download anything and even if your update window (mostly daily) has been passed Maven will not look for new updates but use the ones it has locally. If you want to know which dependencies needs updates you can use the versions plugin. - versions:display-dependency-updates http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html scans a project's dependencies and produces a report of those dependencies which have newer versions available. - versions:display-plugin-updates http://mojo.codehaus.org/versions-maven-plugin/display-plugin-updates-mojo.html scans a project's plugins and produces a report of those plugins which have newer versions available. - versions:display-property-updates http://mojo.codehaus.org/versions-maven-plugin/display-property-updates-mojo.html scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. 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 Tue, May 26, 2015 at 11:18 AM, Robert Metzger rmetz...@apache.org wrote: Hi, At our project we recently had an issue where we accidentally included outdated artifacts (which were still available on snapshot repositories). To detect those issues in the future by our integration tests, I want to instruct maven not to download snapshot updates, using the -nsu command line argument. However, doing mvn clean install -nsu -DskipTests -Dmaven.repo.local=/tmp/test-mvn will still lead to: [INFO] [INFO] Building flink-language-binding-generic 0.9-SNAPSHOT [INFO] Downloading: http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/maven-metadata.xmlDownloaded : http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/maven-metadata.xml (2 KB at 0.8 KB/sec)Downloading: http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.pomDownloaded : http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.pom (4 KB at 5.7 KB/sec)Downloading: http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.jarDownloaded : http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.jar (2660 KB at 379.7 KB/sec) I've added the steps to reproduce here: https://issues.apache.org/jira/browse/MNG-5064?focusedCommentId=14551952page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14551952 I would like to know whether I misunderstood the feature or if this is a bug. Best, Robert
Re: Building selected projects with nested aggregators
Hello all, We also want to build a --project-list with a aggregator pom, so all the modules of that pom are getting build. In the mean time, we also want the dependencies of those module to build. (So, --also-make). Only we can't get this to run. Is there anyone who can help with this? We were thinking of a Bash or Groovy script to parse the aggregator pom to build up the --project-list argument. Does anyone see an easier way? 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 Tue, May 7, 2013 at 2:39 AM, spoots spootsy.oo...@gmail.com wrote: Thanks for the reply, again :) I don't think -amd covers my need though. Because there's no parent/child relationship between the modules/sub-modules there's no dependency between them. It feels to me like there's an option missing for the reactor here... A simpler example for clarity: lt;agt; lt;bgt; lt;c /gt; lt;d /gt; lt;e /gt; lt;/bgt; lt;f /gt; lt;g /gt; lt;/agt; Each node is a project, and sub-projects are nested. For dependencies, say only that c depends on f. There are no parent-child relationships. If I want to build lt;bgt; with all its sub-modules (lt;cgt; lt;dgt; lt;egt;) and dependencies (lt;fgt;), can I do that? The only options I see are: 1 - change to b directory, then mvn install 2 - from top level, mvn install -pl a/b -amd 3 - from top level, mvn install -pl a/b/c,a/b/d,a/b/e -amd Option 1 builds the sub-modules I want, but doesn't build the dependency lt;fgt;. Option 2 only builds the project lt;bgt;, none of it's sub-modules because they are not dependents. Option 3 works, but it's no good because I need to know provide all the sub-modules of lt;bgt;. Ideally there'd be an option like -ams (also make sub-modules) which I could use in option 2, but I can't see any way to do it? -- View this message in context: http://maven.40175.n5.nabble.com/Building-selected-projects-with-nested-aggregators-tp5753572p5755076.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
E-Book Beter Builds with Maven seems to be missing
Hi all, It seems the link from the External Resources[1] to the e-book Beter Builds with Maven'[2] is broken. Is this still being hosted elsewhere? (I couldn't find it with a quick search) Or should we remove it from our site? [1] http://maven.apache.org/articles.html [2] http://www.maestrodev.com/better-build-maven 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
Re: Log4J - cannot find symbol - method trace(String)
You can use the dependency:tree[1] goal to view a tree of your dependencies to see if the correct version of Log4J is being included in the compiler classpath. [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.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 Wed, Apr 30, 2014 at 1:41 PM, Dušan Rychnovský geraltzri...@gmail.com wrote: Hi everyone, I have the following dependency in my project's POM: ... dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.17/version /dependency ... The artifact is downloaded to my local repository, but, during the compile phase, the following error is emitted and the build process is aborted: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project dbtoixattrdt: Compilation failure: Compilation failure: [ERROR] d:\prace\dbtoixattrdt\DBToIXATTRDT-TRUNK\src\main\java\dbtoixattrdt\TraceLogAspect.java:[19,8] error: cannot find symbol [ERROR] symbol: method trace(String) [ERROR] location: variable logger of type Logger This error message does not make much sense, as the trace method should be available on the Logger class in Log4J version 1.2.17. What can be wrong? Thanks in advance, Dušan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Log4J - cannot find symbol - method trace(String)
Could you check your checksum on the log4j jar file? Maybe there is some corruption in your repository. 02:28:40 ~/.m2/repository/log4j/log4j/1.2.17$ ls -altr log4j-1.2.17.jar -rw-r--r-- 1 nick nick 489884 Jan 8 13:31 log4j-1.2.17.jar 02:28:45 ~/.m2/repository/log4j/log4j/1.2.17$ sha1sum log4j-1.2.17.jar 5af35056b4d257e4b64b9e8069c0746e8b08629f log4j-1.2.17.jar 02:28:47 ~/.m2/repository/log4j/log4j/1.2.17$ cat log4j-1.2.17.jar.sha1 5af35056b4d257e4b64b9e8069c0746e8b08629f 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 Wed, Apr 30, 2014 at 2:00 PM, Dušan Rychnovský geraltzri...@gmail.com wrote: Thank you both for your help. Unfortunatelly, neither seems to be the case. * dependency:tree confirmed that version 1.2.17 is beeing used indeed (log4j:log4j:jar:1.2.17:compile), * I have verified that the import statement is correct (import org.apache.log4j.Logger;). Dušan 2014-04-30 13:55 GMT+02:00 Stuart McCulloch mccu...@gmail.com: Also check your java imports, just in case you’ve imported a different Logger by mistake (such as java.util.logging.Logger) On 30 Apr 2014, at 12:48, Nick Stolwijk nick.stolw...@gmail.com wrote: You can use the dependency:tree[1] goal to view a tree of your dependencies to see if the correct version of Log4J is being included in the compiler classpath. [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.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 Wed, Apr 30, 2014 at 1:41 PM, Dušan Rychnovský geraltzri...@gmail.com wrote: Hi everyone, I have the following dependency in my project's POM: ... dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.17/version /dependency ... The artifact is downloaded to my local repository, but, during the compile phase, the following error is emitted and the build process is aborted: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project dbtoixattrdt: Compilation failure: Compilation failure: [ERROR] d:\prace\dbtoixattrdt\DBToIXATTRDT-TRUNK\src\main\java\dbtoixattrdt\TraceLogAspect.java:[19,8] error: cannot find symbol [ERROR] symbol: method trace(String) [ERROR] location: variable logger of type Logger This error message does not make much sense, as the trace method should be available on the Logger class in Log4J version 1.2.17. What can be wrong? Thanks in advance, Dušan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Log4J - cannot find symbol - method trace(String)
And for another thought: maybe of your other dependencies include the
org.apache.log4j.Logger class but with a different version.
Check with maven copy dependencies and a grep over the contents of all
the jar files.
Here is how I do it:
02:40:48 {master} ~/sandbox/bowling-nickstolwijk$ mvn
dependency:copy-dependencies
[INFO] Scanning for projects...
[INFO]
[INFO] Using the builder
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
with a thread count of 1
[INFO]
[INFO]
[INFO] Building bowling-nickstolwijk 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.8:copy-dependencies (default-cli)
@ bowling-nickstolwijk ---
[INFO] hamcrest-core-1.3.jar already exists in destination.
[INFO] junit-4.11.jar already exists in destination.
[INFO] hamcrest-library-1.3.jar already exists in destination.
[INFO] mockito-core-1.9.5.jar already exists in destination.
[INFO] objenesis-1.0.jar already exists in destination.
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.143 s
[INFO] Finished at: 2014-04-30T14:41:08+01:00
[INFO] Final Memory: 9M/153M
[INFO]
02:41:08 {master} ~/sandbox/bowling-nickstolwijk$ cd target/dependency/
02:41:16 {master} ~/sandbox/bowling-nickstolwijk/target/dependency$
findjar.sh . Logger
Starting search for JAR files from directory .
Looking for the class Logger
This might take a while...
org/mockito/internal/debugging/VerboseMockInvocationLogger.class
org/mockito/internal/debugging/VerboseMockInvocationLogger.java
org/mockito/internal/util/ConsoleMockitoLogger.class
org/mockito/internal/util/ConsoleMockitoLogger.java
org/mockito/internal/util/MockitoLogger.class
org/mockito/internal/util/MockitoLogger.java
org/mockito/internal/util/SimpleMockitoLogger.class
org/mockito/internal/util/SimpleMockitoLogger.java
./mockito-core-1.9.5.jar
02:41:20 {master} ~/sandbox/bowling-nickstolwijk/target/dependency$
cat ~/bin/findjar.sh
#!/bin/sh
#
# findjar.sh by Samuli Kaski
#
VERBOSE=no
if [ $# -ne 2 ]; then
echo Usage: findjar.sh path classname;
exit;
fi
STARTPATH=$1
CLASS=$2
echo Starting search for JAR files from directory $STARTPATH
echo Looking for the class $CLASS
echo
echo This might take a while...
echo
for jar in `find $STARTPATH -name '*.jar'`;
do
BASENAME=`basename $jar`
jar -tf $jar | grep $CLASS
if [ $? -eq 0 ]; then
echo $jar
fi
done
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 Wed, Apr 30, 2014 at 2:29 PM, Nick Stolwijk nick.stolw...@gmail.com wrote:
Could you check your checksum on the log4j jar file? Maybe there is
some corruption in your repository.
02:28:40 ~/.m2/repository/log4j/log4j/1.2.17$ ls -altr log4j-1.2.17.jar
-rw-r--r-- 1 nick nick 489884 Jan 8 13:31 log4j-1.2.17.jar
02:28:45 ~/.m2/repository/log4j/log4j/1.2.17$ sha1sum log4j-1.2.17.jar
5af35056b4d257e4b64b9e8069c0746e8b08629f log4j-1.2.17.jar
02:28:47 ~/.m2/repository/log4j/log4j/1.2.17$ cat log4j-1.2.17.jar.sha1
5af35056b4d257e4b64b9e8069c0746e8b08629f
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 Wed, Apr 30, 2014 at 2:00 PM, Dušan Rychnovský
geraltzri...@gmail.com wrote:
Thank you both for your help. Unfortunatelly, neither seems to be the case.
* dependency:tree confirmed that version 1.2.17 is beeing used indeed
(log4j:log4j:jar:1.2.17:compile),
* I have verified that the import statement is correct (import
org.apache.log4j.Logger;).
Dušan
2014-04-30 13:55 GMT+02:00 Stuart McCulloch mccu...@gmail.com:
Also check your java imports, just in case you’ve imported a different
Logger by mistake (such as java.util.logging.Logger)
On 30 Apr 2014, at 12:48, Nick Stolwijk nick.stolw...@gmail.com wrote:
You can use the dependency:tree[1] goal to view a tree of your
dependencies to see if the correct version of Log4J is being included
in the compiler classpath.
[1]
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.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 Wed, Apr 30, 2014 at 1:41 PM, Dušan Rychnovský
geraltzri
Maven Jar Plugin - Testjar: includes together with skipIfEmpty
Hi Folks, I found a little curiosity in the maven jar plugin. if you specify includes and the skipIfEmpty property a jar is still created and attached while it only has a pom file in it. I would have expected that the creation of the jar was skipped if no files where selected by my includes property. My usecase: I only want to generate the tests jar when there are builders in the module, so other modules can use those builders in their tests. I don't want to package all tests, to prevent developers to create dependencies on these tests. My configuration: plugin artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals configuration skipIfEmptytrue/skipIfEmpty includes include**/*Builder.class/include /includes /configuration /execution /executions /plugin 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Depend on a jar via another pom file
That's called a transitive dependency and this blog[1] explains nicely why you shouldn't use those. [1] http://uglycoder.blogspot.nl/2008/04/flaw-with-mavens-transitive.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 Wed, Jan 8, 2014 at 4:56 PM, Omar@Gmail omarnet...@googlemail.comwrote: I have a maven module (lets call it M) that requires aspectjrt but M already depends on another pom file that has aspectjrt within its dependency tree like so: M - middle pom - aspectjrt The problem is M would not compile unless I express the aspectjrt dependency directly in the M pom file, why? Is there a way for M to get apsectjrt via the middle pom without directly depending on aspectjrt?
Re: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Probably you have the xxx-shared artifact already in your local repository from an earlier invocation, so it won't get looked up in Nexus, while your colleague doesn't. I think your parent part of the pom should look something like this: parent groupIdxxx.xxx.xxx/groupId artifactIdxxx-shared/artifactId version2.0.26-SNAPSHOT/version relativePath../xxx-shared/pom.xml/relativePath /parent Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and rebuild. I guess without setting the relativePath you will see the same error as your colleague. Hth, Nick Stolwijk On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson to...@natusoft.se wrote: parent groupIdxxx.xxx.xxx/groupId artifactIdxxx-shared/artifactId version2.0.26-SNAPSHOT/version /parent 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
Re: Trying to understand how maven finds source
Maybe it is mustard after the mail (as the Dutch call it. ;) ), but here is a nice article about the standard directory layout of Maven: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.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 Thu, Oct 24, 2013 at 10:04 PM, Robert Dailey rcdailey.li...@gmail.comwrote: Hey everyone, I'm trying to understand something basic, I haven't been able to find the answer through Google surprisingly (maybe my searching abilities suck today). How is it that Maven is able to find source code to compile? What I would expect is the pom.xml to refer to some *.java path (something like sourcesrc/main/java/*/source), but I don't see anything like that. How does maven know what java source code to compile? Thanks in advance for any help. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple versions of same local jar
Idea 1: You started of with one version and build your war multiple times while updating the version. Maven does not automatically clean the WEB-INF/lib folder in your target folder. Try a mvn clean install instead of just a mvn install. Idea 2: You have multiple versions of your lib in your dependency tree, but with different groupId's. Maven will think those are different jar files. Check your dependency tree with mvn dependency:tree to see where those dependencies come from. 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 Tue, Oct 15, 2013 at 3:24 PM, berc46 jacques.pou...@gmail.com wrote: Hi, I'm using Maven for a Web project within Eclipse. The project uses some libraries from the Maven repository, and 3 of my libraries, which I've added to my local repository with the mvn deploy:deploy-file command. Whenever I package my .war file in Eclipse, I end up with an archive that contains multiple versions of 2 of my personal libraries, even though my dependencies only mention the latest library for each one. In other words, I have a .war with the following structure : Project.war - ... - WEB-INF - lib - ... - PersonalLib1-1.0.jar - PersonalLib1-1.1.jar - PersonalLib1-1.2.jar - ... - PersonalLib2-1.0.jar - PersonalLib2-1.1.jar - PersonalLib2-1.2.jar - PersonalLib2-1.3.jar - PersonalLib2-1.4.jar - ... Any ideas ? -- View this message in context: http://maven.40175.n5.nabble.com/Multiple-versions-of-same-local-jar-tp5773089.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Automatically remove version overrides from child POMs
Hello Robert, The analyze dependency management goal of the dependency plugin[1] can fail the build if there are any dependency management overrides. You can run that with a CI server on al of your builds and discuss the results with the teams. [1] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt-mojo.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 Sat, May 4, 2013 at 8:39 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Hello Robert, you could use the enforcer-plugin to enforce specific versions, then at least you have an easy way to identify those projects. We exclude all versions of spring and then include the latest version again, e.g. Regards Mirko -- Sent from my mobile On May 4, 2013 12:54 AM, Enyedi, Robert reny...@ebay.com wrote: Hi, We're using a parent POM which manages the versions of tens of dependencies. I occasionally encounter modules within my group that override some of those managed versions. Assuming the overrides are not legit, is there an automatic way to remove them from the child POMs? I was hoping that the versions:update-child-modules mojo would help, but it doesn't seem to do what I need. Thanks, Robert
Re: Maven POM file question
Have you taken a look at the Maven Release Plugin? It seems to do exactly what you want. In short: 1) Update the version in your pom to a stable version 2) Check in updated pom(s). 3) Label/tag the SCM with your current revision 4) Change the version in your pom to the next unstable version 5) Check in Voila, stable label and ready for next release. 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 Tue, Feb 12, 2013 at 8:59 PM, Ron Wheeler rwhee...@artifact-software.com wrote: How are you using SNAPSHOTs and releases? How do they relate to versions in the SCM? Is your problem only around releases? Why do you not have a stable release number? Can you not do tagging in your SCM to identify the SCM version of the release? There seems to be something missing from your explanation. Your audit and traceability requirements seem to be pretty normal and usually maven follows a pretty acceptable set of practices. Maybe you should share a few more of the factors that makes your situation so unusual. Ron On 12/02/2013 12:21 PM, Patrick Haggerty wrote: Just wondering if it can be done. Are locked into using only pom.xml? Let's say I make a label on my application and I build that application based on that label. I still need to modify the POM file to set the version. I do not want to change files that have been labeled. Is my understanding wrong? On Tue, Feb 12, 2013 at 12:15 PM, Wayne Fay wayne...@gmail.com wrote: How can I use a different name like pom.company.xml instead of pom.xml? For all intents and purposes, you cannot. Why do you want to do this? Wayne --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best Practices for Managing Maven with Branches
Or take a look at the Maven Release Plugin - branch goal [1] and it's documentation page [2]. [1] http://maven.apache.org/maven-release/maven-release-plugin/branch-mojo.html [2] http://maven.apache.org/maven-release/maven-release-plugin/examples/branch.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 Mon, Jan 14, 2013 at 6:23 PM, Manfred Moser manf...@mosabuam.com wrote: The mvn versions plugin can do the update of the pom... but the branching and stuff can be done with the scm plugin. If you want it completely automated you have to roll those together on your own somehow. On Mon, January 14, 2013 9:06 am, John Kramer wrote: Are there any automated tools for that or should I write my own see/perl/something? John Kramer email: jkra...@mojiva.com mobile: 314.435.2370 skype: kramer.mojiva twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech 0xCAFEBABE0032 On 1/14/13 11:43 AM, Manfred Moser manf...@mosabuam.com wrote: A very common and well working approach is to have a branch qualifier in the version and change the version of your project with the versions plugin. So e.g. you would have 1.1.2-brancha-SNASPHOT 1.1.2-branchb-SNASPHOT and to update them after you cut the branch in your scm you could use mvn versions:set -=DnewVersion= 1.1.2-brancha-SNAPSHOT manfred On Mon, January 14, 2013 8:39 am, John Kramer wrote: Hi guys, Please forgive me if this seems like a newbie question. I am reasonably seasoned with Maven, but have never really handle branching myself, and now I am put in the position where I am going to have to. I.e. What I am asking here is when I branch in git (or svn or whatever) how do I manage versions in poms (and any other versions I am not thinking about)? Could someone point me at best practices for branches? Thanks! John Kramer email: jkra...@mojiva.commailto:jkra...@mojiva.com mobile: 314.435.2370 skype: kramer.mojiva twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech 0xCAFEBABE0032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: about maven.repo.local property in maven3.0.4
Hi,
Did you try ${settings.localRepository} because the property is a settings
property?
Why your second example works seems evident. You set the property, so you
can read it.
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, Dec 15, 2012 at 4:53 PM, jinwei zhu zhujinwe...@gmail.com wrote:
Dear maven community,
Is maven.repo.local property still a Built-in maven property
? If yes, Why I can not get it's value by using ${maven.repo.local}
in pom.xml, but I can get it's value by using ${maven.repo.local} in
pom.xml after running mvn -Dmaven.repo.local=/root/.m2/repositories
. So this confuse me much.
Best regards!
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Copying license files to my jar in maven-jar-plugin
I think you may be looking at the wrong plugin. If I take a look at the Apache Parent Pom [1] I see an execution of the remote-resources-plugin, which is extracting the LICENSE, etc into the directory the jar plugin is going to process. I think you need to change the configuration of the remote-resources-plugin. [1] http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom 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, Feb 3, 2012 at 4:14 PM, Lahiru Gunathilake glah...@gmail.com wrote: Hi all, I have an issue with one of the Apache Incubator project when it comes to copying license files. In Apache we use apache parent pom as the main parent pom of our project. So when we use it it simply copy LICENSE,NOTICE files of its own to my jars. I have LICENSE,NOTICE files with me for each module I build. I want to override them and make sure my LICENSE,NOTICE files are there in place when jar get created. But I am having a hard time to do that, because I couldn't find proper configuration of maven-jar-plugin.. if someone can point me to all the configuration parameters of maven-jar-plugin that would be great, or please advice me how to solve this kind of an issue. Regards Lahiru -- System Analyst Programmer PTI Lab Indiana University - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What is the right way to install a file to my local repository?
I think it goes wrong on this line: Installing C:\Documents and Settings\E18538\workspace\myco-productplus-web\~\Downloads\selenium-server-standalone-2.0b3.jar It doesn't seem to be able to resolve the '~' on your system. Could you try to give it a relative path or an absolute path which is not dependend on your '~' shortcut? 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 Mon, Feb 6, 2012 at 4:37 PM, laredotornado-3 laredotorn...@gmail.com wrote: Installing C:\Documents and Settings\E18538\workspace\myco-productplus-web\~\Downloads\selenium-server-standalone-2.0b3.jar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Overriding distributionManagement Repositories
You could create a profile in your settings.xml which is always active and sets the property altDeploymentRepository[2] to your new value. [1] http://maven.apache.org/settings.html#Active_Profiles [2] http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jun 23, 2011 at 3:44 PM, Rick Mangi rick.ma...@mtvn.com wrote: Hello Maven Users, I'm trying to migrate my users to a new nexus repository on a different domain. I'm trying to avoid having to tell all of the developers to change their distributionManagement/repository and /snapshotRepository values in their pom files or to upgrade to new parent poms all at once. They can do it over time, but we support hundreds of developers on many projects. I can't seem to find a way to override these values in settings.xml. I can easily change where the users fetch artifacts from, but not where they deploy or release to. (btw - most of my users are still using maven 2). Thanks for any advice you may have. Rick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: addin war as dependency to a war porject
If you want multiple wars I think you are better of deploying an ear file.[1] [1] http://maven.apache.org/plugins/maven-ear-plugin/ Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jun 23, 2011 at 5:05 PM, fachhoch fachh...@gmail.com wrote: I just found yesterday that I can add war as dependency to a war project , I wanted to embed camel web-console inot my app , I found in the forum to just include war dependency in my pom and maven will do all the magic I added the camel web console war a dependency and while building my project maven logs said [INFO] Adding overlay: jar:file:/e:/dev/m2/repository/org/apache/camel/camel-web/2.7.1/camel-web-2.7.1.war!/ I saw the mprject.war it has so many other things from camel-web . I tought just by one line in pom will magically add all the resources from this app to my does it do this ? how can I access a severlet without mapping in my web.xml how does this work anyhow it did not work fro me ie when I tried to acces a reource from camel war it said resouirce not found , please explain me how to embed a war in my war project ? -- View this message in context: http://maven.40175.n5.nabble.com/addin-war-as-dependency-to-a-war-porject-tp4517760p4517760.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: generated artifact name
The name in your target directory is defined by the finalName in your build section[1]. [1] http://maven.apache.org/pom.html#Build_Settings Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jun 23, 2011 at 5:08 PM, Yuvaraj Vanarase yuvaraj.vanar...@synechron.com wrote: Anyone has any clue? Regards, Yuvaraj Yuvaraj Vanarase, Lead Technology - Software Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | http://www.synechron.com SYNECHRON - - Top 10 Best IT Employers for 4 consecutive years (link). - Celebrating 10 Years! -Original Message- From: Yuvaraj Vanarase [mailto:yuvaraj.vanar...@synechron.com] Sent: Thursday, June 23, 2011 3:00 PM To: users@maven.apache.org Subject: generated artifact name Hi, Sometimes I observed that jar/ear artifact created under target directory after maven install/package goal doesn't have version in its name. Well, while installing it does install to correct directory structure under local repository. E.g. artifactIdabc/artifactId groupIdcom.xyz/groupId version1.0.0/version Creates abc.ear instead of abc-1.0.0.ear (or jar if jar is the packaging). Regards, Yuvaraj Yuvaraj Vanarase, Lead Technology - Software Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | http://www.synechron.com SYNECHRON - - Top 10 Best IT Employers for 4 consecutive years (linkhttp://www.synechron.com/news/news_best_employer_sep2010.htm). - Celebrating 10 Years! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: With the maven-release-plugin, how to branch a module and its children ?
I guess you could make an aggregator pom in your trunk/ which kicks of all 3 builds. If you branch this pom it would succeed. Or you could move your parent pom one level higher and let it serve as parent and aggregator pom. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl 2011/6/20 Frédéric Conrotte frederic.conro...@victorbuckservices.com: Hello Say you have a module named parent which has 2 childs childA and ChildB If I run mvn release:branch -DbranchName=my-branch in the parent folder, it will branch the parent module code to SVN /branches/my-branch WITHOUT the 2 child modules. I would like release:branch to branch the parent module and all its children to . /branches/my-branch/parent . /branches/my-branch/childA . /branches/my-branch/childB I didn't found any solution in the doc yet: . http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html . http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html Is it feasible ? Or do I have to run the command for every module I want to branch ? Any help would be appreciated, thanks Fred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3
Your request doesn't make any sense to me. Could you please describe what you want to accomplish? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 1:42 PM, Brosh, Yossi yossi.br...@sap.com wrote: Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3.0.3
Maven will get its plugins and dependencies from the configured repositories. The default repository is central. You'll need an internet connection to let Maven retrieve the plugins from there. If you use a proxy, you need to configure Maven to use that too. This can be done in ~/.m2/settings.xml for your own user or globally on your PC in MAVEN_HOME/conf/settings.xml. I would suggest you start with the documentation and the various books[2], especially [3] [1] http://maven.apache.org/users/index.html [2] http://maven.apache.org/articles.html [3] http://www.sonatype.com/books/maven-book/ Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 2:23 PM, Brosh, Yossi yossi.br...@sap.com wrote: I need to install : maven-deploy-plugin , in order to run maven deploy Best regards, Yossi -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] Sent: Tuesday, May 24, 2011 2:59 PM To: Maven Users List Subject: Re: maven 3.0.3 Your request doesn't make any sense to me. Could you please describe what you want to accomplish? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, May 24, 2011 at 1:42 PM, Brosh, Yossi yossi.br...@sap.com wrote: Hi to all, I am working with maven 3.0.3, windows 7. I need to install plugin's maven, any idea? Thanks, Yos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating Maven Dependencies never ends
Your assumption was correct, but even this is the wrong mailing list. The Maven plugin used in STS or Eclipse is M2Eclipse and they have their own development and mailing list [1]. I know it is hard in the beginning to get the right mailing list. Maven and the default plugins (all in group org.apache.maven.plugins) use this list. The plugins at org.codehaus.mojo use the list at codehaus [2]. All the other projects and plugins have (or haven't) their own communication channels. I don't know which issue you ran into, sorry. [1] https://docs.sonatype.org/display/M2ECLIPSE/Project+Information [2] http://mojo.codehaus.org/mail-lists.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Mar 29, 2011 at 11:47 PM, Dave DaveLists dbfli...@gmail.com wrote: Hello, New to the group here. First, I assumed that the developers list was for those developing Maven as opposed to those developing USING Maven. Perhaps this is wrong. By any chance does anyone know why when I installed the 3.0.5 release of the Spring Framework (with its 3.6 Eclipse developer tools suite) that any time a new project is created (or one of Spring's sample projects is loaded) Maven tries to update its dependencies, but gets stuck in a never-finished state that locks up the Eclipse editor forever? I have to kill it with task manager to close it. Shot in the dark here but hopefully someone has some ideas. I have posted in the Spring forums (along with a few others) but so far no luck. Thanks... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven2 started ignoring my default settings.xml file
Try mvn help:effective-settings to see your settings as maven sees them. Are you sure your server id is the same as your repository/mirror id? With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 24, 2011 at 10:11 PM, Wayne Fay wayne...@gmail.com wrote: When I run mvn deploy it seems to be ignoring the server credentials in the ~/.m2/settings.xml file. I have verified this in the Nexus logs. Nexus receives no credentials, thus tries to upload as user 'anonymous' and fails, returning 401. Any ideas why maven is apparently not defaulting as it should? Note, this is Maven 2.2.1. Try with Maven 3.0.3 and use -X which should tell you more useful information about the configuration files that are being seen/used by Maven during its execution. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Bad mojo. Builds under maven2, fails under maven3.
I don't know whether this is fixed in newer versions of the Antrun plugin, but I noticed you use version 1.3, while version 1.6 is also available. You can give it a try and hopes it fixes your problem. With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 10, 2011 at 12:35 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: antrun - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where to host and publish a new plugin
A lot of the not-core plugins are hosted at Codehaus. They also have the infrastructure, like Subversion, Jira, snapshot repositories and deploying to central. Take a look here[1] to apply for a sandbox project. With regards, [1] http://mojo.codehaus.org/contribution/submitting-a-plugin.html Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 10, 2011 at 4:49 PM, Pulkit Singhal pulkitsing...@gmail.com wrote: Hello Everyone, I'm following the instructions given here to create a new maven plugin: http://maven.apache.org/guides/plugin/guide-java-plugin-development.html I think it would be useful to everyone when its done so I want to find out: 1) Where do you usually host the source for your plugins? svn? github? Which repository is popular and the accepted norm for active useful maven plugins? 2) How do you go on to promoting/publishing it on maven sonatype repo afterwards? Thanks! - Pulkit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ? add dependencies to surefire plugin
Does it need to be on the classpath of surefire or of your unittests? If it is the first you are on the good way. You can check with -X what the classpath for surefire is. For the second, add a normal dependency with scope test. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 10, 2011 at 9:04 PM, Dipl.-Ing. Torsten Liermann l...@liermann-it.de wrote: f-client - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ? add dependencies to surefire plugin
Do you need all those dependencies on the runtime test classpath? The only solution I see is to use the gf-client as test dependency and start excluding all that you don't need. There is no such thing as a scope runtime-test and I don't know if this ever came up. Maybe search through Jira for it. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 10, 2011 at 9:22 PM, Dipl.-Ing. Torsten Liermann l...@liermann-it.de wrote: Thanks Nick. I need the artifact in the runtime classpath for the unit test. If I declare this dependency normal with test scope, then maven (3.0.2) adds this artifact to the test-compiler classpath. Glassfishs gf-client has over hundred dependencies and so the compilation time is 500 % longer. :( On Thu, 10 Mar 2011 21:12:04 +0100 Nick Stolwijk nick.stolw...@gmail.com wrote: Does it need to be on the classpath of surefire or of your unittests? If it is the first you are on the good way. You can check with -X what the classpath for surefire is. For the second, add a normal dependency with scope test. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Mar 10, 2011 at 9:04 PM, Dipl.-Ing. Torsten Liermann l...@liermann-it.de wrote: f-client - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven subversion
First, this message belongs to the user list, so redirecting there. For your question, take a look at SCM for Subversion[1]. [1] http://maven.apache.org/scm/subversion.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Mar 9, 2011 at 11:27 AM, anjana ajalod...@yahoo.com wrote: hii i m working on maven and subversion To Have to set up my maven project so that the scm configuration(in pom.xml file) points to a local repository i have seen an example to do this from the following site: http://www.chrissearle.org/node/296 http://www.chrissearle.org/node/296 [ http://www.chrissearle.org/node/296 ^ ] but in this example i m unable to understand the scm tag and their sub tags how can i implement this... do u have any solution for this problem -- View this message in context: http://maven.40175.n5.nabble.com/maven-subversion-tp3415264p3415264.html Sent from the Maven - Issues mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn package with dependency jar
Take a look at the Advanced Artifact-Matching in includes and excludes on the advanced descriptor page[1]. [1] http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Mar 9, 2011 at 12:58 AM, Mark static.void@gmail.com wrote: How can I use mvn to package my project as well as one (not all) of my dependencies? I've been looking at jar-with-dependencies plugin however that seems to copy every single of my dependencies. I just want to add 1 single jar. Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
I just checked our 1.8.0.1 instance of Nexus and it is right there under the configuration of a hosted repository: Deployment policy: Allow redeploy Disallow redeploy Read only Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 6:58 PM, baz themail bazthem...@gmail.com wrote: Todd, thats one of the function that I thought Nexus has... but I cannot find the usage for it. Is it only available in Pro version? On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
I've also checked 1.3.6 (still in production here, Saturday we are moving to 1.8.0.1) and, indeed, it isn't there. You have to upgrade to a newer version to have it. It isn't a Pro feature, the free version also has it. With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:08 PM, baz themail bazthem...@gmail.com wrote: Nick, I am using Nexus open source version 1.3.6. - Open repository named releases. - Configuration tab. - I see Repositoy ID, Repository Name, Repository type, Provider, Format, Repository Policy, Default Local Storage Location, Override Local Storage Location; Access settings: Allow Deployment, Allow File Browsing, Include in Search; Expiration settings: Not found cache TTL. I do not see Deployment policy. Is this a feature for PRO? Thanks. B. On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: I just checked our 1.8.0.1 instance of Nexus and it is right there under the configuration of a hosted repository: Deployment policy: Allow redeploy Disallow redeploy Read only Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 6:58 PM, baz themail bazthem...@gmail.com wrote: Todd, thats one of the function that I thought Nexus has... but I cannot find the usage for it. Is it only available in Pro version? On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail
Re: Is there any way to stop the same version of pom file/build being built more than once?
We just did a reinstall on a new server and planning to copy the repositories by hand and do a reindex. We had a testrun and it went painlessly. The mirror and snapshot repositories we just deleted, as to do some cleanup. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:24 PM, baz themail bazthem...@gmail.com wrote: How is the upgrade process from 1.3.6 to 1.8.0.1? Painless? On Thu, Jan 6, 2011 at 10:12 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: I've also checked 1.3.6 (still in production here, Saturday we are moving to 1.8.0.1) and, indeed, it isn't there. You have to upgrade to a newer version to have it. It isn't a Pro feature, the free version also has it. With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:08 PM, baz themail bazthem...@gmail.com wrote: Nick, I am using Nexus open source version 1.3.6. - Open repository named releases. - Configuration tab. - I see Repositoy ID, Repository Name, Repository type, Provider, Format, Repository Policy, Default Local Storage Location, Override Local Storage Location; Access settings: Allow Deployment, Allow File Browsing, Include in Search; Expiration settings: Not found cache TTL. I do not see Deployment policy. Is this a feature for PRO? Thanks. B. On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: I just checked our 1.8.0.1 instance of Nexus and it is right there under the configuration of a hosted repository: Deployment policy: Allow redeploy Disallow redeploy Read only Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 6:58 PM, baz themail bazthem...@gmail.com wrote: Todd, thats one of the function that I thought Nexus has... but I cannot find the usage for it. Is it only available in Pro version? On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e
Re: Is there any way to stop the same version of pom file/build being built more than once?
Yes, we had to upgrade Jira, Hudson, Nexus and Sonar, so we just copy the data and replace the (virtual) machine. That way, when the upgrade goes wrong, we can easily go back to the old situation. With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:33 PM, baz themail bazthem...@gmail.com wrote: Ic. so instead of upgrade from same machine, you have a new server then migrate the files and directories over... Thank you for your reply. B. On Thu, Jan 6, 2011 at 10:31 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: We just did a reinstall on a new server and planning to copy the repositories by hand and do a reindex. We had a testrun and it went painlessly. The mirror and snapshot repositories we just deleted, as to do some cleanup. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:24 PM, baz themail bazthem...@gmail.com wrote: How is the upgrade process from 1.3.6 to 1.8.0.1? Painless? On Thu, Jan 6, 2011 at 10:12 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: I've also checked 1.3.6 (still in production here, Saturday we are moving to 1.8.0.1) and, indeed, it isn't there. You have to upgrade to a newer version to have it. It isn't a Pro feature, the free version also has it. With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 7:08 PM, baz themail bazthem...@gmail.com wrote: Nick, I am using Nexus open source version 1.3.6. - Open repository named releases. - Configuration tab. - I see Repositoy ID, Repository Name, Repository type, Provider, Format, Repository Policy, Default Local Storage Location, Override Local Storage Location; Access settings: Allow Deployment, Allow File Browsing, Include in Search; Expiration settings: Not found cache TTL. I do not see Deployment policy. Is this a feature for PRO? Thanks. B. On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk nick.stolw...@gmail.com wrote: I just checked our 1.8.0.1 instance of Nexus and it is right there under the configuration of a hosted repository: Deployment policy: Allow redeploy Disallow redeploy Read only Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Jan 6, 2011 at 6:58 PM, baz themail bazthem...@gmail.com wrote: Todd, thats one of the function that I thought Nexus has... but I cannot find the usage for it. Is it only available in Pro version? On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - To unsubscribe
Re: Is there any way to stop the same version of pom file/build being built more than once?
And use the Maven Release Plugin to create the branch[1][2] in the first place. This will change the version numbers back to snapshot. [1] http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html [2] http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Jan 5, 2011 at 6:58 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven tries to download wrong pmd version
What goals are you running? The site lifecycle doesn't take build/pluginManagement into account and you have to set the version in /project/reporting/plugins/ Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Jan 4, 2011 at 3:11 PM, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, a build of an aggregated project recently broke (actually after first release) with following error message: [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-pmd-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-pmd-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-pmd-plugin:pom:2.6-SNAPSHOT from the specified remote repositories: nexus (http://nexus.anotheria.net/nexus/content/groups/public) for project org.apache.maven.plugins:maven-pmd-plugin the funny thing is that i'm not using pmd 2.6: from the parent: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.5/version /plugin ... any ideas where the 2.6-SNAPSHOT comes from? regards Leon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven tries to download wrong pmd version
Unfortunately not.[1] [1] http://maven.apache.org/pom.html#Reporting With regards, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Jan 4, 2011 at 3:29 PM, Leon Rosenberg rosenberg.l...@gmail.com wrote: Damned, site it was. Thanks for the hint! on a side note, can i setup pluginmanagement for reporting as well? regards Leon On Tue, Jan 4, 2011 at 3:15 PM, Nick Stolwijk nick.stolw...@gmail.com wrote: What goals are you running? The site lifecycle doesn't take build/pluginManagement into account and you have to set the version in /project/reporting/plugins/ Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Jan 4, 2011 at 3:11 PM, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, a build of an aggregated project recently broke (actually after first release) with following error message: [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-pmd-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-pmd-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-pmd-plugin:pom:2.6-SNAPSHOT from the specified remote repositories: nexus (http://nexus.anotheria.net/nexus/content/groups/public) for project org.apache.maven.plugins:maven-pmd-plugin the funny thing is that i'm not using pmd 2.6: from the parent: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.5/version /plugin ... any ideas where the 2.6-SNAPSHOT comes from? regards Leon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to prune contents of the local repo?
rm -rf ~/.m2/repository No kidding, host a proxy like Nexus on your network and use that as a mirrored proxy. This has all kind of clean up tasks, like remove old snapshots, etc. And, because it is a local mirror, it has all the artifacts you need. And even in different repositories, like proxied central, hosted snapshots with cleanup policy, hosted releases with deploy once policy, hosted thirdparty repository. All cleanly seperated and easily backupped. For staging builds you would need Nexus Professional, for all your other wishes the normal Nexus fits like a glove. Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Dec 28, 2010 at 6:47 PM, baz themail bazthem...@gmail.com wrote: Hi, 1. What is the best and recommended way to limit the size of the local maven repo? Currently, I am having a cron job to remove older SNAPSHOT. 2. Is there any way to keep certain release builds but not others? Meaning, is there any type of promotion mechanism in maven to mark some releases in local repo? 3. Is there any way to stop the same version of pom file/build being built more than once? Thanks. B. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
If you still have the same snippet in your pom, you only have the snapshotRepository and not the normal repository element. With regards, Nick Stolwijk ~Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Dec 8, 2010 at 5:44 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote: -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Wednesday, December 08, 2010 8:40 AM To: Maven Users List Subject: Re: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds? If I set up deployment credentials in Nexus (I believe it's already set up), how do I provide them in Maven? Googling for maven nexus deployment credentials gives me this link which is exactly what you are looking for... http://www.sonatype.com/books/nexus-book/reference/ch13s04.html Yeah, I figured out that part a minute after I wrote that. It doesn't solve the problem, however. It still complains about the missing repository element (which is there, as far as I can tell). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
Also, I see you are trying to deploy to a group. I don't think nexus is very happy about that: distributionManagement snapshotRepository idnexus/id urlhttp://myhost:8081/nexus/content/groups/public/url /snapshotRepository /distributionManagement Try something like this: distributionManagement repository idnexus-inhouse/id urlhttp://myhost:8081/nexus/content/inhouse/url /repository snapshotRepository idnexus-inhouse-snapshot/id urlhttp://myhost:8081/nexus/content/inhouse-snapshot/url /snapshotRepository /distributionManagement And create the inhouse and inhouse-snapshot repositories inside nexus and add them to the right groups. With regards, Nick Stolwijk ~Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Dec 8, 2010 at 5:49 PM, Nick Stolwijk nick.stolw...@gmail.com wrote: If you still have the same snippet in your pom, you only have the snapshotRepository and not the normal repository element. With regards, Nick Stolwijk ~Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Dec 8, 2010 at 5:44 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote: -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Wednesday, December 08, 2010 8:40 AM To: Maven Users List Subject: Re: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds? If I set up deployment credentials in Nexus (I believe it's already set up), how do I provide them in Maven? Googling for maven nexus deployment credentials gives me this link which is exactly what you are looking for... http://www.sonatype.com/books/nexus-book/reference/ch13s04.html Yeah, I figured out that part a minute after I wrote that. It doesn't solve the problem, however. It still complains about the missing repository element (which is there, as far as I can tell). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 no longer supporting dynamic configuration of plugins?
I can't answer your question, sorry. Maybe you should post this at the dev list. There resides the most people with intimate knowledge about Maven's plugin setup. With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Sat, Dec 4, 2010 at 11:08 PM, Peter Niederwieser pnied...@gmail.com wrote: No Maven committers reading this list? Even a No would help. Cheers, Peter -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-no-longer-supporting-dynamic-configuration-of-plugins-tp3279670p3292542.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to create the custom project structure!
Although this is highly seen as a bad practice, you may want to start by looking here: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-Isitpossibletocreatemyowndirectorystructure%3F More information about the pom structure: http://maven.apache.org/pom.html Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Tue, Nov 16, 2010 at 8:19 AM, D.R.MC dream.realist...@gmail.com wrote: How to create the custom project structure! e.g. The source directory is src/java/main. + java +main Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dual javadoc
Yes, just bind the javadoc:jar goal twice with different configuration. With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Thu, Nov 11, 2010 at 8:35 PM, Gerard Weatherby gerard.weathe...@gmail.com wrote: Is there a way to configure the javadoc plugin to generate two sets of Javadoc output? We find it convenient to have both the default public and showprivate/show versions. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multi-module agregated test report
I would suggest you use Maven(+Hudson)+Sonar.
Maven for building and gathering information
Hudson for CI (but it can be left out)
Sonar for reporting
Sonar can do nice reports for coverage, unit tests, QA metrics, etc.
Hth,
Nick Stolwijk
~Java Developer~
IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl
On Thu, Nov 4, 2010 at 3:47 PM, emerson echofloripa.y...@gmail.com wrote:
Hi Jesse
I still need to use maven for generating the aggregation.
You are saying that Junit reports should would just fine for that then?
regards
Emerson
On 5 October 2010 13:30, Jesse Farinacci jie...@gmail.com wrote:
Hi Emerson,
On Tue, Oct 5, 2010 at 5:25 AM, emerson echofloripa.y...@gmail.com wrote:
Should I presume there is no equivalent to the aggregated dashboard of M1?
Yes. There is no equivalent for the M1 dashboard. Some report plugins
support aggregation, but that is on a per-plugin basis.
I realize what I'm about to suggest is even more bold than the
statements that an MRM is a necessary component for proper Maven
function in any environment of even minor sophistication (which it
is), but.. You should consider running Hudson with all of the static
code analysis tools, and test reporting, enabled. Hudson handles
proper module {checkstyle, findugs, pmd, test} aggregation on your
behalf, and in a spectacularly useful and easy way.
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
