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 <joerg.schai...@gmx.de.invalid> > 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: >> > >> > <plugin> >> > <groupId>org.acme</groupId> >> > <artifactId>xy-compiler-plugin</artifactId> >> > <version>1.2.3</version> >> > <dependencies> >> > <dependency> >> > <groupId>org.xy</groupId> >> > <artifactId>xy-compiler</artifactId> >> > <version>4.5</version> >> > </dependency> >> > </dependencies> >> > </plugin> >> > >> > 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: >> > >> > <plugin> >> > <groupId>org.acme</groupId> >> > <artifactId>xy-compiler-plugin</artifactId> >> > <version>1.2.3</version> >> > <configuration> >> > <compilerVersion>4.5</compilerVersion> >> > </configuration> >> > </plugin> >> > >> > 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
