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