[jira] [Updated] (MPIR-381) Improve russian localization
[ https://issues.apache.org/jira/browse/MPIR-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Samoshin updated MPIR-381: - Description: Add missing string constants, correct some stylistic, spelling and punctuation errors. Github pull request: [https://github.com/apache/maven-project-info-reports-plugin/pull/10] was: Add missing string constants, correct some stylistic, spelling and punctuation errors. Github pull request: [https://github.com/apache/maven-project-info-reports-plugin/pull/|https://github.com/apache/maven-project-info-reports-plugin/pull/9]10 > Improve russian localization > > > Key: MPIR-381 > URL: https://issues.apache.org/jira/browse/MPIR-381 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: plugins >Affects Versions: 3.0.0 >Reporter: Dmitry Samoshin >Assignee: Michael Osipov >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Add missing string constants, correct some stylistic, spelling and > punctuation errors. > > Github pull request: > [https://github.com/apache/maven-project-info-reports-plugin/pull/10] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPIR-381) Improve russian localization
[ https://issues.apache.org/jira/browse/MPIR-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Samoshin updated MPIR-381: - Description: Add missing string constants, correct some stylistic, spelling and punctuation errors. Github pull request: [https://github.com/apache/maven-project-info-reports-plugin/pull/|https://github.com/apache/maven-project-info-reports-plugin/pull/9]10 was: Add missing string constants, correct some stylistic, spelling and punctuation errors. Github pull request: [https://github.com/apache/maven-project-info-reports-plugin/pull/9] > Improve russian localization > > > Key: MPIR-381 > URL: https://issues.apache.org/jira/browse/MPIR-381 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: plugins >Affects Versions: 3.0.0 >Reporter: Dmitry Samoshin >Assignee: Michael Osipov >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Add missing string constants, correct some stylistic, spelling and > punctuation errors. > > Github pull request: > [https://github.com/apache/maven-project-info-reports-plugin/pull/|https://github.com/apache/maven-project-info-reports-plugin/pull/9]10 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-project-info-reports-plugin] dsamoshin closed pull request #9: [MPIR-381] Improve russian localization
dsamoshin closed pull request #9: [MPIR-381] Improve russian localization URL: https://github.com/apache/maven-project-info-reports-plugin/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] dsamoshin commented on issue #9: [MPIR-381] Improve russian localization
dsamoshin commented on issue #9: [MPIR-381] Improve russian localization URL: https://github.com/apache/maven-project-info-reports-plugin/pull/9#issuecomment-501045654 Fixed by new branch dsamoshin/MPIR-381 (new pull request) https://github.com/apache/maven-project-info-reports-plugin/pull/10 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] dsamoshin opened a new pull request #10: [MPIR-381] Improve russian localization
dsamoshin opened a new pull request #10: [MPIR-381] Improve russian localization URL: https://github.com/apache/maven-project-info-reports-plugin/pull/10 1. Improve russian localization 2. Fix some language errors and lead to a general view This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (MNG-6355) HTTP connector does not honor nonProxyHosts when following redirects
[ https://issues.apache.org/jira/browse/MNG-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6355. --- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) No reaction. > HTTP connector does not honor nonProxyHosts when following redirects > > > Key: MNG-6355 > URL: https://issues.apache.org/jira/browse/MNG-6355 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.3 > Environment: Linux >Reporter: Roy >Priority: Major > > Setup: An external maven repository hosting website (outside the firewall) > that does a redirect to an internal website (for authentication). The > external website requires a proxy, the internal one does not. > Observation through Wagon trace: The proxy settings in the POM are used to > access the external website, but the nonProxyHosts in the same POM are not > referred to when accessing the internal website. The request keeps using the > proxy when following redirects. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861498#comment-16861498
]
Michael Osipov commented on MNG-6677:
-
I think we cannot enfore anything at the moment, you should make up something
on your own.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6677:
Fix Version/s: Issues to be reviewed for 4.x
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-608) Unable to run javadoc:aggregate on multi-module projects with one or more pom modules when using Java modules (jigsaw).
[ https://issues.apache.org/jira/browse/MJAVADOC-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hanson updated MJAVADOC-608: --- Description: The following error is displayed and build fail when runnin mvn javadoc:aggregate on a multi-module project where one or more child modules are of pom type (pom) when using mavan modules (jigsaw) [ERROR] Creating an aggregated report for both named and unnamed modules is not possible. [ERROR] Ensure that every module has a module descriptor or is a jar with a MANIFEST.MF containing an Automatic-Module-Name. I've attached a minimal project showing the problem. Run either mvn javadoc:aggregate or mvn site:site maven module with packaging pom should be excluded from the unnames module lest, they are not java modules and will not produce any jar files, named or not. This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) was: The following error is displayed and build fail when runnin mvn javadoc:aggregate on a multi-module project where one or more child modules are of pom type (pom) [ERROR] Creating an aggregated report for both named and unnamed modules is not possible. [ERROR] Ensure that every module has a module descriptor or is a jar with a MANIFEST.MF containing an Automatic-Module-Name. I've attached a minimal project showing the problem. Run either mvn javadoc:aggregate or mvn site:site This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) > Unable to run javadoc:aggregate on multi-module projects with one or more pom > modules when using Java modules (jigsaw). > --- > > Key: MJAVADOC-608 > URL: https://issues.apache.org/jira/browse/MJAVADOC-608 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.1.0 >Reporter: Anders Hanson >Priority: Major > Attachments: module-test.zip > > > The following error is displayed and build fail when runnin mvn > javadoc:aggregate on a multi-module project where one or more child modules > are of pom type (pom) when using mavan modules (jigsaw) > > [ERROR] Creating an aggregated report for both named and unnamed modules is > not possible. > [ERROR] Ensure that every module has a module descriptor or is a jar with a > MANIFEST.MF containing an Automatic-Module-Name. > I've attached a minimal project showing the problem. Run either mvn > javadoc:aggregate or mvn site:site > maven module with packaging pom should be excluded from the unnames module > lest, they are not java modules and will not produce any jar files, named or > not. > This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-608) Unable to run javadoc:aggregate on multi-module projects with one or more pom modules when using Java modules (jigsaw).
[ https://issues.apache.org/jira/browse/MJAVADOC-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hanson updated MJAVADOC-608: --- Summary: Unable to run javadoc:aggregate on multi-module projects with one or more pom modules when using Java modules (jigsaw). (was: Unable to run javadoc:aggregate on multi-module projects with one or more pom modules.) > Unable to run javadoc:aggregate on multi-module projects with one or more pom > modules when using Java modules (jigsaw). > --- > > Key: MJAVADOC-608 > URL: https://issues.apache.org/jira/browse/MJAVADOC-608 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.1.0 >Reporter: Anders Hanson >Priority: Major > Attachments: module-test.zip > > > The following error is displayed and build fail when runnin mvn > javadoc:aggregate on a multi-module project where one or more child modules > are of pom type (pom) > > [ERROR] Creating an aggregated report for both named and unnamed modules is > not possible. > [ERROR] Ensure that every module has a module descriptor or is a jar with a > MANIFEST.MF containing an Automatic-Module-Name. > I've attached a minimal project showing the problem. Run either mvn > javadoc:aggregate or mvn site:site > > This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-608) Unable to run javadoc:aggregate on multi-module projects with one or more pom modules.
Anders Hanson created MJAVADOC-608: -- Summary: Unable to run javadoc:aggregate on multi-module projects with one or more pom modules. Key: MJAVADOC-608 URL: https://issues.apache.org/jira/browse/MJAVADOC-608 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 3.1.0 Reporter: Anders Hanson Attachments: module-test.zip The following error is displayed and build fail when runnin mvn javadoc:aggregate on a multi-module project where one or more child modules are of pom type (pom) [ERROR] Creating an aggregated report for both named and unnamed modules is not possible. [ERROR] Ensure that every module has a module descriptor or is a jar with a MANIFEST.MF containing an Automatic-Module-Name. I've attached a minimal project showing the problem. Run either mvn javadoc:aggregate or mvn site:site This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-608) Unable to run javadoc:aggregate on multi-module projects with one or more pom modules.
[ https://issues.apache.org/jira/browse/MJAVADOC-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hanson updated MJAVADOC-608: --- Attachment: module-test.zip > Unable to run javadoc:aggregate on multi-module projects with one or more pom > modules. > -- > > Key: MJAVADOC-608 > URL: https://issues.apache.org/jira/browse/MJAVADOC-608 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.1.0 >Reporter: Anders Hanson >Priority: Major > Attachments: module-test.zip > > > The following error is displayed and build fail when runnin mvn > javadoc:aggregate on a multi-module project where one or more child modules > are of pom type (pom) > > [ERROR] Creating an aggregated report for both named and unnamed modules is > not possible. > [ERROR] Ensure that every module has a module descriptor or is a jar with a > MANIFEST.MF containing an Automatic-Module-Name. > I've attached a minimal project showing the problem. Run either mvn > javadoc:aggregate or mvn site:site > > This is with maven 3.6.0 and jdk 11.0.3 (latest AdoptJDK) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861468#comment-16861468
]
Vladimir Sitnikov commented on MNG-6677:
{quote}This still does not the id of the license in the list. {quote}
The point of field is to provide machine-readable meaning.
In other words, it is intentional that I don't put "Tomcat BSD-Style License"
to expression.
Does that answer the question?
PS. We could just have a small conversation over zoom/hangout if you think that
would be faster.
PPS. I do get the topic is complicated, and I'm really sorry it takes time to
type/read :-/
PPPS. All this thread appeared for me when I was trying to verify third-party
licenses for Apache JMeter.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861464#comment-16861464
]
Vladimir Sitnikov commented on MNG-6677:
{quote}As an alternative, you can reuse the name element to write your SPDX ID.
Isn't that enough for the moment?
{quote}
I tried that, however there are lots of "license variations".
For instance: [http://jtidy.sourceforge.net/license.html]
It is not a "standard" license.
So it is somewhat expected to list that license in pom.xml as
{code:xml}
Java HTML Tidy License
http://jtidy.sourceforge.net/license.html
{code}
For most of the cases (all?) it would be equivalent to BSD-3-Clause, however it
would probably be incorrect to label the license as just BSD-3-Clause.
That is why I'm inclined that name/url seem to be not that bad, and it would
probably make sense to have a field for "machine-readable effective meaning" of
the license.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861456#comment-16861456
]
Michael Osipov commented on MNG-6677:
-
This still does not the id of the license in the list.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861452#comment-16861452
]
Vladimir Sitnikov commented on MNG-6677:
{quote}Please make a proposal how you would like the next POM version look
like.{quote}
For instance:
{code:xml}
(Apache-2.0 AND MIT) OR (Apache-2.0 AND
BSD-3-Clause)
Tomcat BSD-Style License
tomcat.apache.org/license-bsd.txt
Tomcat MIT-Style License
tomcat.apache.org/license-mit.txt
{code}
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861450#comment-16861450
]
Michael Osipov commented on MNG-6677:
-
As an alternative, you can reuse the name element to write your SPDX ID. Isn't
that enough for the moment?
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861449#comment-16861449
]
Vladimir Sitnikov commented on MNG-6677:
However it would be quite complicated if licensing for different uses is
different (e.g. MIT in winter and BSD in summer).
I guess there should be a pre-defined value for those cases like
ITS_COMPLICATED_CONSULT_LAWYERS, so machine-reader could figure out that the
case is complicated and require manual intervention.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861440#comment-16861440
]
Vladimir Sitnikov edited comment on MNG-6677 at 6/11/19 8:10 PM:
-
{quote}The problem is with the list of licenses also that some people write two
licenses in the name element because it is so. So is Tomcat, for example. How
do you want to cover that?
{quote}
Technically speaking, SPDX has notion of "license expressions" which looks like
{{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with
Bison exception...)
The same would go for "(Apache-2.0 AND MIT) OR (Apache-2.0 AND BSD-3-Clause)"
I don't think we need to have xml representation of that expression though, and
we could be just fine with a string field with "license expression" inside.
{quote}What we could do is to add the license id optionally to the manifest or
the properties bundled the archiver, but that you can already do on your
own{quote}
Unfortunately, that is not enforced by default.
Maven Central enforces everybody to have tag. So they have it. As you
know it is not parsable :(
was (Author: vladimirsitnikov):
{quote}The problem is with the list of licenses also that some people write two
licenses in the name element because it is so. So is Tomcat, for example. How
do you want to cover that?
{quote}
Technically speaking, SPDX has notion of "license expressions" which looks like
{{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with
Bison exception...)
I don't think we need to have xml representation of that expression though, and
we could be just fine with a string field with "license expression" inside.
{quote}What we could do is to add the license id optionally to the manifest or
the properties bundled the archiver, but that you can already do on your
own{quote}
Unfortunately, that is not enforced by default.
Maven Central enforces everybody to have tag. So they have it. As you
know it is not parsable :(
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861440#comment-16861440
]
Vladimir Sitnikov commented on MNG-6677:
{quote}The problem is with the list of licenses also that some people write two
licenses in the name element because it is so. So is Tomcat, for example. How
do you want to cover that?
{quote}
Technically speaking, SPDX has notion of "license expressions" which looks like
{{Apache-2.0+ WITH Bison-exception-2.2}} (which is (Apache 2.0 or later) with
Bison exception...)
I don't think we need to have xml representation of that expression though, and
we could be just fine with a string field with "license expression" inside.
{quote}What we could do is to add the license id optionally to the manifest or
the properties bundled the archiver, but that you can already do on your
own{quote}
Unfortunately, that is not enforced by default.
Maven Central enforces everybody to have tag. So they have it. As you
know it is not parsable :(
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5896) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5896: Fix Version/s: 3.6.2 > Download dependency POMs in parallel > > > Key: MNG-5896 > URL: https://issues.apache.org/jira/browse/MNG-5896 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Harald Wellmann >Priority: Major > Fix For: 3.6.2 > > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.3 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 (v7.6.3#76005)
[jira] [Assigned] (MNG-5896) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MNG-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-5896: --- Assignee: Michael Osipov > Download dependency POMs in parallel > > > Key: MNG-5896 > URL: https://issues.apache.org/jira/browse/MNG-5896 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Harald Wellmann >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.3 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 (v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861419#comment-16861419
]
Michael Osipov commented on MNG-6677:
-
Yes, I was referring to MPIR-382. The problem is with the list of licenses also
that some people write two licenses in the name element because it is so. So is
Tomcat, for example. How do you want to cover that? IT would require a unique
license ID. Please make a proposal how you would like the next POM version look
like.
What we could do is to add the license id optionally to the manifest or the
properties bundled the archiver, but that you can already do on your own.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861406#comment-16861406
]
Vladimir Sitnikov commented on MNG-6677:
[~michael-o], I have tried to search for the request, and I fail to find one.
I see similar issues like https://issues.apache.org/jira/browse/RAT-251 and
https://issues.apache.org/jira/browse/MPIR-382
Did you have something else in mind?
The fun fact is I came from https://github.com/spdx/tools/issues/192 "Support
normalization of license names" (which is very close to MPIR-382), however for
now it looks like the idea of trying to use "standard ID/URL" in tag
won't fly.
That is why I wonder if a dedicated machine-readable field could appear.
Note: I know that 4.0.0 is here "for ages".
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861371#comment-16861371
]
Michael Osipov edited comment on MNG-6677 at 6/11/19 7:09 PM:
--
There is a similiar request on that matter. Please search for, I'd like to
merge both tickets. Please note that this cannot change before the POM is
changed itself.
was (Author: michael-o):
There is a similiar request on that matter. Please search for, I'd like to
merge both tickets.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861371#comment-16861371
]
Michael Osipov commented on MNG-6677:
-
There is a similiar request on that matter. Please search for, I'd like to
merge both tickets.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6474) Maven intermittently hanging at end of multithreaded build
[ https://issues.apache.org/jira/browse/MNG-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861156#comment-16861156 ] Michael Osipov edited comment on MNG-6474 at 6/11/19 7:07 PM: -- If you have two jobs (VMs) accessing the same local repo than you are in trouble. The repo impl is not concurrent-safe. Use Takari's implementation for that or distinct repos. was (Author: michael-o): If you have two jobs (VM) accessing the same local repo than you are in trouble. The repo impl is not concurrent-safe. Use Takari's implementation for that or distinct repos. > Maven intermittently hanging at end of multithreaded build > -- > > Key: MNG-6474 > URL: https://issues.apache.org/jira/browse/MNG-6474 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 >Reporter: Beirtí Ó'Nunáin >Priority: Major > Attachments: Trunk_Build_after_every_commit_UNDEFINED-r15120.log, > thread dump.txt > > > I can't reproduce this with a small skeleton project. It has only started > happening since we upgraded from 3.3 to 3.5. > > I have a multithreaded multi-module build which builds a number of large > (300mb+) artifacts upon SVN commits. I'm running the following goals: > > mvn clean deploy -T 1C > > Reasonably often, perhaps 1 in 10 builds, the build hangs just before where > I'd expect the build to have finished. I'm guessing that maven is attempting > to install an artifact to the local repository (looking at the stack trace) > while the build is about to complete as when I compare the build log from the > hung build to a successful build, the following line is the "Reactor Summary" > This issue happens both on my local machine and on our TeamCity server (Both > multi-processor, multi-core 14 vs 32 cores) > The Thread dump isn't indicating any kind of DeadLock. Our sysadmins have > checked the box for any antivirus scanning which may be impacting the file > copy indicated in the log but can't see anything going on at that time. > Full thread dump from TeamCity attached > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSITE-838) Include doxia confluence module
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861329#comment-16861329 ] Michael Osipov edited comment on MSITE-838 at 6/11/19 7:00 PM: --- OK, I see -- you want to avoid error-prone, repetitive tasks checking for versions and updating them?! was (Author: michael-o): OK, I see -- you want to avoid error-prone, repititive tasks checking for versions and updating them?! > Include doxia confluence module > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6474) Maven intermittently hanging at end of multithreaded build
[ https://issues.apache.org/jira/browse/MNG-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861331#comment-16861331 ] Beirtí Ó'Nunáin commented on MNG-6474: -- :) yeah, I hadn't realised the builds were running on the same agent. The error got masked by the hang (assuming that's what the error was). And it was also happening in developer machines when running command line builds, presumably because eclipse/intellij was also building in the background. > Maven intermittently hanging at end of multithreaded build > -- > > Key: MNG-6474 > URL: https://issues.apache.org/jira/browse/MNG-6474 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 >Reporter: Beirtí Ó'Nunáin >Priority: Major > Attachments: Trunk_Build_after_every_commit_UNDEFINED-r15120.log, > thread dump.txt > > > I can't reproduce this with a small skeleton project. It has only started > happening since we upgraded from 3.3 to 3.5. > > I have a multithreaded multi-module build which builds a number of large > (300mb+) artifacts upon SVN commits. I'm running the following goals: > > mvn clean deploy -T 1C > > Reasonably often, perhaps 1 in 10 builds, the build hangs just before where > I'd expect the build to have finished. I'm guessing that maven is attempting > to install an artifact to the local repository (looking at the stack trace) > while the build is about to complete as when I compare the build log from the > hung build to a successful build, the following line is the "Reactor Summary" > This issue happens both on my local machine and on our TeamCity server (Both > multi-processor, multi-core 14 vs 32 cores) > The Thread dump isn't indicating any kind of DeadLock. Our sysadmins have > checked the box for any antivirus scanning which may be impacting the file > copy indicated in the log but can't see anything going on at that time. > Full thread dump from TeamCity attached > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861329#comment-16861329 ] Michael Osipov commented on MSITE-838: -- OK, I see -- you want to avoid error-prone, repititive tasks checking for versions and updating them?! > Include doxia confluence module > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[
https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861294#comment-16861294
]
Matt Nelson commented on MSITE-838:
---
{quote}
This is probably just convience nothing else, isn't it?
{quote}
Yes exactly that, I had a request to add confluence site support to our company
POM. I grabbed the latest version 1.9 and started getting some errors because
the plugin was using 1.8 for all other doxia deps, but confluence was on 1.9.
So instead of having to keep in sync the doxia version of the plugin and the
added deps. It is easier to add all the automatically detectable parsers by
default.
> Include doxia confluence module
> ---
>
> Key: MSITE-838
> URL: https://issues.apache.org/jira/browse/MSITE-838
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: doxia integration
>Reporter: Matt Nelson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Include doxia confluence module (and possibly all the other modules)
> https://github.com/apache/maven-doxia/tree/master/doxia-modules
> https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861283#comment-16861283 ] Michael Osipov commented on MSITE-838: -- The question was rather targeted at the user: He/she can add them himself/herself and have it available. This is probably just convience nothing else, isn't it? > Include doxia confluence module > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[
https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861266#comment-16861266
]
Matt Nelson commented on MSITE-838:
---
{quote}
Will it work if the parsers are just added to the plugin's dep list on the POM?
{quote}
It should behave the same way markdown does today. I only added the parsers
that have a known expected source directory and/or file extension.
https://maven.apache.org/doxia/references/index.html
> Include doxia confluence module
> ---
>
> Key: MSITE-838
> URL: https://issues.apache.org/jira/browse/MSITE-838
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: doxia integration
>Reporter: Matt Nelson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Include doxia confluence module (and possibly all the other modules)
> https://github.com/apache/maven-doxia/tree/master/doxia-modules
> https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-826) Require Java 7
[
https://issues.apache.org/jira/browse/MSHARED-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861246#comment-16861246
]
Hudson commented on MSHARED-826:
Build succeeded in Jenkins: Maven TLP » maven-shared-utils » master #7
See https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/7/
> Require Java 7
> --
>
> Key: MSHARED-826
> URL: https://issues.apache.org/jira/browse/MSHARED-826
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While working on
> [MSHARED-822|https://issues.apache.org/jira/browse/MSHARED-822] I noticed
> that this project still has {{maven.compiler.source}} and
> {{maven.compiler.target}} on 1.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MPIR-381) Improve russian localization
[ https://issues.apache.org/jira/browse/MPIR-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPIR-381: --- Assignee: Michael Osipov > Improve russian localization > > > Key: MPIR-381 > URL: https://issues.apache.org/jira/browse/MPIR-381 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: plugins >Affects Versions: 3.0.0 >Reporter: Dmitry Samoshin >Assignee: Michael Osipov >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Add missing string constants, correct some stylistic, spelling and > punctuation errors. > > Github pull request: > [https://github.com/apache/maven-project-info-reports-plugin/pull/9] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shared-utils] rfscholte merged pull request #7: [MSHARED-826] Require Java 7
rfscholte merged pull request #7: [MSHARED-826] Require Java 7 URL: https://github.com/apache/maven-shared-utils/pull/7 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-project-info-reports-plugin] michael-o commented on issue #9: [MPIR-381] Improve russian localization
michael-o commented on issue #9: [MPIR-381] Improve russian localization URL: https://github.com/apache/maven-project-info-reports-plugin/pull/9#issuecomment-500944814 Please rebase and squash. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSITE-838) Include doxia confluence module
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861238#comment-16861238 ] Michael Osipov commented on MSITE-838: -- Will it work if the parsers are just added to the plugin's dep list on the POM? > Include doxia confluence module > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated MNG-6677:
---
Description:
Current model for license is something, yet it is not machine-friendly.
Developers tend to put random data into
{{..}}, and it is hard to analyze in
automatic way.
What if we could use SPDX license identifiers/expressions for license
information?
Note: currently POM allows to list multiple tags, and it is not clear
how they should be treated (and? or?). So a machine-readable field should
probably allow for AND/OR license expressions.
So it would be nice if there was a way to declare a machine-readable license
tag.
I'm not affiliated with SPDX, however OSGi use those ids:
https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
was:
Current model for license is something, yet it is not machine-friendly.
Developers tend to put random data into
{{..}}, and it is hard to analyze in
automatic way.
What if we could use SPDX license identifiers/expressions for license
information?
Note: currently POM is allowed to list multiple tags, and it is not
clear how they should be treated (and? or?).
So it would be nice if there was a way to declare a machine-readable license
tag.
I'm not affiliated with SPDX, however OSGi use those ids:
https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6677) Ability to declare machine-readable license identifier for project
Vladimir Sitnikov created MNG-6677:
--
Summary: Ability to declare machine-readable license identifier
for project
Key: MNG-6677
URL: https://issues.apache.org/jira/browse/MNG-6677
Project: Maven
Issue Type: Improvement
Components: POM
Affects Versions: 3.6.1
Reporter: Vladimir Sitnikov
Current model for license is something, yet it is not machine-friendly.
Developers tend to put random data into
{{..}}, and it is hard to analyze in
automatic way.
What if we could use SPDX license identifiers/expressions for license
information?
Note: currently POM is allowed to list multiple tags, and it is not
clear how they should be treated (and? or?).
So it would be nice if there was a way to declare a machine-readable license
tag.
I'm not affiliated with SPDX, however OSGi use those ids:
https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-916) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ https://issues.apache.org/jira/browse/MASSEMBLY-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861180#comment-16861180 ] Michael Osipov commented on MASSEMBLY-916: -- You should create a sample project which can be easily turned into an IT for the one who will pick this up. > When using mulitple Spring dependencies, the files from META-INF (from the > Spring jars) overwrite each other in an executable jar-with-dependencies. > > > Key: MASSEMBLY-916 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-916 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Brian >Priority: Major > Attachments: spring.schemas_v3.1.0.txt, spring.schemas_v3.1.1.txt > > > When using multiple Spring jars with the assembly plugin the spring.schemas > file is not correctly populated and will only include the xsd file mapping > for one jar file. > This appears to be the same issue as MASSEMBLY-360, which was fixed in 2.2, > but is happening again in version 3.1.1. It looks like it is only 3.1.1 that > is a problem since I confirmed that the correct behaviour happens in 3.1.0. > This can go unnoticed since it is often only an issue when the xsd file urls > cannot be accessed, like on an environment with no internet access. I have > attached our META-INF/spring.schemas files for the same project, but built > using versions 3.1.0 and 3.1.1 of the assembly plugin to illustrate the > difference in output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6474) Maven intermittently hanging at end of multithreaded build
[ https://issues.apache.org/jira/browse/MNG-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861156#comment-16861156 ] Michael Osipov commented on MNG-6474: - If you have two jobs (VM) accessing the same local repo than you are in trouble. The repo impl is not concurrent-safe. Use Takari's implementation for that or distinct repos. > Maven intermittently hanging at end of multithreaded build > -- > > Key: MNG-6474 > URL: https://issues.apache.org/jira/browse/MNG-6474 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 >Reporter: Beirtí Ó'Nunáin >Priority: Major > Attachments: Trunk_Build_after_every_commit_UNDEFINED-r15120.log, > thread dump.txt > > > I can't reproduce this with a small skeleton project. It has only started > happening since we upgraded from 3.3 to 3.5. > > I have a multithreaded multi-module build which builds a number of large > (300mb+) artifacts upon SVN commits. I'm running the following goals: > > mvn clean deploy -T 1C > > Reasonably often, perhaps 1 in 10 builds, the build hangs just before where > I'd expect the build to have finished. I'm guessing that maven is attempting > to install an artifact to the local repository (looking at the stack trace) > while the build is about to complete as when I compare the build log from the > hung build to a successful build, the following line is the "Reactor Summary" > This issue happens both on my local machine and on our TeamCity server (Both > multi-processor, multi-core 14 vs 32 cores) > The Thread dump isn't indicating any kind of DeadLock. Our sysadmins have > checked the box for any antivirus scanning which may be impacting the file > copy indicated in the log but can't see anything going on at that time. > Full thread dump from TeamCity attached > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6474) Maven intermittently hanging at end of multithreaded build
[ https://issues.apache.org/jira/browse/MNG-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861121#comment-16861121 ] Beirtí Ó'Nunáin commented on MNG-6474: -- Apologies, missed the earlier commen. I've not seen the issue recently on the build server and I have a theory on why it was happening, just for information We had 2 jobs in teamcity running on the same branch. One was responsible for doing a simple 'mvn deploy' to Artifactory and the other was responsible for Code Quality checks (PMD etc.) After checkins, both would run concurrently and I think that maven was locking on the maven-metadata file in the local repository. We no longer run builds concurrently for the same branch and the issue seems to have gone away. > Maven intermittently hanging at end of multithreaded build > -- > > Key: MNG-6474 > URL: https://issues.apache.org/jira/browse/MNG-6474 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 >Reporter: Beirtí Ó'Nunáin >Priority: Major > Attachments: Trunk_Build_after_every_commit_UNDEFINED-r15120.log, > thread dump.txt > > > I can't reproduce this with a small skeleton project. It has only started > happening since we upgraded from 3.3 to 3.5. > > I have a multithreaded multi-module build which builds a number of large > (300mb+) artifacts upon SVN commits. I'm running the following goals: > > mvn clean deploy -T 1C > > Reasonably often, perhaps 1 in 10 builds, the build hangs just before where > I'd expect the build to have finished. I'm guessing that maven is attempting > to install an artifact to the local repository (looking at the stack trace) > while the build is about to complete as when I compare the build log from the > hung build to a successful build, the following line is the "Reactor Summary" > This issue happens both on my local machine and on our TeamCity server (Both > multi-processor, multi-core 14 vs 32 cores) > The Thread dump isn't indicating any kind of DeadLock. Our sysadmins have > checked the box for any antivirus scanning which may be impacting the file > copy indicated in the log but can't see anything going on at that time. > Full thread dump from TeamCity attached > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven] splatch commented on issue #165: [MNG-6028] Include current goals in resume suggestion
splatch commented on issue #165: [MNG-6028] Include current goals in resume suggestion URL: https://github.com/apache/maven/pull/165#issuecomment-500868319 @michael-o I had no capacity to push it forward towards direction pointed by @hboutemy. If there is a will to accept PR as-is then I can rebase it against the current head. Otherwise, I will have to abandon it. :( This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6432) Space in silently disables mirror
[
https://issues.apache.org/jira/browse/MNG-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861090#comment-16861090
]
Michael Osipov commented on MNG-6432:
-
I'd like to close this because the parsing won't change in 3.x. All docs say
"comma separated". Whitespace trimming isn't mentioned.
> Space in silently disables mirror
> --
>
> Key: MNG-6432
> URL: https://issues.apache.org/jira/browse/MNG-6432
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.0.5, 3.3.9, 3.5.2
> Environment: Maven 3.5.2 (Red Hat 3.5.2-5 on Fedora 28).
> and
> Maven 3.0.5 (Red Hat 3.0.5-17 on RHEL 7.5)
> and
> Maven 3.3.9 on RHEL 7.5
>Reporter: Elias Elmqvist Wulcan
>Priority: Minor
> Labels: newbie
> Fix For: wontfix-candidate
>
> Attachments: Possible list of hits.png
>
>
>
> Maven silently ignores mirror configuration when there is a space in
> mirrorOf. This could be a major problem if the developer's mirror
> configuration is critical and this causes her to not notice that the mirror
> is disabled.
> Without space inside mirrorOf, the mirror setting is respected.
> {code:java}
>
>
>
> loopback
> loopback
> http://127.0.0.1
> !my-repo,*
>
>
>
> {code}
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building mirrorOf-test 1
> [INFO]
>
> Downloading from loopback:
> http://127.0.0.1/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
> {noformat}
>
> With a space after the comma in mirrorOf, the mirror is ignored without
> warning.
> {code:java}
>
>
>
> loopback
> loopback
> http://127.0.0.1
> !my-repo, *
>
>
>
> {code}
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building mirrorOf-test 1
> [INFO]
>
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
> ...
> {noformat}
>
> The problem is reproducible with minimal pom.xm
> {code:java}
>
> 4.0.0
> com.example
> mirrorOf-test
> 1
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6432) Space in silently disables mirror
[
https://issues.apache.org/jira/browse/MNG-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6432:
Fix Version/s: wontfix-candidate
> Space in silently disables mirror
> --
>
> Key: MNG-6432
> URL: https://issues.apache.org/jira/browse/MNG-6432
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.0.5, 3.3.9, 3.5.2
> Environment: Maven 3.5.2 (Red Hat 3.5.2-5 on Fedora 28).
> and
> Maven 3.0.5 (Red Hat 3.0.5-17 on RHEL 7.5)
> and
> Maven 3.3.9 on RHEL 7.5
>Reporter: Elias Elmqvist Wulcan
>Priority: Minor
> Labels: newbie
> Fix For: wontfix-candidate
>
> Attachments: Possible list of hits.png
>
>
>
> Maven silently ignores mirror configuration when there is a space in
> mirrorOf. This could be a major problem if the developer's mirror
> configuration is critical and this causes her to not notice that the mirror
> is disabled.
> Without space inside mirrorOf, the mirror setting is respected.
> {code:java}
>
>
>
> loopback
> loopback
> http://127.0.0.1
> !my-repo,*
>
>
>
> {code}
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building mirrorOf-test 1
> [INFO]
>
> Downloading from loopback:
> http://127.0.0.1/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
> {noformat}
>
> With a space after the comma in mirrorOf, the mirror is ignored without
> warning.
> {code:java}
>
>
>
> loopback
> loopback
> http://127.0.0.1
> !my-repo, *
>
>
>
> {code}
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building mirrorOf-test 1
> [INFO]
>
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
> ...
> {noformat}
>
> The problem is reproducible with minimal pom.xm
> {code:java}
>
> 4.0.0
> com.example
> mirrorOf-test
> 1
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-scm] michael-o commented on issue #33: Scm 775
michael-o commented on issue #33: Scm 775 URL: https://github.com/apache/maven-scm/pull/33#issuecomment-500838100 OK, great. Just rebase and we'll look at together. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6430) UnsatisfiedLinkError:Native Library jdk1.8.0_121\jre\bin\glass.dll already loaded in another classloader
[
https://issues.apache.org/jira/browse/MNG-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860804#comment-16860804
]
Tibor Digana commented on MNG-6430:
---
[~Kalkan]
I have checked the files you attached in Jira and I see that there are two
problems.
I think it is positive, because the first problem (see pictures) are related to
your IDEA project and not Surefire. The second issue looks also simple because
you use different plugin version and different provider version or you use
JUnit5 provider for Surefire from JUnit5 team (do not do it) - see
{{java.lang.NoSuchMethodError:
org.apache.maven.surefire.report.RunListener.testSetStarting(Lorg/apache/maven/surefire/report/ReportEntry;)V}}
and
https://issues.apache.org/jira/secure/attachment/12939385/2018-09-11T16-32-01_814-jvmRun1.dump
> UnsatisfiedLinkError:Native Library jdk1.8.0_121\jre\bin\glass.dll already
> loaded in another classloader
>
>
> Key: MNG-6430
> URL: https://issues.apache.org/jira/browse/MNG-6430
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Burcu
>Assignee: Tibor Digana
>Priority: Major
> Labels: ClassLoader, Classloader, classloader, glass,
> unsatisfiedLinkError
> Attachments: 2018-09-11T16-32-01_814-jvmRun1.dump,
> 2018-09-11T16-32-01_814-jvmRun2.dump, 2018-09-12T13-28-04_278-jvmRun1.dump,
> glassdll.jpg, mvnTest.jpg, plugin.jpg, pom.xml, pom.xml, runAllTest.jpg
>
>
> Although I made the linkte and tried other solutions, I could not resolve the
> glass.dll not found error. I'm looking for a solution to this issue that is
> long-lasting. I'm using Powermock and TestFx. I have encountered this problem
> since I started working with both. I would like to try if you offer a
> solution in this regard. Below you will find some images of the fault.
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-scm] ChrisGWarp commented on issue #33: Scm 775
ChrisGWarp commented on issue #33: Scm 775 URL: https://github.com/apache/maven-scm/pull/33#issuecomment-500771595 I thought I’d committed that. Let me review where I’m st with it. I had to pull it in from SVN days... Sent from my iPhone > On 11 Jun 2019, at 7:54 am, Michael Osipov wrote: > > Any chance to rebase and squash? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRESOURCES-250) Add ability to flatten folder structure into target directory when copying resources
[ https://issues.apache.org/jira/browse/MRESOURCES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860739#comment-16860739 ] Jamie Spence commented on MRESOURCES-250: - Also example from 2010 [here|https://stackoverflow.com/questions/4257858/maven-copy-files-without-subdirectory-structure] > Add ability to flatten folder structure into target directory when copying > resources > > > Key: MRESOURCES-250 > URL: https://issues.apache.org/jira/browse/MRESOURCES-250 > Project: Maven Resources Plugin > Issue Type: New Feature > Components: copy >Reporter: Jamie Spence >Priority: Major > > See flatten description at: > h[ttps://ant.apache.org/manual/Tasks/copy.html|https://ant.apache.org/manual/Tasks/copy.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6676) Resume reactor build after skipped project using -pl !X -rf X combination
Markus Karg created MNG-6676: Summary: Resume reactor build after skipped project using -pl !X -rf X combination Key: MNG-6676 URL: https://issues.apache.org/jira/browse/MNG-6676 Project: Maven Issue Type: Improvement Components: core Affects Versions: 3.6.1 Reporter: Markus Karg With huge multi-module builds sometimes it would come handy if Maven would have a "skip-this-and-resume" option. For example, you have hundreds of sub modules built fine, but one of them is heavily broken; due to your current task you want to ignore that one project just for now, and repeat the reactor build *after* the broken one. Due to the heavily long multi-hours time your already spent, you do not want to start from the beginning. A nice syntax for this would be the combination "-pl !X -rf X" which means: "Resume *after* X". At the moment this is not working, as "-pl X" removes X from the project list, so "-rf X" says it cannot find X. The fix should be that "-pl X" *keeps* X on the project list but marks it explicitly as *SKIPPED*, so "-rf X" *finds* X, but detects that it is to be SKIPPED, so it resumes with the next-in-list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shared-utils] mthmulders commented on issue #7: [MSHARED-826] Require Java 7
mthmulders commented on issue #7: [MSHARED-826] Require Java 7 URL: https://github.com/apache/maven-shared-utils/pull/7#issuecomment-500726193 Thanks for the suggestion. I deliberately didn't want to mix the two (requiring Java 1.7 and using its new features). Java 7 is required for [MSHARED-822](https://issues.apache.org/jira/browse/MSHARED-822) / #6, so we'll soon make use of at least some of the new features. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-compiler-plugin] rhowe commented on issue #19: (doc) Simplify CompilationFailureException
rhowe commented on issue #19: (doc) Simplify CompilationFailureException URL: https://github.com/apache/maven-compiler-plugin/pull/19#issuecomment-500718706 Tests passed for me on an OS X device This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
