Re: Can a plugin permit a dependency override by the user setting a simple option?
Hi Jörg. Thanks for the reply. Can you please elaborate with examples? Option 1 is what I need, but that does not work. Or maybe we have a misunderstanding about the term "property". Are we talking about a simple Maven property or a mojo configuration property? Regards -- Alexander Kriegisch https://scrum-master.de Jörg Schaible schrieb am 03.02.2024 17:59 (GMT +07:00): > There are several approaches, depending on the use case: > > 1/ It is always the same dependency, the user just wants to use different > versions. Solution: Use a property for the version. The user can then > overwrite the property in his pom. > > 2/ The user should be able to use a different dependency. The approach with > the > > property works here also, just use it also for the groupId and artifactId. > > 3/ The user must not use a single dependency that varies, but several. Here > you may take an approach with different profiles. Best practice here is to > activate the profiles by existing of a (relative) file e.g. in a local > profile > folder. > > And you may combine these approaches. Check the result with > help:effective-pom > where you can see, what Maven internally generates as pom for an individual > project. > > Regards, > Jörg > > Regards, > Jörg > > > > - > 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: Can a plugin permit a dependency override by the user setting a simple option?
Hi Lasse. Thanks for the reply. I fail to see how this plugin is an example for a solution to the problem explained in my question. Please elaborate. Regards -- Alexander Kriegisch https://scrum-master.de Lasse Lindqvist schrieb am 03.02.2024 21:10 (GMT +07:00): > If you need an example of how this can be done, take a look at > https://github.com/wvengen/proguard-maven-plugin > > It might not be exactly what you want, but should give an idea of how it > could be done. > > la 3. helmik. 2024 klo 13.00 Jörg Schaible > kirjoitti: > >> Hi Alexander, >> >> On Saturday, 3. February 2024, 06:03:27 CET Alexander Kriegisch wrote: >> > Many plugins, e.g. compiler plugins, depend on other libraries, in this >> > case compilers. This is true for plugins such as Plexus Compiler, >> > AspectJ Maven, GMaven+. Usually, what a user needs to do to override the >> > default provided by the plugin (which is almost never exactly the >> > version the user wants), the user does something like: >> > >> > >> > org.acme >> > xy-compiler-plugin >> > 1.2.3 >> > >> > >> > org.xy >> > xy-compiler >> > 4.5 >> > >> > >> > >> > >> > While this is not so much work, I was wondering if there is any way to >> > make it a little bit easier for the user as a plugin developer, so she >> > can do this instead: >> > >> > >> > org.acme >> > xy-compiler-plugin >> > 1.2.3 >> > >> > 4.5 >> > >> > >> > >> > My current knowledge of the Maven Way says, this is not possible. But I >> > am asking anyway, just because I am curious and did not find any helpful >> > resources online. >> >> There are several approaches, depending on the use case: >> >> 1/ It is always the same dependency, the user just wants to use different >> versions. Solution: Use a property for the version. The user can then >> overwrite the property in his pom. >> >> 2/ The user should be able to use a different dependency. The approach >> with the >> property works here also, just use it also for the groupId and artifactId. >> >> 3/ The user must not use a single dependency that varies, but several. >> Here >> you may take an approach with different profiles. Best practice here is to >> activate the profiles by existing of a (relative) file e.g. in a local >> profile >> folder. >> >> And you may combine these approaches. Check the result with >> help:effective-pom >> where you can see, what Maven internally generates as pom for an >> individual >> project. >> >> Regards, >> Jörg >> >> Regards, >> Jörg >> >> >> >> - >> 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 know which plugin/goal is frozen in multithreaded build ?
Howdy, Important questions: - what maven version exactly - what java version are you using? - how exactly is "multi threaded" build invoked Also, you could tweak logging properties to show threads and trigger MT build in debug piped into file, and that file when filtered for thread name would probably give some clue. T On Sat, Feb 3, 2024, 17:48 Francois Marot wrote: > Hello all, > > I have a large build that completes normally in single threaded build but > freezes in multithreaded builds. Problem is I do not know which module and > which plugin is frozen. The last logs that get displayed are the classic > end log for a given module and the logs always stop there. So I believe > another module is still underway, stuck, and prevents the build to go > further. If there were entry/exit logs for each module and each plugin, I > could parse the logs, match each entry/exit, and find the last missing > exit. That would point me to the culprit... > But to my knowledge there are no such entry/exit logs... > > I'will try to use mvnDebug command and plug a debugger but I do not even > know what I'm looking for ! Any idea ? > > Have a good day > François >
Re: How to know which plugin/goal is frozen in multithreaded build ?
I would suggest maybe just attaching a profiler and/or taking a stackdump. It should show you what plugin is currently running and stuck. la 3. helmik. 2024 klo 18.48 Francois Marot (francois.ma...@gmail.com) kirjoitti: > > Hello all, > > I have a large build that completes normally in single threaded build but > freezes in multithreaded builds. Problem is I do not know which module and > which plugin is frozen. The last logs that get displayed are the classic > end log for a given module and the logs always stop there. So I believe > another module is still underway, stuck, and prevents the build to go > further. If there were entry/exit logs for each module and each plugin, I > could parse the logs, match each entry/exit, and find the last missing > exit. That would point me to the culprit... > But to my knowledge there are no such entry/exit logs... > > I'will try to use mvnDebug command and plug a debugger but I do not even > know what I'm looking for ! Any idea ? > > Have a good day > François - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to know which plugin/goal is frozen in multithreaded build ?
Hello all, I have a large build that completes normally in single threaded build but freezes in multithreaded builds. Problem is I do not know which module and which plugin is frozen. The last logs that get displayed are the classic end log for a given module and the logs always stop there. So I believe another module is still underway, stuck, and prevents the build to go further. If there were entry/exit logs for each module and each plugin, I could parse the logs, match each entry/exit, and find the last missing exit. That would point me to the culprit... But to my knowledge there are no such entry/exit logs... I'will try to use mvnDebug command and plug a debugger but I do not even know what I'm looking for ! Any idea ? Have a good day François
Re: Can a plugin permit a dependency override by the user setting a simple option?
If you need an example of how this can be done, take a look at https://github.com/wvengen/proguard-maven-plugin It might not be exactly what you want, but should give an idea of how it could be done. la 3. helmik. 2024 klo 13.00 Jörg Schaible kirjoitti: > Hi Alexander, > > On Saturday, 3. February 2024, 06:03:27 CET Alexander Kriegisch wrote: > > Many plugins, e.g. compiler plugins, depend on other libraries, in this > > case compilers. This is true for plugins such as Plexus Compiler, > > AspectJ Maven, GMaven+. Usually, what a user needs to do to override the > > default provided by the plugin (which is almost never exactly the > > version the user wants), the user does something like: > > > > > > org.acme > > xy-compiler-plugin > > 1.2.3 > > > > > > org.xy > > xy-compiler > > 4.5 > > > > > > > > > > While this is not so much work, I was wondering if there is any way to > > make it a little bit easier for the user as a plugin developer, so she > > can do this instead: > > > > > > org.acme > > xy-compiler-plugin > > 1.2.3 > > > > 4.5 > > > > > > > > My current knowledge of the Maven Way says, this is not possible. But I > > am asking anyway, just because I am curious and did not find any helpful > > resources online. > > There are several approaches, depending on the use case: > > 1/ It is always the same dependency, the user just wants to use different > versions. Solution: Use a property for the version. The user can then > overwrite the property in his pom. > > 2/ The user should be able to use a different dependency. The approach > with the > property works here also, just use it also for the groupId and artifactId. > > 3/ The user must not use a single dependency that varies, but several. > Here > you may take an approach with different profiles. Best practice here is to > activate the profiles by existing of a (relative) file e.g. in a local > profile > folder. > > And you may combine these approaches. Check the result with > help:effective-pom > where you can see, what Maven internally generates as pom for an > individual > project. > > Regards, > Jörg > > Regards, > Jörg > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Can a plugin permit a dependency override by the user setting a simple option?
Hi Alexander, On Saturday, 3. February 2024, 06:03:27 CET Alexander Kriegisch wrote: > Many plugins, e.g. compiler plugins, depend on other libraries, in this > case compilers. This is true for plugins such as Plexus Compiler, > AspectJ Maven, GMaven+. Usually, what a user needs to do to override the > default provided by the plugin (which is almost never exactly the > version the user wants), the user does something like: > > > org.acme > xy-compiler-plugin > 1.2.3 > > > org.xy > xy-compiler > 4.5 > > > > > While this is not so much work, I was wondering if there is any way to > make it a little bit easier for the user as a plugin developer, so she > can do this instead: > > > org.acme > xy-compiler-plugin > 1.2.3 > > 4.5 > > > > My current knowledge of the Maven Way says, this is not possible. But I > am asking anyway, just because I am curious and did not find any helpful > resources online. There are several approaches, depending on the use case: 1/ It is always the same dependency, the user just wants to use different versions. Solution: Use a property for the version. The user can then overwrite the property in his pom. 2/ The user should be able to use a different dependency. The approach with the property works here also, just use it also for the groupId and artifactId. 3/ The user must not use a single dependency that varies, but several. Here you may take an approach with different profiles. Best practice here is to activate the profiles by existing of a (relative) file e.g. in a local profile folder. And you may combine these approaches. Check the result with help:effective-pom where you can see, what Maven internally generates as pom for an individual project. Regards, Jörg Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Community over Code EU 2024 Travel Assistance Applications now open!
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code EU 2024 are now open! We will be supporting Community over Code EU, Bratislava, Slovakia, June 3th - 5th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, March 1st, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Bratislava, Slovakia in June, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
