> /usr/share/maven/lib/ext That would be perfect! Is that documented somewhere? I never saw mention of that before today!
What is the earliest version of Maven that supports that extension folder? On Thu, Sep 30, 2021 at 1:19 AM Delany <[email protected]> wrote: > Hi Austin, > > I think those Takari projects aren't maintained anymore. The issue was > recently fixed in Maven 3.8.2 with > https://issues.apache.org/jira/browse/MNG-4706 > > You can use the command line -Dmaven.ext.class.path to include the > extension. The strange wording is perhaps because there is an idea in the > Maven community that command line arguments are second-class citizens to > configuration written into the pom files, and conversely that you can throw > whatever arguments in and it will not interfere with existing > configuration. There is some truth to this, as arguments to config a plugin > are honoured, but not if the same config has been configured in a pom. > > You can also add the extensions for the system to /usr/share/maven/lib/ext > > Thanks, > Delany > > > > On Thu, 30 Sept 2021 at 07:45, Austin Witt <[email protected]> wrote: > > > I wish to install a Maven extension - Takari's Concurrent Safe Local > > Repository extension ( > > > http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository > > ) > > - on a system such that it's picked up by all Maven runs. > > > > Individual projects should not have to put it in their pom.xml; I do not > > want projects to be able to opt-out of this extension, and I do not want > > them to have to opt-in. > > Individual projects should not have to put it in their > > basedir/.mvn/extensions.xml; I do not want projects to be able to opt-out > > of this extension, and I do not want them to have to opt-in. > > > > However... > > > > This is a CICD system where builds run in Docker containers, and each get > > their *own* ~/.m2 directory (complete with their own self-specified > > settings.xml), which the builds themselves set up *if they need it* at > > build-time. So, there isn't a ~/.m2/lib/ext that I can drop the extension > > JAR into "ahead-of-time" before Maven runs - to put it there, I'd have to > > modify each project's pipeline to drop the JAR in before kicking off any > > Maven processes. > > > > I am looking for a way to provide the extension as default functionality > > for *all* Maven processes on a system, without requiring an individual > > "maven project in a git repo" to be aware of it. > > > > I am not entirely sure I understand how the final Extension > > mechanism, -Dmaven.ext.class.path, works. It *seems like* I could add > that > > via environment variables as a global maven option, and point at a JAR > > somewhere *else *on the system. However, the documentation I could find > on > > it cautions: > > > > -Dmaven.ext.class.path=[path to files] is a little bit more flexible, but > > remains not configured into the build, which is not suitable to ensure an > > extension is available at build time. > > -- https://maven.apache.org/studies/extension-demo/ > > > > > > What does "not configured into the build, which is not suitable to ensure > > an extension is available at build time" *mean* ? Is it just saying that > > it's not loaded before the project is parsed and so is unsuitable for > > extensions that require that, as identified in the line about pom.xml > > extension configuration? All documentation I can find about > > -Dmaven.ext.class.path talks about EventSpy implementations - does it > > *only* work > > for those? Or can I load other extensions via that mechanism? > > > > If -Dmaven.ext.class.path works with all extension types *and* loads > > in-time for Takari's extension, I can probably use that. > > > > If not, is there a way to change the Maven extension directory with a > > property? E.g. mvn -Dext.dir=/opt/some/dir and have that used, instead of > > the user-local ~/.m2/lib/ext? > > > > Thank you for your time, > > Austin > > >
