You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Austin Witt <wi...@gmail.com> on 2021/09/29 19:18:39 UTC
Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
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
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
An easy fix is to run maven with one local Repo cache per executor thread. Jenkins has a option for that. Alternatively run the whole build in a container with Repo overlay. (I wish Jenkins had more support to prepopulate those)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Austin Witt <wi...@gmail.com>
Gesendet: Monday, October 4, 2021 5:27:28 PM
An: Maven Users List <us...@maven.apache.org>
Betreff: Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?
Regardless, is there a solution you would recommend for solving the "many
concurrent instances of Maven are running against the same local
repository, and sometimes their file writes conflict" problem?
On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov <mi...@apache.org> wrote:
> Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > 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.
> >
>
> Don't! It is broken! Throw it away!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Tamás Cservenák <ta...@cservenak.net>.
There is an ongoing thread on users ML about same issue here:
https://lists.apache.org/thread.html/rd30b06bbe69de2466fd49bc665b96f02dfb8c34431cedff678fe1a08%40%3Cusers.maven.apache.org%3E
HTH
T
On Mon, Oct 4, 2021 at 5:28 PM Austin Witt <wi...@gmail.com> wrote:
> Is it broken in that it doesn't actually solve the problem? Or broken in
> that it doesn't actually install correctly in Maven?
>
> Regardless, is there a solution you would recommend for solving the "many
> concurrent instances of Maven are running against the same local
> repository, and sometimes their file writes conflict" problem?
>
> On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov <mi...@apache.org>
> wrote:
>
> > Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > > 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.
> > >
> >
> > Don't! It is broken! Throw it away!
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-10-04 um 17:27 schrieb Austin Witt:
> Is it broken in that it doesn't actually solve the problem? Or broken in
> that it doesn't actually install correctly in Maven?
It does not solve the problem. It fails miserably. Don't use it.
See here also: https://github.com/takari/takari-local-repository/issues/15
See my answer to the other, related thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Austin Witt <wi...@gmail.com>.
Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?
Regardless, is there a solution you would recommend for solving the "many
concurrent instances of Maven are running against the same local
repository, and sometimes their file writes conflict" problem?
On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov <mi...@apache.org> wrote:
> Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > 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.
> >
>
> Don't! It is broken! Throw it away!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-09-29 um 21:18 schrieb Austin Witt:
> 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.
>
Don't! It is broken! Throw it away!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Delany <de...@gmail.com>.
It's here
https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
Delany
On Thu, 30 Sep 2021, 16:56 Austin Witt, <wi...@gmail.com> wrote:
> > /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 <de...@gmail.com> 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 <wi...@gmail.com>
> 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
> > >
> >
>
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Austin Witt <wi...@gmail.com>.
> /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 <de...@gmail.com> 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 <wi...@gmail.com> 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
> >
>
Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext
Posted by Delany <de...@gmail.com>.
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 <wi...@gmail.com> 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
>