[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712779#comment-17712779
]
Roy Teeuwen commented on MNG-5659:
--
I'm facing the same issue as a contractor. A logical way I would see this work
is to be able to specify a settings file per folder:
~/workspace/client-one/settings.xml
~/workspace/client-two/settings.xml
I have looked into making a core extension for this, but the issue is that you
can't easily load in core extensions on a global level. You could add them to
the ${maven.home}/lib/ext, but on an update of maven this extension would then
disappear. It would be easier if you could load them also in through for
example ${user.home}/.m2/lib/ext
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7772) Allow to register maven core extension in .m2 folder instead of MAVEN_HOME
Roy Teeuwen created MNG-7772:
Summary: Allow to register maven core extension in .m2 folder
instead of MAVEN_HOME
Key: MNG-7772
URL: https://issues.apache.org/jira/browse/MNG-7772
Project: Maven
Issue Type: Improvement
Reporter: Roy Teeuwen
Currently the way to register a maven core extension is described here:
[https://maven.apache.org/guides/mini/guide-using-extensions.html]
Namely the following ways are supported:
* Registered via extension jar in {{${maven.home}/lib/ext}}
* Registered via CLI argument {{mvn -Dmaven.ext.class.path=extension.jar}}
* Registered via [{{.mvn/extensions.xml}}
file|https://maven.apache.org/configure.html#mvn-extensions-xml-file]
The downside of this is that the ${maven.home} directory is not something that
you should touch, seeing as with every update of maven (through for example
homebrew), it will replace the directory with the new version, making it
required to manually re-register the core extension by dragging the jar in
/lib/ext.
My proposal is to also make it possible to register the extension through the
${user.home}/.m2 folder. This could for example be by also allowing the
extensions.xml in the .m2 folder or by creating an ext folder in the .m2 folder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7772) Allow to register maven core extension in .m2 folder instead of MAVEN_HOME
[
https://issues.apache.org/jira/browse/MNG-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715596#comment-17715596
]
Roy Teeuwen commented on MNG-7772:
--
I'd want to see if I could contribute this, unless there is a good reason to
not allow this?
> Allow to register maven core extension in .m2 folder instead of MAVEN_HOME
> ---
>
> Key: MNG-7772
> URL: https://issues.apache.org/jira/browse/MNG-7772
> Project: Maven
> Issue Type: Improvement
>Reporter: Roy Teeuwen
>Priority: Major
>
> Currently the way to register a maven core extension is described here:
> [https://maven.apache.org/guides/mini/guide-using-extensions.html]
> Namely the following ways are supported:
> * Registered via extension jar in {{${maven.home}/lib/ext}}
> * Registered via CLI argument {{mvn -Dmaven.ext.class.path=extension.jar}}
> * Registered via [{{.mvn/extensions.xml}}
> file|https://maven.apache.org/configure.html#mvn-extensions-xml-file]
> The downside of this is that the ${maven.home} directory is not something
> that you should touch, seeing as with every update of maven (through for
> example homebrew), it will replace the directory with the new version, making
> it required to manually re-register the core extension by dragging the jar in
> /lib/ext.
> My proposal is to also make it possible to register the extension through the
> ${user.home}/.m2 folder. This could for example be by also allowing the
> extensions.xml in the .m2 folder or by creating an ext folder in the .m2
> folder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5897) Make extensions configurable in a more convenient way
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690862#comment-17690862
]
Roy Teeuwen commented on MNG-5897:
--
+1 for this feature request. I also have some parameters i'd like to pass to
the core extensions that I want to use
> Make extensions configurable in a more convenient way
> -
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-5897) Make extensions configurable in a more convenient way
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690862#comment-17690862
]
Roy Teeuwen edited comment on MNG-5897 at 2/19/23 9:42 AM:
---
+1 for this feature request. I also have some parameters i'd like to pass to
the core extensions that I want to use. I'd like to use the
https://github.com/gzm55/project-settings-maven-extension to be able to
configure a settings.xml for a folder, see my feature request more specifically
for an explanation:
https://github.com/gzm55/project-settings-maven-extension/issues/5
was (Author: royteeuwen):
+1 for this feature request. I also have some parameters i'd like to pass to
the core extensions that I want to use
> Make extensions configurable in a more convenient way
> -
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000661#comment-15000661
]
Roy Teeuwen commented on MNG-5199:
--
Any update on this issue? This is for us also an issue in CI environments.
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://issues.apache.org/jira/browse/MNG-5199
> Project: Maven
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5929) Allow mirrors to be set through settings.xml profiles
Roy Teeuwen created MNG-5929: Summary: Allow mirrors to be set through settings.xml profiles Key: MNG-5929 URL: https://issues.apache.org/jira/browse/MNG-5929 Project: Maven Issue Type: Improvement Components: Settings Reporter: Roy Teeuwen Currently I am working for 3 customers with all three their own internal repository. This means that they use the following mirror settings: mirror mirrorUrl * I have now made three profiles for each company, allowing me to use one settings file. I made a bash script where I can set MAVEN_OPTS=-DsettingsProfile=customerName and then use this variable for the activation of the profiles. The only pitfall is that I can't do the same for the mirror, seeing as this is not an allowed element inside the profiles. So it would be very nice if this could be improved to allow the mirror element in the profiles section. (Another solution would be to return the -Dapache.user_settings=settingsfile, but this is sadly dropped from maven 3. Using the -s is not an option seeing as this won't be used in spawned maven processes from the main maven proces.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (SCM-623) Add a configuration mode to be able to use git svn (at least for release plugin)
[ https://jira.codehaus.org/browse/SCM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359336#comment-359336 ] Roy Teeuwen commented on SCM-623: - Can anyone comment on this being possible in one or the other way? Even if it's with a workaround? > Add a configuration mode to be able to use git svn (at least for release > plugin) > > > Key: SCM-623 > URL: https://jira.codehaus.org/browse/SCM-623 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
