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 > >
