[jira] [Commented] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[
https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850185#comment-17850185
]
Nils Breunese commented on MWRAPPER-110:
Ok, so the intention is for {{MAVEN_ARGS}} (documented in the Maven
configuration docs) to work with all Maven Wrapper distribution types then? If
so, why was the pull request in this ticket closed?
> The Maven 3.9 `MAVEN_ARGS` env var is not supported
> ---
>
> Key: MWRAPPER-110
> URL: https://issues.apache.org/jira/browse/MWRAPPER-110
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by
> `mvn`, but not by `mvnw`.
> Please port this patch: [https://github.com/apache/maven/pull/49]
> A workaround is to export an extra env variable `MAVEN_CONFIG` which is
> picked by `mvnw`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[
https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850125#comment-17850125
]
Nils Breunese edited comment on MWRAPPER-110 at 5/28/24 6:10 PM:
-
I just found that {{MAVEN_CONFIG}} still gets read when using Maven Wrapper
3.3.0+ with the {{bin}} type, but {{MAVEN_CONFIG}} doesn't get read when using
the new default {{only-script}} type.
And when you use {{only-script}}, you can use {{MAVEN_ARGS}}. But that doesn't
work with the {{bin}} type.
Is it intentional that what environment variable you can use depends on the
Maven Wrapper distribution type? Because I think the current situation is
pretty confusing.
was (Author: breun):
I just found that {{MAVEN_CONFIG}} still gets read when using Maven Wrapper
3.3.0+ with the {{bin}} type, but {{MAVEN_CONFIG}} doesn't get read when using
the new default {{only-script}} type.
And when you use {{only-script}}, you should use {{MAVEN_ARGS}}? Which doesn't
work with the {{bin}} type? This is all pretty confusing.
> The Maven 3.9 `MAVEN_ARGS` env var is not supported
> ---
>
> Key: MWRAPPER-110
> URL: https://issues.apache.org/jira/browse/MWRAPPER-110
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by
> `mvn`, but not by `mvnw`.
> Please port this patch: [https://github.com/apache/maven/pull/49]
> A workaround is to export an extra env variable `MAVEN_CONFIG` which is
> picked by `mvnw`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[
https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850125#comment-17850125
]
Nils Breunese edited comment on MWRAPPER-110 at 5/28/24 6:01 PM:
-
I just found that {{MAVEN_CONFIG}} still gets read when using Maven Wrapper
3.3.0+ with the {{bin}} type, but {{MAVEN_CONFIG}} doesn't get read when using
the new default {{only-script}} type.
And when you use {{only-script}}, you should use {{MAVEN_ARGS}}? Which doesn't
work with the {{bin}} type? This is all pretty confusing.
was (Author: breun):
I just found that {{MAVEN_CONFIG}} still gets read when using Maven Wrapper
3.3.0+ with the {{bin}} type, but {{MAVEN_CONFIG}} doesn't get read when using
the new default {{only-script}} type.
This is all very confusing...
> The Maven 3.9 `MAVEN_ARGS` env var is not supported
> ---
>
> Key: MWRAPPER-110
> URL: https://issues.apache.org/jira/browse/MWRAPPER-110
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by
> `mvn`, but not by `mvnw`.
> Please port this patch: [https://github.com/apache/maven/pull/49]
> A workaround is to export an extra env variable `MAVEN_CONFIG` which is
> picked by `mvnw`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[
https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850125#comment-17850125
]
Nils Breunese commented on MWRAPPER-110:
I just found that {{MAVEN_CONFIG}} still gets read when using Maven Wrapper
3.3.0+ with the {{bin}} type, but {{MAVEN_CONFIG}} doesn't get read when using
the new default {{only-script}} type.
This is all very confusing...
> The Maven 3.9 `MAVEN_ARGS` env var is not supported
> ---
>
> Key: MWRAPPER-110
> URL: https://issues.apache.org/jira/browse/MWRAPPER-110
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by
> `mvn`, but not by `mvnw`.
> Please port this patch: [https://github.com/apache/maven/pull/49]
> A workaround is to export an extra env variable `MAVEN_CONFIG` which is
> picked by `mvnw`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[
https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850078#comment-17850078
]
Nils Breunese commented on MWRAPPER-110:
We use Maven Wrapper type {{bin}}, because our JDK build image doesn't contain
{{curl}} or {{wget}}, so moving to {{only-script}} is not immediately an option
for us. We migrated from {{MAVEN_CONFIG}} to {{MAVEN_ARGS}} because
{{MAVEN_CONFIG}} is no longer read since Maven Wrapper 3.3.0 (MWRAPPER-133),
but now it turns out that {{MAVEN_ARGS}} also doesn't work when calling Maven
via {{./mvnw}}. We really need an environment variable to pass Maven CLI
arguments, so support for {{MAVEN_ARGS}} would be really appreciated, or are
there any other options for us?
> The Maven 3.9 `MAVEN_ARGS` env var is not supported
> ---
>
> Key: MWRAPPER-110
> URL: https://issues.apache.org/jira/browse/MWRAPPER-110
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by
> `mvn`, but not by `mvnw`.
> Please port this patch: [https://github.com/apache/maven/pull/49]
> A workaround is to export an extra env variable `MAVEN_CONFIG` which is
> picked by `mvnw`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-141) Use distribution type of existing Maven Wrapper by default
Nils Breunese created MWRAPPER-141:
--
Summary: Use distribution type of existing Maven Wrapper by default
Key: MWRAPPER-141
URL: https://issues.apache.org/jira/browse/MWRAPPER-141
Project: Maven Wrapper
Issue Type: Improvement
Components: Maven Wrapper Plugin
Reporter: Nils Breunese
It would be great if the {{wrapper:wrapper}} goal would use the type of an
existing Maven Wrapper as the default, because this would allow making changes
to the Maven version or other configuration, without having to specify the type
of the existing Maven Wrapper again. This would be especially handy when
changing (updating) the Maven version, or the Maven Wrapper version.
This would also avoid accidentally changing the distribution type when a user
forgets to specify the type of the existing Maven Wrapper.
It should still be possible call {{wrapper:wrapper -Dtype=$type}} to explicitly
set a different type for an existing project.
When there is no existing Maven Wrapper, or when it exists but doesn't have
{{distributionType}} set in {{{}maven-wrapper.properties{}}}, then the default
{{only-script}} type should still be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:53 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (for instance when updating Maven
Wrapper), would it make sense to use this type by default when {{type}} is not
explicitly set via {{{}-Dtype={}}}? If so, I guess this can also be implemented
via a separate ticket.
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}? If so, I guess this can also be implemented via a separate
ticket.
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:23 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}? If so, I guess this can also be implemented via a separate
ticket.
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese edited comment on MWRAPPER-135 at 5/17/24 4:21 PM:
-
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{maven-wrapper.properties}} (to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
was (Author: breun):
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{{}maven-wrapper.properties{}}}(to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847367#comment-17847367
]
Nils Breunese commented on MWRAPPER-135:
Also, if {{wrapper:wrapper}} is run on a project that already contains this
property in {{{}maven-wrapper.properties{}}}(to update Maven Wrapper), would it
make sense to use this type by default when {{type}} is not explicitly set via
{{{}-Dtype={}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[
https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847365#comment-17847365
]
Nils Breunese commented on MWRAPPER-135:
[~cstamas] I've created a pull request for this feature. Currently the property
name is {{{}distributionType{}}}, because that is also what it is called in the
{{WrapperMojo}} class internally. Do you think that is the best name, or should
it maybe be {{{}wrapperType{}}}?
> Provide a reliable way to determine the Maven Wrapper type
> --
>
> Key: MWRAPPER-135
> URL: https://issues.apache.org/jira/browse/MWRAPPER-135
> Project: Maven Wrapper
> Issue Type: Task
> Components: Maven Wrapper Plugin
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.2
>
>
> Just like MWRAPPER-134 but for type. I completely forgot about this. As this
> way, tooling can figure out not only version but type (also for humans, just
> peek at properties).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843693#comment-17843693
]
Nils Breunese commented on MWRAPPER-134:
[~dalbani] See here:
[https://github.com/renovatebot/renovate/discussions/28648]. A colleague of
mine is willing to work on this, but hasn't found the time for it yet.
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the {{mvnw}} / \{{mvnw.cmd}} scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated MWRAPPER-134:
---
Description:
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the {{mvnw}} / \{{mvnw.cmd}} scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
was:
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the `mvnw` / `./mvnw.bat` scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the {{mvnw}} / \{{mvnw.cmd}} scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
Nils Breunese created MWRAPPER-134:
--
Summary: Provide a reliable way to determine the Maven Wrapper
version
Key: MWRAPPER-134
URL: https://issues.apache.org/jira/browse/MWRAPPER-134
Project: Maven Wrapper
Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Nils Breunese
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the `mvnw` / `./mvnw.bat` scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17717234#comment-17717234
]
Nils Breunese commented on MNG-5659:
[~delany] I would prefer for all projects, both internal and third party, to
build locally without any modifications or extra command line options. We
currently have this with our per-project settings setup, except that Maven can
only be run from the root of our projects, because it is not possible to
specify the location of a file relative to the project base dir in
{{{}.mvn/maven.config{}}}. If that would be possible, or Maven would have some
other mechanism for per-project settings (automatically reading
{{.mvn/settings.xml}} from the project base dir?), that would be great, because
all projects could be self-contained.
> 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] [Commented] (MNG-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714262#comment-17714262 ] Nils Breunese commented on MNG-5659: [~delany] We have a single aggregate repository that proxies all repositories that are approved for use, but for a proof of concept project, fixing a bug in an open source project or some other ad hoc use cases this is not always be sufficient and people may need direct access to extra (sometimes snapshot) repositories from their local machines. > 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] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711136#comment-17711136
]
Nils Breunese commented on MNG-5659:
[~delany] Projects that build using our private artifact repository already
have {{}} and {{}} entries for it in their
root {{{}pom.xml{}}}, but I recall we had to add it as a mirror in settings as
well for some reason to make it work in every situation. If that technically
shouldn't be necessary, I guess we should investigate again if we can just do
without those per-project settings files (or report an issue about that if we
still need it in some cases)?
> 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] [Commented] (MNG-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710859#comment-17710859 ] Nils Breunese commented on MNG-5659: The username from my example was a project-specific username, not a developer-specific one, and the credentials were indeed injected via environment variables, but let's ignore that example for now. There may be a better solution to our needs that I am not aware of which doesn't require per-project settings, which I'd love to learn about. Our main need is having each project use the appropriate artifact repository (or sometimes repositories). We have a central private artifact repository, which stores our build artifacts and proxies Maven Central and other approved Maven repositories. This is currently the only artifact repository that our build pipelines can access, but developers will sometimes want to build a project locally that requires other artifact repositories, e.g. a third-party GitHub project or an experimental Proof of Concept project which requires dependencies from a repository that hasn't been added to our in-company artifact repository yet. A global settings file that defaults to our private artifact repository would interfere with such local builds. You mentioned "(...) for alternative repositories use either a setting profile or a project profile". What do you mean by this exactly and can you explain how these be used to accomplish what I described above? > 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] [Updated] (MBUILDCACHE-51) Broken link to maven-build-cache-config.xml template on Getting Started page
[
https://issues.apache.org/jira/browse/MBUILDCACHE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated MBUILDCACHE-51:
-
Affects Version/s: 1.0.0
> Broken link to maven-build-cache-config.xml template on Getting Started page
>
>
> Key: MBUILDCACHE-51
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-51
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Nils Breunese
>Priority: Minor
>
> [https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html#adding-build-cache-config]
> references a template {{maven-build-cache-config.xml}} file, but
> [https://maven.apache.org/extensions/resources/maven-build-cache-config.xml]
> results in a Page Not Found error.
> What is the actual location of this file and can the link be fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-52) Use current latest release in Getting Started snippet
[ https://issues.apache.org/jira/browse/MBUILDCACHE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Breunese updated MBUILDCACHE-52: - Affects Version/s: 1.0.0 > Use current latest release in Getting Started snippet > - > > Key: MBUILDCACHE-52 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-52 > Project: Maven Build Cache Extension > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Nils Breunese >Priority: Minor > > [https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html#declaring-build-cache-extension] > shows an XML snippet for version 1.0.0-SNAPSHOT, while 1.0.0 is currently > the latest release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-53) Default local cache location is different from documented location
Nils Breunese created MBUILDCACHE-53:
Summary: Default local cache location is different from documented
location
Key: MBUILDCACHE-53
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-53
Project: Maven Build Cache Extension
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Nils Breunese
[https://maven.apache.org/extensions/maven-build-cache-extension/build-cache-config.html#local]
says:
{quote}The base directory where the local cache is located. Defaults to \{@code
$\{localRepository}/../cache}.
{quote}
However, the actual location seems to be {{${localRepository}/../build-cache}}
({{{}~/.m2/build-cache{}}} on my machine).
There is also a superfluous {{\}} after the {{$}} in the documentation of the
default location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-51) Broken link to maven-build-cache-config.xml template on Getting Started page
[
https://issues.apache.org/jira/browse/MBUILDCACHE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710804#comment-17710804
]
Nils Breunese commented on MBUILDCACHE-51:
--
In the navigation I found a link to
[https://maven.apache.org/extensions/maven-build-cache-extension/build-cache-config.html]
which does work.
> Broken link to maven-build-cache-config.xml template on Getting Started page
>
>
> Key: MBUILDCACHE-51
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-51
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Nils Breunese
>Priority: Minor
>
> [https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html#adding-build-cache-config]
> references a template {{maven-build-cache-config.xml}} file, but
> [https://maven.apache.org/extensions/resources/maven-build-cache-config.xml]
> results in a Page Not Found error.
> What is the actual location of this file and can the link be fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-52) Use current latest release in Getting Started snippet
Nils Breunese created MBUILDCACHE-52: Summary: Use current latest release in Getting Started snippet Key: MBUILDCACHE-52 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-52 Project: Maven Build Cache Extension Issue Type: Improvement Reporter: Nils Breunese [https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html#declaring-build-cache-extension] shows an XML snippet for version 1.0.0-SNAPSHOT, while 1.0.0 is currently the latest release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-51) Broken link to maven-build-cache-config.xml template on Getting Started page
Nils Breunese created MBUILDCACHE-51:
Summary: Broken link to maven-build-cache-config.xml template on
Getting Started page
Key: MBUILDCACHE-51
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-51
Project: Maven Build Cache Extension
Issue Type: Bug
Reporter: Nils Breunese
[https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html#adding-build-cache-config]
references a template {{maven-build-cache-config.xml}} file, but
[https://maven.apache.org/extensions/resources/maven-build-cache-config.xml]
results in a Page Not Found error.
What is the actual location of this file and can the link be fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17710790#comment-17710790
]
Nils Breunese commented on MNG-5659:
I have previously worked in an environment where everyone was supposed to
maintain a global {{~/.m2/settings.xml}}, but there were always issues with
people not having the file, not having the right contents in the file, or the
global settings interfering with the build of some third-party project. We like
to keep the Maven settings for each project contained in the project repo, so
any project will always build right after cloning it, without depending on a
global {{~/.m2/settings.xml}} file.
Our in-company project generator generates a {{.mvn/settings.xml}} file with
the correct default settings for in-company projects and a
{{.mvn/maven.config}} file which includes {{--settings=.mvn/settings.xml}} and
this has been working great for us. This lets people add more project-specific
settings when they need to, for instance for deployment settings like a
username if the project is a library. And nobody needs to have or maintain a
global {{~/.m2/settings.xml}} themselves at all.
The only downside of this setup is what I mentioned before: it won't let you
run Maven from another directory than the root directory of the project,
because of the relative path in {{--settings=.mvn/settings.xml}}. If we could
somehow reference a file in the project relative to the project base directory
that would no longer be an issue.
> 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] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710790#comment-17710790
]
Nils Breunese edited comment on MNG-5659 at 4/11/23 7:48 AM:
-
I have previously worked in an environment where everyone was supposed to
maintain a global {{\~/.m2/settings.xml}}, but there were always issues with
people not having the file, not having the right contents in the file, or the
global settings interfering with the build of some third-party project. We like
to keep the Maven settings for each project contained in the project repo, so
any project will always build right after cloning it, without depending on a
global {{~/.m2/settings.xml}} file.
Our in-company project generator generates a {{.mvn/settings.xml}} file with
the correct default settings for in-company projects and a
{{.mvn/maven.config}} file which includes {{--settings=.mvn/settings.xml}} and
this has been working great for us. This lets people add more project-specific
settings when they need to, for instance for deployment settings like a
username if the project is a library. And nobody needs to have or maintain a
global {{~/.m2/settings.xml}} themselves at all.
The only downside of this setup is what I mentioned before: it won't let you
run Maven from another directory than the root directory of the project,
because of the relative path in {{--settings=.mvn/settings.xml}}. If we could
somehow reference a file in the project relative to the project base directory
that would no longer be an issue.
was (Author: breun):
I have previously worked in an environment where everyone was supposed to
maintain a global {{~/.m2/settings.xml}}, but there were always issues with
people not having the file, not having the right contents in the file, or the
global settings interfering with the build of some third-party project. We like
to keep the Maven settings for each project contained in the project repo, so
any project will always build right after cloning it, without depending on a
global {{~/.m2/settings.xml}} file.
Our in-company project generator generates a {{.mvn/settings.xml}} file with
the correct default settings for in-company projects and a
{{.mvn/maven.config}} file which includes {{--settings=.mvn/settings.xml}} and
this has been working great for us. This lets people add more project-specific
settings when they need to, for instance for deployment settings like a
username if the project is a library. And nobody needs to have or maintain a
global {{~/.m2/settings.xml}} themselves at all.
The only downside of this setup is what I mentioned before: it won't let you
run Maven from another directory than the root directory of the project,
because of the relative path in {{--settings=.mvn/settings.xml}}. If we could
somehow reference a file in the project relative to the project base directory
that would no longer be an issue.
> 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] [Commented] (MNG-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710290#comment-17710290 ] Nils Breunese commented on MNG-5659: We indeed use settings to set mirror configuration, so I don't think this would help us. > 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] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699135#comment-17699135
]
Nils Breunese edited comment on MNG-5659 at 3/10/23 11:00 PM:
--
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have 1000+ Maven projects
with project-specific {{settings.xml}} files, because it is just super-valuable
for projects to be buildable right after cloning them, requiring no more than a
JDK installed on the host system. Maven Wrapper pulls in the configured Maven
version and {{.mvn/maven.config}} contains {{--settings=.mvn/settings.xml}} for
any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. A workaround is to 'override' {{\--settings}}
whenever you do this, but colleagues keep running into this problem.
If Maven would always look for {{settings.xml}} in a specific project-specific
location, then we would be able to drop the {{\--settings}} entry from all
{{.mvn/maven.config}} files and just run Maven from anywhere in a project.
was (Author: breun):
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have 1000+ Maven projects
with project-specific {{settings.xml}} files, because it is just super-valuable
for projects to be buildable right after cloning them, requiring no more than a
JDK installed on the host system. Maven Wrapper pulls in the configured Maven
version and {{.mvn/maven.config}} contains {{--settings=.mvn/settings.xml}} for
any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{\--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
> 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] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699135#comment-17699135
]
Nils Breunese edited comment on MNG-5659 at 3/10/23 10:59 PM:
--
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have 1000+ Maven projects
with project-specific {{settings.xml}} files, because it is just super-valuable
for projects to be buildable right after cloning them, requiring no more than a
JDK installed on the host system. Maven Wrapper pulls in the configured Maven
version and {{.mvn/maven.config}} contains {{--settings=.mvn/settings.xml}} for
any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{\--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
was (Author: breun):
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{\--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
> 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] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699135#comment-17699135
]
Nils Breunese edited comment on MNG-5659 at 3/10/23 10:59 PM:
--
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{\--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
was (Author: breun):
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
> 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] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699135#comment-17699135
]
Nils Breunese edited comment on MNG-5659 at 3/10/23 10:58 PM:
--
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for any project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{\--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
was (Author: breun):
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for the project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
> 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] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699135#comment-17699135
]
Nils Breunese commented on MNG-5659:
I'm not sure I'd be considered as someone mastering Maven (although they do
call me Dr. Pom at work :)), but at my company we have over 1000+ Maven
projects with project-specific {{settings.xml}} files, because it is just
super-valuable for projects to be buildable right after cloning them, requiring
no more than a JDK installed on the host system. Maven Wrapper pulls in the
configured Maven version and {{.mvn/maven.config}} contains
{{--settings=.mvn/settings.xml}} for the project-specific settings.
This setup works fine as long as you always call {{./mvnw}} from the root of a
project, but breaks down when you want to run Maven from a
subdirectory/submodule, because suddenly {{--settings=.mvn/settings.xml}}
points to the wrong location. If Maven would always look for {{settings.xml}}
in a specific project-specific location, then we would be able to drop the
{{--settings}} entry from all {{.mvn/maven.config}} files and just run Maven
from anywhere in a project.
> 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] [Updated] (MPLUGINTESTING-81) Link to Git repository is broken
[
https://issues.apache.org/jira/browse/MPLUGINTESTING-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated MPLUGINTESTING-81:
Description:
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html
says:
{quote}
The following is a link to the online source repository.
https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/
{quote}
However, that link results in a 404.
It looks like the URL for the GitHub repository is
https://github.com/apache/maven-plugin-testing
Alternative a deeplink to the[maven-plugin-testing-harness subfolder on the
master
branch|https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness]
could be provided, but that is strictly not a 'repository'.
was:
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html
says:
{quote}
The following is a link to the online source repository.
https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/
{quote}
However, that link results in a 404.
It looks like the URL for the GitHub repository is
https://github.com/apache/maven-plugin-testing
Alternative a deeplink to the[ {{maven-plugin-testing-harness}} subfolder on
the {{master}}
branch|https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness]
could be provided, but that is strictly not a 'repository'.
> Link to Git repository is broken
>
>
> Key: MPLUGINTESTING-81
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-81
> Project: Maven Plugin Testing
> Issue Type: Bug
> Components: plugin-testing-harness
>Reporter: Nils Breunese
>Priority: Minor
>
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html
> says:
> {quote}
> The following is a link to the online source repository.
> https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/
> {quote}
> However, that link results in a 404.
> It looks like the URL for the GitHub repository is
> https://github.com/apache/maven-plugin-testing
> Alternative a deeplink to the[maven-plugin-testing-harness subfolder on the
> master
> branch|https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness]
> could be provided, but that is strictly not a 'repository'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGINTESTING-81) Link to Git repository is broken
Nils Breunese created MPLUGINTESTING-81:
---
Summary: Link to Git repository is broken
Key: MPLUGINTESTING-81
URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-81
Project: Maven Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Reporter: Nils Breunese
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html
says:
{quote}
The following is a link to the online source repository.
https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/
{quote}
However, that link results in a 404.
It looks like the URL for the GitHub repository is
https://github.com/apache/maven-plugin-testing
Alternative a deeplink to the[ {{maven-plugin-testing-harness}} subfolder on
the {{master}}
branch|https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness]
could be provided, but that is strictly not a 'repository'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649101#comment-17649101
]
Nils Breunese commented on MNG-7425:
[~michael-o] I'm afraid I can't use that at work, since we use Maven Wrapper
for all of our builds, this custom Maven build won't be available from our
artifact repository and our CI servers won't let allow access to just any URL
on the internet. I also can't really reproduce this issue at will and this
issue occurs only a couple of times per year for me personally, so it will be
hard for me to verify if Resolver 1.8 fixes this issue in a reasonable
timeframe anyway.
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498882#comment-17498882
]
Nils Breunese commented on MNG-7425:
Ah, great news!
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated MNG-7425:
---
Description:
I’ve been encountering Maven warnings like these for years from time to time:
{code}
WARN: zip file is empty:
/Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
java.util.zip.ZipException: zip file is empty
{code}
This issue causes builds to fail. While I am sure that Maven 3.8.4 is affected,
this is certainly not the oldest version that is affected.
According to [the thread I started about this on the Maven users mailinglist
this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
occurs on at least macOS, Linux and Windows.
I know that when I encounter this I can just delete the file and run Maven
again and then it’ll generally download ok, but this a manual workaround for an
issue that shouldn't exist in the first place.
* Could Maven be modified to ensure that 0 bytes artifacts don't end up in the
local repository?
* Would it make sense for Maven to assume that an empty JAR file was not
downloaded correctly and the download should be retried automatically?
was:
I’ve been encountering Maven warnings like these for years from time to time:
{code}
WARN: zip file is empty:
/Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
java.util.zip.ZipException: zip file is empty
{code}
So while I am sure that Maven 3.8.4 is affected, this is certainly not the
oldest version that is affected.
According to [the thread I started about this on the Maven users mailinglist
this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
occurs on at least macOS, Linux and Windows.
I know that when I encounter this I can just delete the file and run Maven
again and then it’ll generally download ok, but this a manual workaround for an
issue that shouldn't exist in the first place.
* Could Maven be modified to ensure that 0 bytes artifacts don't end up in the
local repository?
* Would it make sense for Maven to assume that an empty JAR file was not
downloaded correctly and the download should be retried automatically?
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
Nils Breunese created MNG-7425:
--
Summary: Maven artifact downloads sometimes result in empty zip
files in local repository
Key: MNG-7425
URL: https://issues.apache.org/jira/browse/MNG-7425
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.8.4
Reporter: Nils Breunese
I’ve been encountering Maven warnings like these for years from time to time:
{code}
WARN: zip file is empty:
/Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
java.util.zip.ZipException: zip file is empty
{code}
So while I am sure that Maven 3.8.4 is affected, this is certainly not the
oldest version that is affected.
According to [the thread I started about this on the Maven users mailinglist
this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
occurs on at least macOS, Linux and Windows.
I know that when I encounter this I can just delete the file and run Maven
again and then it’ll generally download ok, but this a manual workaround for an
issue that shouldn't exist in the first place.
* Could Maven be modified to ensure that 0 bytes artifacts don't end up in the
local repository?
* Would it make sense for Maven to assume that an empty JAR file was not
downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7219) plexus-cipher missing from transitive dependencies of maven-core 3.8.2
Nils Breunese created MNG-7219:
--
Summary: plexus-cipher missing from transitive dependencies of
maven-core 3.8.2
Key: MNG-7219
URL: https://issues.apache.org/jira/browse/MNG-7219
Project: Maven
Issue Type: Bug
Affects Versions: 3.8.2
Reporter: Nils Breunese
I have a project that uses
{{org.apache.maven.plugin-testing:maven-plugin-testing-harness:3.3.0}} for
testing a Maven plugin.
After upgrading the project’s Maven dependencies from Maven 3.8.1 to 3.8.2 I
got this error message when running tests:
{code}
Error injecting:
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
java.lang.NoClassDefFoundError:
org/sonatype/plexus/components/cipher/PlexusCipher ... 117 more
{code}
{{PlexusCipher}} is a class in the {{plexus-cipher}} artifact, which is a
transitive dependency of {{maven-core}} 3.8.1:
{code}
[INFO] org.example:plexus-cipher-mystery:jar:1.0-SNAPSHOT
[INFO] \- org.apache.maven:maven-core:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-model:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-settings:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-settings-builder:jar:3.8.1:compile
[INFO]| +- org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[INFO]| \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
[INFO]| \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[INFO]+- org.apache.maven:maven-builder-support:jar:3.8.1:compile
(…snip…)
{code}
But {{plexus-cipher}} is not a transitive dependency of {{maven-core}} 3.8.2:
{code}
[INFO] org.example:plexus-cipher-mystery:jar:1.0-SNAPSHOT
[INFO] \- org.apache.maven:maven-core:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-model:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-settings:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-settings-builder:jar:3.8.2:compile
[INFO]| +- org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[INFO]| \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
[INFO]+- org.apache.maven:maven-builder-support:jar:3.8.2:compile
(…snip…)
{code}
Both {{maven-core}} 3.8.1 and 3.8.2 have a transitive dependency on
{{org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4}}. When using
{{maven-core}} 3.8.1 {{plexus-sec-dispatcher}} has a dependency on
plexus-cipher, but when using {{maven-core}} 3.8.2 it doesn’t.
The [{{pom.xml}} of
{{plexus-sec-dispatcher:1.4}}|https://search.maven.org/artifact/org.sonatype.plexus/plexus-sec-dispatcher/1.4/jar]
indeed declares a dependency on {{plexus-cipher}} 1.4, but it’s not there when
depending on {{maven-core}} 3.8.2.
This regression was [confirmed by Michael Osipov on the Maven Users mailing
list|https://lists.apache.org/thread.html/r7f5a62fd35dc6698c8f7097734f7c4acf4bb657d6c721e8a7bc76b8c%40%3Cusers.maven.apache.org%3E].
He mentioned that it was caused by commit
41efc134a9067b58a5ab01e9b8b05d2bd84a94f0, which was done for MNG-6886 ("upgrade
plexus-cipher to 1.8 and update changed groupId"). A global exclusion was
performed, but not all affected modules were properly updated (so the change
wasn't complete):
{code}
[DEBUG] org.apache.maven:maven-settings-builder:jar:3.8.2
[DEBUG]org.apache.maven:maven-builder-support:jar:3.8.2:compile
[DEBUG]javax.inject:javax.inject:jar:1:compile
[DEBUG]org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.2.1:compile
[DEBUG]org.apache.maven:maven-settings:jar:3.8.2:compile
[DEBUG]org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
(exclusions managed from [org.sonatype.plexus:plexus-cipher:*:*])
[DEBUG]junit:junit:jar:4.12:test
[DEBUG] org.hamcrest:hamcrest-core:jar:1.3:test (scope managed from
compile) (version managed from 1.3)
[INFO] org.apache.maven:maven-settings-builder:jar:3.8.2
[INFO] +- org.apache.maven:maven-builder-support:jar:3.8.2:compile
[INFO] +- javax.inject:javax.inject:jar:1:compile
[INFO] +- org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[INFO] +- org.codehaus.plexus:plexus-utils:jar:3.2.1:compile
[INFO] +- org.apache.maven:maven-settings:jar:3.8.2:compile
[INFO] +- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
[INFO] \- junit:junit:jar:4.12:test
[INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380109#comment-17380109
]
Nils Breunese commented on MNG-7185:
I've created a pull request to update the Javadoc:
https://github.com/apache/maven/pull/487
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379965#comment-17379965
]
Nils Breunese commented on MNG-7185:
Thanks for the explanation. I guess the conclusion is that there is no bug, but
Javadoc for {{VersionRange#createFromVersionSpec}} doesn't show the syntax for
a closed range for a single version.
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379926#comment-17379926
]
Nils Breunese commented on MNG-7185:
I don't really grasp the concept of a version range representing a recommended
version (what is that used for?), but it looks like {{[1.0.0]}} is the syntax I
actually wanted to use. This syntax is not mentioned in the Javadoc of
{{VersionRange#createFromVersionSpec}}, so that might be a good idea to add?
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7185) Single version range should not match other versions
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379420#comment-17379420
]
Nils Breunese commented on MNG-7185:
I've created a small reproduction project:
https://github.com/breun/maven-version-range-single-version
When running {{mvn test}} I see this:
{code}
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.107 s
<<< FAILURE! - in VersionRangeTest
[ERROR] range_with_single_version_should_not_contain_another_version Time
elapsed: 0.016 s <<< FAILURE!
org.opentest4j.AssertionFailedError:
Expecting value to be false but was true
at
VersionRangeTest.range_with_single_version_should_not_contain_another_version(VersionRangeTest.java:23)
{code}
> Single version range should not match other versions
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7185) Single version range should not match other versions
Nils Breunese created MNG-7185:
--
Summary: Single version range should not match other versions
Key: MNG-7185
URL: https://issues.apache.org/jira/browse/MNG-7185
Project: Maven
Issue Type: Bug
Affects Versions: 3.8.1
Reporter: Nils Breunese
I would expect a version range for a single version to not contain any other
versions, but it seems this is not the case, because this test fails on the
second assertion:
{code}
@Test
void range_with_single_version_should_not_contain_other_version() {
VersionRange singleVersionRange =
VersionRange.createFromVersionSpec("1.0.0");
assertThat(singleVersionRange.containsVersion(new
DefaultArtifactVersion("1.0.0"))).isTrue();
assertThat(singleVersionRange.containsVersion(new
DefaultArtifactVersion("2.0.0"))).isFalse();
}
{code}
Is this a bug, or do I misinterpret what a single version range is? Does
{{maven-artifact}} have a concept for a version range that only contains a
single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-181) Upgrade Ant to 1.9.15
[
https://issues.apache.org/jira/browse/MRESOLVER-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345771#comment-17345771
]
Nils Breunese commented on MRESOLVER-181:
-
I tried this ticket as my first contribution to Maven. I have a pull request
that updates Ant to 1.9.15 and replaces the use of {{BuildFileTest}} with
{{BuildFileRule}}. {{mvn clean verify}} is passing
However, {{mvn -X -Prun-its verify}} is failing:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (smoke-test) on project
maven-resolver-ant-tasks: An Ant BuildException has occured: The following
error occurred while executing this line:
[ERROR] /Users/breun/Projects/maven-resolver-ant-tasks/build.xml:98:
java.lang.NoSuchMethodError:
org.apache.tools.ant.util.FileUtils.createTempFile(Lorg/apache/tools/ant/Project;Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
[ERROR] around Ant part .. @ 4:32 in
/Users/breun/Projects/maven-resolver-ant-tasks/target/antrun/build-main.xml
{code}
I'm afraid I don't know why this happens.
> Upgrade Ant to 1.9.15
> -
>
> Key: MRESOLVER-181
> URL: https://issues.apache.org/jira/browse/MRESOLVER-181
> Project: Maven Resolver
> Issue Type: Dependency upgrade
> Components: Ant Tasks
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Labels: up-for-grabs
>
> - upgrade Ant
> - switch test cases to BuildFileRule (from deprecated BuildFileTest)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865662#comment-16865662
]
Nils Breunese edited comment on MNG-5659 at 6/17/19 2:41 PM:
-
Currently I use a {{.mvn/maven.config}} that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for {{settings.xml}} that would just always be
found, regardless of whether you're in a subdirectory or not.
A workaround is to always call Maven from the project root and use {{-pl
modulename}} whenever you want to limit an execution to a particular module,
but it would sure be nice to just run Maven from any location in a project.
was (Author: breun):
Currently I use a {{.mvn/maven.config}} that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
A workaround is to always call Maven from the project root and use {{-pl
modulename}} whenever you want to limit an execution to a particular module,
but it would sure be nice to just run Maven from any location in a project.
> 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
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865662#comment-16865662
]
Nils Breunese edited comment on MNG-5659 at 6/17/19 2:40 PM:
-
Currently I use a `.mvn/maven.config` that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
A workaround is to always call Maven from the project root and use {{-pl
modulename}} whenever you want to limit an execution to a particular module,
but it would sure be nice to just run Maven from any location in a project.
was (Author: breun):
Currently I use a `.mvn/maven.config` that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
> 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
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865662#comment-16865662
]
Nils Breunese edited comment on MNG-5659 at 6/17/19 2:40 PM:
-
Currently I use a {{.mvn/maven.config}} that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
A workaround is to always call Maven from the project root and use {{-pl
modulename}} whenever you want to limit an execution to a particular module,
but it would sure be nice to just run Maven from any location in a project.
was (Author: breun):
Currently I use a `.mvn/maven.config` that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
A workaround is to always call Maven from the project root and use {{-pl
modulename}} whenever you want to limit an execution to a particular module,
but it would sure be nice to just run Maven from any location in a project.
> 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
(v7.6.3#76005)
[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=16865662#comment-16865662
]
Nils Breunese commented on MNG-5659:
Currently I use a `.mvn/maven.config` that contains the following:
{code}
--settings .mvn/settings.xml
{code}
This works when Maven is run from the project root, but when trying to run
Maven in a subdirectory/submodule you'll get this error:
{code}
[ERROR] Error executing Maven.
java.io.FileNotFoundException: The specified user settings file does not exist:
/path/to/current/directory/.mvn/settings.xml
{code}
It would be cool if you could specify a location relative to the project root.
Or have a default location for `settings.xml` that would just always be found,
regardless of whether you're in a subdirectory or not.
> 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
(v7.6.3#76005)
[jira] [Commented] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865657#comment-16865657
]
Nils Breunese commented on MNG-6303:
[~kwin] I think the issue you're looking for is MNG-5659.
> .mvn/jvm.config should allow to resolve environment variables
> -
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSKINS-119) Text overlapping on mobile devices
Nils Breunese created MSKINS-119: Summary: Text overlapping on mobile devices Key: MSKINS-119 URL: https://issues.apache.org/jira/browse/MSKINS-119 Project: Maven Skins Issue Type: Bug Reporter: Nils Breunese When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an iPhone 4 you see the main body text and navigation text is overlapping, making the page hard to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Breunese updated MSKINS-119: - Attachment: screenshot.jpg > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug >Reporter: Nils Breunese > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-119) Text overlapping on mobile devices
[ https://issues.apache.org/jira/browse/MSKINS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Breunese updated MSKINS-119: - Description: When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an iPhone 4 you see the main body text and navigation text is overlapping, making the page hard to read. Please see the attached screenshot. (was: When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an iPhone 4 you see the main body text and navigation text is overlapping, making the page hard to read.) > Text overlapping on mobile devices > -- > > Key: MSKINS-119 > URL: https://issues.apache.org/jira/browse/MSKINS-119 > Project: Maven Skins > Issue Type: Bug >Reporter: Nils Breunese > Attachments: screenshot.jpg > > > When visiting http://maven.apache.org/plugins/maven-jdeps-plugin/ on an > iPhone 4 you see the main body text and navigation text is overlapping, > making the page hard to read. Please see the attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
