[jira] [Created] (MNG-8110) POM name unspecified
Philippe Cloutier created MNG-8110:
--
Summary: POM name unspecified
Key: MNG-8110
URL: https://issues.apache.org/jira/browse/MNG-8110
Project: Maven
Issue Type: Bug
Components: Documentation: General
Reporter: Philippe Cloutier
The _project_ element's _name_ element is not specified in the {_}POM
Reference{_}. The only mention of it is in [the _More Project Information_
section|https://maven.apache.org/pom.html#More_Project_Information], which
contains:
{quote}name: Projects tend to have conversational names, beyond the artifactId.
The Sun engineers did not refer to their project as "java-1.5", but rather just
called it "Tiger". Here is where to set that value.
{quote}
It should at least indicate whether it's mandatory, and ideally provide
examples.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7734) Default configuration file (settings.xml) contains copyright notice
[
https://issues.apache.org/jira/browse/MNG-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Cloutier updated MNG-7734:
---
Description:
[The default contents of Maven's settings.xml configuration
file|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob_plain;f=apache-maven/src/assembly/maven/conf/settings.xml;hb=HEAD]
start with the following comment:
{code:xml}
{code}
As a result, my organization has _settings.xml_ files which start with that
copyright notice. This is confusing and distracting, making an already long
file even longer. A casual look makes it seem as if that file is unmodified
source, while it is in fact a configuration file.
It is true that the file contains sizable test comments which must be subject
copyright, so the notice is correct and has some value. However, its prominence
(length and position, before even the file's description) increases the risk of
confusion.
Since copyright notices are not necessary to copyright protection, since the
Apache License is permissive and since the value of copyrights on that file are
limited, I recommend to remove that notice from settings.xml.
was:
[The default contents of Maven's settings.xml configuration
file|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob_plain;f=apache-maven/src/assembly/maven/conf/settings.xml;hb=HEAD]
start with the following comment:
{code:xml}
{code}
As a result, my organization has settings.xml files which start with that
copyright notice. This is confusing and distracting, making an already long
file even longer. A casual look makes it seem as if that file is unmodified
source, while it is in fact a configuration file.
It is true that the file contains sizable test comments which must be subject
copyright, so the notice is correct and has some value. However, its length and
prominence (before even the file's description) increases the risk of confusion.
Since copyright notices are not necessary to copyright protection, since the
Apache License is permissive and since the value of copyrights on that file are
limited, I recommend to remove that notice from settings.xml.
> Default configuration file (settings.xml) contains copyright notice
> ---
>
> Key: MNG-7734
> URL: https://issues.apache.org/jira/browse/MNG-7734
> Project: Maven
> Issue Type: Wish
> Components: Settings
>Affects Versions: 3.9.0
>Reporter: Philippe Cloutier
>Priority: Minor
>
> [The default contents of Maven's settings.xml configuration
> file|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob_plain;f=apache-maven/src/assembly/maven/conf/settings.xml;hb=HEAD]
> start with the following comment:
> {code:xml}
>
> {code}
> As a result, my organization has _settings.xml_ files which start with that
> copyright notice. This is confusing and distracting, making an already long
> file even longer. A casual look makes it seem as if that file is unmodified
> source, while it is in fact a configuration file.
> It is true that the file contains sizable test comments which must be subject
> copyright, so the notice is correct and has some value. However, its
> prominence (length and position, before even the file's description)
> increases the risk of confusion.
> Since copyright notices are not necessary to copyright protection, since the
> Apache License is permissive and since the value of copyrights on that file
> are limited, I recommend to remove that notice from settings.xml.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7735) Default configuration file (settings.xml) description is confusing/misleading
Philippe Cloutier created MNG-7735:
--
Summary: Default configuration file (settings.xml) description is
confusing/misleading
Key: MNG-7735
URL: https://issues.apache.org/jira/browse/MNG-7735
Project: Maven
Issue Type: Improvement
Components: Settings
Reporter: Philippe Cloutier
Attachments: settings_clarification.patch
[The default contents of Maven's settings.xml configuration
file|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob_plain;f=apache-maven/src/assembly/maven/conf/settings.xml;hb=HEAD]
start with the following comment:
{code:xml}
[jira] [Created] (MNG-7734) Default configuration file (settings.xml) contains copyright notice
Philippe Cloutier created MNG-7734:
--
Summary: Default configuration file (settings.xml) contains
copyright notice
Key: MNG-7734
URL: https://issues.apache.org/jira/browse/MNG-7734
Project: Maven
Issue Type: Wish
Components: Settings
Affects Versions: 3.9.0
Reporter: Philippe Cloutier
[The default contents of Maven's settings.xml configuration
file|https://gitbox.apache.org/repos/asf?p=maven.git;a=blob_plain;f=apache-maven/src/assembly/maven/conf/settings.xml;hb=HEAD]
start with the following comment:
{code:xml}
{code}
As a result, my organization has settings.xml files which start with that
copyright notice. This is confusing and distracting, making an already long
file even longer. A casual look makes it seem as if that file is unmodified
source, while it is in fact a configuration file.
It is true that the file contains sizable test comments which must be subject
copyright, so the notice is correct and has some value. However, its length and
prominence (before even the file's description) increases the risk of confusion.
Since copyright notices are not necessary to copyright protection, since the
Apache License is permissive and since the value of copyrights on that file are
limited, I recommend to remove that notice from settings.xml.
--
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&focusedCommentId=17699050#comment-17699050 ] Philippe Cloutier commented on MNG-5659: I'm skeptical about this issue, but for what it's worth, [a very popular Stack Overflow answer|https://stackoverflow.com/questions/67001968/how-to-disable-maven-blocking-external-http-repositories] offers a related workaround. I would appreciate someone mastering Maven to take a stance about whether a project-specific settings.xml makes sense. > 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] (MNGSITE-513) Intra-page anchor links from some tables of contents (ToCs) are broken
[ https://issues.apache.org/jira/browse/MNGSITE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Cloutier updated MNGSITE-513: -- Description: [The _Introduction to Build Profiles_ page|https://maven.apache.org/guides/introduction/introduction-to-profiles.html] starts with a table of contents (ToC) in which each element contains an intra-page link to the relevant section. Unfortunately, all of these links appear to be broken (clicking them has no effect). For example, the viewport remains still after clicking the "JDK" link, which uses URL [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#JDK] It seems the issue is that links use title case, while the actual anchors are completely lowercase. For instance, changing the above example to [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#jdk] should fix. This also affects [the _Settings Reference_|https://maven.apache.org/settings.html], so should probably be checked on all pages. was: [The _Introduction to Build Profiles_ page|https://maven.apache.org/guides/introduction/introduction-to-profiles.html] starts with a table of contents (ToC) in which each element contains an intra-page link to the relevant section. Unfortunately, all of these links appear to be broken (clicking them has no effect). For example, the viewport remains still after clicking the "JDK" link, which uses URL [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#JDK] It seems the issue is that links use title case, while the actual anchors are completely lowercase. For instance, changing the above example to [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#jdk] should fix. Summary: Intra-page anchor links from some tables of contents (ToCs) are broken (was: Intra-page anchor links from "Introduction to Build Profiles" page ToC are broken) > Intra-page anchor links from some tables of contents (ToCs) are broken > -- > > Key: MNGSITE-513 > URL: https://issues.apache.org/jira/browse/MNGSITE-513 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Philippe Cloutier >Priority: Major > > [The _Introduction to Build Profiles_ > page|https://maven.apache.org/guides/introduction/introduction-to-profiles.html] > starts with a table of contents (ToC) in which each element contains an > intra-page link to the relevant section. > Unfortunately, all of these links appear to be broken (clicking them has no > effect). For example, the viewport remains still after clicking the "JDK" > link, which uses URL > [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#JDK] > It seems the issue is that links use title case, while the actual anchors are > completely lowercase. For instance, changing the above example to > [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#jdk] > should fix. > This also affects [the _Settings > Reference_|https://maven.apache.org/settings.html], so should probably be > checked on all pages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNGSITE-515) Profiles not properly specified
[
https://issues.apache.org/jira/browse/MNGSITE-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Cloutier updated MNGSITE-515:
--
Description:
I don't know if an unspecified feature is considered a bug or merely as an
issue, but here goes anyway...
The POM Reference does not specify profiles beyond the following:
h2. Profiles
A new feature of the POM 4.0 is the ability of a project to change settings
depending on the environment where it is being built. A {{profile}} element
contains both an optional activation (a profile trigger) and the set of changes
to be made to the POM if that profile has been activated. For example, a
project built for a test environment may point to a different database than
that of the final deployment. Or dependencies may be pulled from different
repositories based upon the JDK version used. The elements of profiles are as
follows:
# {color:#88}http://maven.apache.org/POM/4.0.0"{color}{color:#00}
{color}{color:#660066}xmlns:xsi{color}{color:#00}={color}{color:#008800}"http://www.w3.org/2001/XMLSchema-instance"{color}
# {color:#00}
{color}{color:#660066}xsi:schemaLocation{color}{color:#00}={color}{color:#008800}"http://maven.apache.org/POM/4.0.0
[https://maven.apache.org/xsd/maven-4.0.0.xsd]"{color}{color:#88}>{color}
# {color:#00} ...{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}test{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#88}{color}
...and the following section about activation.
Several sources including the following indicate that a _profile_ element can
also contain a _properties_ element:
* [https://www.baeldung.com/maven-profiles]
*
[https://stackoverflow.com/questions/35468752/maven-profiles-with-variable-for-properties]
* [https://mkyong.com/maven/maven-profiles-example/]
This also seems to contradict [the _Profiles in POMs_ section of _Introduction
to Build
Profiles_|https://maven.apache.org/guides/introduction/introduction-to-profiles.html#profiles-in-poms],
although I for one struggle to make sense of:
{quote} (flag)(not actually available in the main POM, but used
behind the scenes)(flag)
{quote}
By the way, since profiles can be activated explicitly, the beginning of the
_Activation_ subsection is misleading:
{quote}The power of a profile comes from its ability to modify the basic POM
only under certain circumstances. Those circumstances are specified via an
activation element.
{quote}
was:
The POM Reference does not specify profiles beyond the following:
h2. Profiles
A new feature of the POM 4.0 is the ability of a project to change settings
depending on the environment where it is being built. A {{profile}} element
contains both an optional activation (a profile trigger) and the set of changes
to be made to the POM if that profile has been activated. For example, a
project built for a test environment may point to a different database than
that of the final deployment. Or dependencies may be pulled from different
repositories based upon the JDK version used. The elements of profiles are as
follows:
# {color:#88}http://maven.apache.org/POM/4.0.0"{color}{color:#00}
{color}{color:#660066}xmlns:xsi{color}{color:#00}={color}{color:#008800}"http://www.w3.org/2001/XMLSchema-instance"{color}
# {color:#00}
{color}{color:#660066}xsi:schemaLocation{color}{color:#00}={color}{color:#008800}"http://maven.apache.org/POM/4.0.0
[https://maven.apache.org/xsd/maven-4.0.0.xsd]"{color}{color:#88}>{color}
# {color:#00} ...{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}test{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#
[jira] [Created] (MNGSITE-515) Profiles not properly specified
Philippe Cloutier created MNGSITE-515:
-
Summary: Profiles not properly specified
Key: MNGSITE-515
URL: https://issues.apache.org/jira/browse/MNGSITE-515
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Philippe Cloutier
The POM Reference does not specify profiles beyond the following:
h2. Profiles
A new feature of the POM 4.0 is the ability of a project to change settings
depending on the environment where it is being built. A {{profile}} element
contains both an optional activation (a profile trigger) and the set of changes
to be made to the POM if that profile has been activated. For example, a
project built for a test environment may point to a different database than
that of the final deployment. Or dependencies may be pulled from different
repositories based upon the JDK version used. The elements of profiles are as
follows:
# {color:#88}http://maven.apache.org/POM/4.0.0"{color}{color:#00}
{color}{color:#660066}xmlns:xsi{color}{color:#00}={color}{color:#008800}"http://www.w3.org/2001/XMLSchema-instance"{color}
# {color:#00}
{color}{color:#660066}xsi:schemaLocation{color}{color:#00}={color}{color:#008800}"http://maven.apache.org/POM/4.0.0
[https://maven.apache.org/xsd/maven-4.0.0.xsd]"{color}{color:#88}>{color}
# {color:#00} ...{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}test{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00}
{color}{color:#88}{color}{color:#00}...{color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#00} {color}{color:#88}{color}
# {color:#88}{color}
Several sources including the following indicate that a _profile_ element can
also contain a _properties_ element:
* [https://www.baeldung.com/maven-profiles]
*
[https://stackoverflow.com/questions/35468752/maven-profiles-with-variable-for-properties]
* [https://mkyong.com/maven/maven-profiles-example/]
This also seems to contradict [the _Profiles in POMs_ section of _Introduction
to Build
Profiles_|https://maven.apache.org/guides/introduction/introduction-to-profiles.html#profiles-in-poms],
although I for one struggle to make sense of:
{quote} (flag)(not actually available in the main POM, but used
behind the scenes)(flag)
{quote}
By the way, since profiles can be activated explicitly, the beginning of the
_Activation_ subsection is misleading:
{quote}The power of a profile comes from its ability to modify the basic POM
only under certain circumstances. Those circumstances are specified via an
activation element.
{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNGSITE-514) Introduction to Build Profiles: Implicit profile activation introduction outdated
[
https://issues.apache.org/jira/browse/MNGSITE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697164#comment-17697164
]
Philippe Cloutier commented on MNGSITE-514:
---
By the way, unless I would misunderstand, the introduction of [the parent
section _How can a profile be triggered? How does this vary according to the
type of profile being
used?_|https://maven.apache.org/guides/introduction/introduction-to-profiles.html#how-can-a-profile-be-triggered-how-does-this-vary-according-to-t]
should also be reviewed, since the last 3 elements of the list are just
implicit conditions (they should be part of bullet {_}Implicit{_}).
> Introduction to Build Profiles: Implicit profile activation introduction
> outdated
> -
>
> Key: MNGSITE-514
> URL: https://issues.apache.org/jira/browse/MNGSITE-514
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Philippe Cloutier
>Priority: Minor
>
> The introduction of [the _Implicit profile activation_ section in
> _Introduction to Build
> Profiles_|https://maven.apache.org/guides/introduction/introduction-to-profiles.html#implicit-profile-activation]
> contains the following sentence:
> {quote}{color:#33}Currently, this detection is limited to JDK version
> matching, operating system matching or the presence/the value of a system
> property.{color}
> {quote}
> The list is incomplete (probably outdated), since as documented at the end of
> that same section, file existence can also be tested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-514) Introduction to Build Profiles: Implicit profile activation introduction outdated
Philippe Cloutier created MNGSITE-514:
-
Summary: Introduction to Build Profiles: Implicit profile
activation introduction outdated
Key: MNGSITE-514
URL: https://issues.apache.org/jira/browse/MNGSITE-514
Project: Maven Project Web Site
Issue Type: Bug
Reporter: Philippe Cloutier
The introduction of [the _Implicit profile activation_ section in _Introduction
to Build
Profiles_|https://maven.apache.org/guides/introduction/introduction-to-profiles.html#implicit-profile-activation]
contains the following sentence:
{quote}{color:#33}Currently, this detection is limited to JDK version
matching, operating system matching or the presence/the value of a system
property.{color}
{quote}
The list is incomplete (probably outdated), since as documented at the end of
that same section, file existence can also be tested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-513) Intra-page anchor links from "Introduction to Build Profiles" page ToC are broken
Philippe Cloutier created MNGSITE-513: - Summary: Intra-page anchor links from "Introduction to Build Profiles" page ToC are broken Key: MNGSITE-513 URL: https://issues.apache.org/jira/browse/MNGSITE-513 Project: Maven Project Web Site Issue Type: Bug Reporter: Philippe Cloutier [The _Introduction to Build Profiles_ page|https://maven.apache.org/guides/introduction/introduction-to-profiles.html] starts with a table of contents (ToC) in which each element contains an intra-page link to the relevant section. Unfortunately, all of these links appear to be broken (clicking them has no effect). For example, the viewport remains still after clicking the "JDK" link, which uses URL [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#JDK] It seems the issue is that links use title case, while the actual anchors are completely lowercase. For instance, changing the above example to [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#jdk] should fix. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNGSITE-512) POM Reference: Repositories section confusing
Philippe Cloutier created MNGSITE-512: - Summary: POM Reference: Repositories section confusing Key: MNGSITE-512 URL: https://issues.apache.org/jira/browse/MNGSITE-512 Project: Maven Project Web Site Issue Type: Improvement Reporter: Philippe Cloutier [The Repositories section of the POM Reference page|https://maven.apache.org/pom.html#Repositories] is confusing. It covers one type of repositories (repositories of Maven artifacts), but not a much more common type of repositories (repositories of source code). It would be less confusing to either: * rename the section with a more specific title (such as "Artifact repositories") * or also cover source code repositories, if that is supported By the way, reviewing the section's current contents (e.g. discussing purpose before implementation) could also help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-324) Make the BF algorithm as the default option to speed up maven dependency resolution and downloading
[
https://issues.apache.org/jira/browse/MRESOLVER-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693403#comment-17693403
]
Philippe Cloutier commented on MRESOLVER-324:
-
What downsides does BFS have when compared to DFS?
> Make the BF algorithm as the default option to speed up maven dependency
> resolution and downloading
> ---
>
> Key: MRESOLVER-324
> URL: https://issues.apache.org/jira/browse/MRESOLVER-324
> Project: Maven Resolver
> Issue Type: Wish
> Components: Resolver
>Affects Versions: 1.10.0
>Reporter: wei cai
>Priority: Major
> Fix For: 1.10.0
>
>
> This is a WISH type Jira :D. So far, Maven 3.9.0 has released a BF algorithm
> which includes changes from below JIRAs along with the DF option (default).
> * MRESOLVER-228
> * MRESOLVER-247
> * MRESOLVER-7
> The BF algorithm solves:
> * Cache missing issue when comes to resolve heavy dependencies with
> different exclusions, it can help speed up dependency resolution especially
> for large scale enterprise level projects.
> * Improve download speed by:
> ** Skip downloading poms for conflict losers.
> ** Download poms in parallel.
> Below is the introduction in
> [https://maven.apache.org/docs/3.9.0/release-notes.html:]
> {noformat}
> Choice of resolver collectors: a new BF collector (with parallel POM
> downloads) has been added along the existing DF one.{noformat}
> The solution is already widely adopted at eBay. You can simply enable it by
> putting below config item into file: ${maven.projectBasedir}/.mvn/maven.config
> {code:java}
> aether.dependencyCollector.impl=bf {code}
> More introduction about this option:
> [https://maven.apache.org/resolver/configuration.html]
> Please try and tells us how much it helps by running:
> {code:java}
> 1. mvn clean install -DskipTests -Dmaven.repo.local=bf
> -Daether.dependencyCollector.impl=bf
> 2. mvn clean install -DskipTests -Dmaven.repo.local=df{code}
> With more feedback collected, we would be able to propose the changes to
> Maven team to make BF as the default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-324) Make the BF algorithm as the default option to speed up maven dependency resolution and downloading
[
https://issues.apache.org/jira/browse/MRESOLVER-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692974#comment-17692974
]
Philippe Cloutier commented on MRESOLVER-324:
-
Thank you for this request [~wecai]
For those wondering, "BF" means [Breadth-First
Search|https://en.wikipedia.org/wiki/Breadth-first_search].
> Make the BF algorithm as the default option to speed up maven dependency
> resolution and downloading
> ---
>
> Key: MRESOLVER-324
> URL: https://issues.apache.org/jira/browse/MRESOLVER-324
> Project: Maven Resolver
> Issue Type: Wish
> Components: Resolver
>Affects Versions: 1.10.0
>Reporter: wei cai
>Priority: Major
> Fix For: 1.10.0
>
>
> This is a WISH type Jira :D. So far, Maven 3.9.0 has released a BF algorithm
> which includes changes from below JIRAs along with the DF option (default).
> * MRESOLVER-228
> * MRESOLVER-247
> * MRESOLVER-7
> The BF algorithm solves:
> * Cache missing issue when comes to resolve heavy dependencies with
> different exclusions, it can help speed up dependency resolution especially
> for large scale enterprise level projects.
> * Improve download speed by:
> ** Skip downloading poms for conflict losers.
> ** Download poms in parallel.
> Below is the introduction in
> [https://maven.apache.org/docs/3.9.0/release-notes.html:]
> {noformat}
> Choice of resolver collectors: a new BF collector (with parallel POM
> downloads) has been added along the existing DF one.{noformat}
> The solution is already widely adopted at eBay. You can simply enable it by
> putting below config item into file: ${maven.projectBasedir}/.mvn/maven.config
> {code:java}
> aether.dependencyCollector.impl=bf {code}
> More introduction about this option:
> [https://maven.apache.org/resolver/configuration.html]
> Please try and tells us how much it helps by running:
> {code:java}
> 1. mvn clean install -DskipTests -Dmaven.repo.local=bf
> -Daether.dependencyCollector.impl=bf
> 2. mvn clean install -DskipTests -Dmaven.repo.local=df{code}
> With more feedback collected, we would be able to propose the changes to
> Maven team to make BF as the default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel in BF collector
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692967#comment-17692967 ] Philippe Cloutier commented on MRESOLVER-7: --- Thank you [~wecai] Considering the change in this ticket's scope, I suggest those who voted for this ticket hoping to see a change in default behavior to also vote for MNG-5896. > Download dependency POMs in parallel in BF collector > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.0 > > Attachments: resolve_deps.png, resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel in BF collector
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626603#comment-17626603 ] Philippe Cloutier commented on MRESOLVER-7: --- Thank you very much [~wecai] for these details. I would appreciate a clarification of what "Skipper to skip unnecessary resolution" means. > Download dependency POMs in parallel in BF collector > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.0 > > Attachments: resolve_deps.png, resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel in BF collector
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625917#comment-17625917 ] Philippe Cloutier commented on MRESOLVER-7: --- Thank you very much for your work as well as for this valuable explanation [~cstamas] I know nothing about collectors and the model builder nuance, but if I understand the situation correctly, I recommend to: * Restore this ticket's original title and IN PROGRESS status * If a ticket specifically about the BF collector is needed or useful: ** create one or clone this one ** set it as a dependency of this one ** mark it as resolved * If a ticket specifically about the DF collector is needed or useful: ** create one or clone this one ** set it as a dependency of this one * Ensure that the assignee of each ticket is representative This may have been overdue, but seeing how much work was already needed, congratulations for what was already accomplished. > Download dependency POMs in parallel in BF collector > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.0 > > Attachments: resolve_deps.png, resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel in BF collector
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616469#comment-17616469 ] Philippe Cloutier commented on MRESOLVER-7: --- [~cstamas] : Does this specifically affect the BF collector as opposed to other collectors? Is there a workaround? > Download dependency POMs in parallel in BF collector > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.0 > > Attachments: resolve_deps.png, resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-771) Broken link from Introduction - Examples to "Resolving Conflicts Using the Dependency Tree"
[ https://issues.apache.org/jira/browse/MDEP-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420007#comment-17420007 ] Philippe Cloutier commented on MDEP-771: Thank you Karl A "pull request" being a merge request? We do not have a solution for this at this time. > Broken link from Introduction - Examples to "Resolving Conflicts Using the > Dependency Tree" > --- > > Key: MDEP-771 > URL: https://issues.apache.org/jira/browse/MDEP-771 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Philippe Cloutier >Priority: Minor > > [The Introduction page's Examples > section|http://maven.apache.org/plugins/maven-dependency-plugin/index.html] > contains a link titled "Resolving Conflicts Using the Dependency Tree" to the > following URL: > http://maven.apache.org/plugins/maven-dependency-plugin/index.html > That URL unfortunately yields a Page Not Found error. The content can be seen > on > https://maven.apache.org/plugins-archives/maven-dependency-plugin-2.4/examples/resolving-conflicts-using-the-dependency-tree.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MDEP-771) Broken link from Introduction - Examples to "Resolving Conflicts Using the Dependency Tree"
Philippe Cloutier created MDEP-771: -- Summary: Broken link from Introduction - Examples to "Resolving Conflicts Using the Dependency Tree" Key: MDEP-771 URL: https://issues.apache.org/jira/browse/MDEP-771 Project: Maven Dependency Plugin Issue Type: Bug Reporter: Philippe Cloutier [The Introduction page's Examples section|http://maven.apache.org/plugins/maven-dependency-plugin/index.html] contains a link titled "Resolving Conflicts Using the Dependency Tree" to the following URL: http://maven.apache.org/plugins/maven-dependency-plugin/index.html That URL unfortunately yields a Page Not Found error. The content can be seen on https://maven.apache.org/plugins-archives/maven-dependency-plugin-2.4/examples/resolving-conflicts-using-the-dependency-tree.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391796#comment-17391796 ] Philippe Cloutier commented on SUREFIRE-1844: - [~michaelboyles] thank you, but can you clarify which release/features you refer to? > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233075#comment-17233075 ] Philippe Cloutier commented on SUREFIRE-1844: - Thank you for the quick reaction Could someone clarify when the changes are supposed to be deployed? > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6093) create a slf4j-simple provider extension that supports level color rendering
[ https://issues.apache.org/jira/browse/MNG-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203357#comment-17203357 ] Philippe Cloutier commented on MNG-6093: Thank you Herve It looks like the solution is effective by default with SLF4J. We still had monochrome SLF4J output, but in our case this was a Spring problem which is worked around with spring.output.ansi.enabled=ALWAYS (even though the problem happened with DETECT). > create a slf4j-simple provider extension that supports level color rendering > > > Key: MNG-6093 > URL: https://issues.apache.org/jira/browse/MNG-6093 > Project: Maven > Issue Type: New Feature > Components: Logging >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5.0-alpha-1, 3.5.0 > > > With color support, core Maven and plugins do general message colorization > (or more high-level "message styling" through maven-shared-utils) > slf4j provider however has to add color: > - for log level output (DEBUG/INFO/WARNING/ERROR) > - for stacktrace rendering > That's why we use Gossip slf4j provider: it has sufficient little extension > points to add this, with just a little bit of code (see > http://maven.apache.org/ref/3-LATEST/maven-embedder/apidocs/org/apache/maven/cli/logging/impl/gossip/package-summary.html > ) and configuration > The issue with switching to Gossip slf4j provider is that people don't know > it and it does not have the same features as slf4j-simple (missing relative > timestamps and configuration with CLI: see > http://mail-archives.apache.org/mod_mbox/maven-dev/201607.mbox/%3CCAK8jvqxYNK4weM2Frp4Brg3J7EybyjBiCsSRdGuNMQhYAG728Q%40mail.gmail.com%3E > ), the configuration file is not the same (name nor content). > But the extension points are not that big: if slf4j-simple provider just made > a few methods protected instread of private, it would be extensible > What if we just copy slf4j-simple to change the signatures and create small > extension classes? The license permits it, we can try it and eventually see > with slf4j if the modification can go into official release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6093) create a slf4j-simple provider extension that supports level color rendering
[ https://issues.apache.org/jira/browse/MNG-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202427#comment-17202427 ] Philippe Cloutier commented on MNG-6093: Would someone explain how this was solved? The links are broken so I really can't figure it out. > create a slf4j-simple provider extension that supports level color rendering > > > Key: MNG-6093 > URL: https://issues.apache.org/jira/browse/MNG-6093 > Project: Maven > Issue Type: New Feature > Components: Logging >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5.0-alpha-1, 3.5.0 > > > With color support, core Maven and plugins do general message colorization > (or more high-level "message styling" through maven-shared-utils) > slf4j provider however has to add color: > - for log level output (DEBUG/INFO/WARNING/ERROR) > - for stacktrace rendering > That's why we use Gossip slf4j provider: it has sufficient little extension > points to add this, with just a little bit of code (see > http://maven.apache.org/ref/3-LATEST/maven-embedder/apidocs/org/apache/maven/cli/logging/impl/gossip/package-summary.html > ) and configuration > The issue with switching to Gossip slf4j provider is that people don't know > it and it does not have the same features as slf4j-simple (missing relative > timestamps and configuration with CLI: see > http://mail-archives.apache.org/mod_mbox/maven-dev/201607.mbox/%3CCAK8jvqxYNK4weM2Frp4Brg3J7EybyjBiCsSRdGuNMQhYAG728Q%40mail.gmail.com%3E > ), the configuration file is not the same (name nor content). > But the extension points are not that big: if slf4j-simple provider just made > a few methods protected instread of private, it would be extensible > What if we just copy slf4j-simple to change the signatures and create small > extension classes? The license permits it, we can try it and eventually see > with slf4j if the modification can go into official release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1843) Trademarks / privacy policy footer displays broken
Philippe Cloutier created SUREFIRE-1843: --- Summary: Trademarks / privacy policy footer displays broken Key: SUREFIRE-1843 URL: https://issues.apache.org/jira/browse/SUREFIRE-1843 Project: Maven Surefire Issue Type: Bug Components: documentation Reporter: Philippe Cloutier Attachments: image-2020-09-22-17-29-40-357.png The footer which is at the end of Surefire's documentation pages, such as [this one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have a broken display (at least in Firefox 81 and Google Chrome 85). The horizontal alignment is incorrect, causing the sentence to start outside the visible area and its end to overlap with the "Privacy policy" link, as can be seen in the screenshot below: !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
