[jira] [Updated] (MNGSITE-397) Improve wording on `Providing a uniform build system` in `Introduction`
[
https://issues.apache.org/jira/browse/MNGSITE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edinson E. Padrón Urdaneta updated MNGSITE-397:
---
Labels: docuentation (was: )
> Improve wording on `Providing a uniform build system` in `Introduction`
> ---
>
> Key: MNGSITE-397
> URL: https://issues.apache.org/jira/browse/MNGSITE-397
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Edinson E. Padrón Urdaneta
>Priority: Trivial
> Labels: docuentation
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current text is
> {quote}Maven allows a project to build using its project object model (POM)
> and a set of plugins that are shared by all projects using Maven, providing a
> uniform build system. Once you familiarize yourself with how one Maven
> project builds you automatically know how all Maven projects build saving you
> immense amounts of time when trying to navigate many projects.
> {quote}
> I think this way reads better:
> {quote}Maven allows a project to be built using its project object model
> (POM) and a set of plugins that are shared by all projects using Maven,
> providing a uniform build system. Once you familiarize yourself with how one
> Maven project builds, you automatically know how all Maven projects build,
> saving you immense amounts of time when trying to navigate many projects.
> {quote}
> Changing "to build" with "to be built" and adding a couple of commas.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-399) Fix the `banned dependencies rule` link at `Optional Dependencies and Dependency Exclusions`
[
https://issues.apache.org/jira/browse/MNGSITE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edinson E. Padrón Urdaneta updated MNGSITE-399:
---
Summary: Fix the `banned dependencies rule` link at `Optional Dependencies
and Dependency Exclusions` (was: Fix the `banned dependencies rule` link at `
Optional Dependencies and Dependency Exclusions`)
> Fix the `banned dependencies rule` link at `Optional Dependencies and
> Dependency Exclusions`
>
>
> Key: MNGSITE-399
> URL: https://issues.apache.org/jira/browse/MNGSITE-399
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Edinson E. Padrón Urdaneta
>Priority: Major
> Labels: documentation
>
> Currently the link is constructed this way
> {code:java}
> [banned dependencies
> rule](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
> {code}
> {{But even though that's valid Markdown syntax, the file is an APT (Almost
> Plain Text) instead of MD.}}
>
> {{The correct syntax should be}}
> {code:java}
> {{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
> dependencies rule}}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-399) Fix the `banned dependencies rule` link at `Optional Dependencies and Dependency Exclusions`
[
https://issues.apache.org/jira/browse/MNGSITE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edinson E. Padrón Urdaneta updated MNGSITE-399:
---
Priority: Trivial (was: Major)
> Fix the `banned dependencies rule` link at `Optional Dependencies and
> Dependency Exclusions`
>
>
> Key: MNGSITE-399
> URL: https://issues.apache.org/jira/browse/MNGSITE-399
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Edinson E. Padrón Urdaneta
>Priority: Trivial
> Labels: documentation
>
> Currently the link is constructed this way
> {code:java}
> [banned dependencies
> rule](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
> {code}
> {{But even though that's valid Markdown syntax, the file is an APT (Almost
> Plain Text) instead of MD.}}
>
> {{The correct syntax should be}}
> {code:java}
> {{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
> dependencies rule}}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-398) Fix typos and make improvements in `Configuring Apache Maven`
[
https://issues.apache.org/jira/browse/MNGSITE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edinson E. Padrón Urdaneta updated MNGSITE-398:
---
Labels: document (was: )
> Fix typos and make improvements in `Configuring Apache Maven`
> -
>
> Key: MNGSITE-398
> URL: https://issues.apache.org/jira/browse/MNGSITE-398
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Edinson E. Padrón Urdaneta
>Priority: Trivial
> Labels: document
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current text for `MAVEN_OPTS` is
> {quote}This variable contains parameters used to start up the JVM running
> Maven and can be used to supply additional options to globally to Maven.
> {quote}
> There's an odd `to` before `globally`. An a rewording like this could be
> improve how it is read
> {quote}This variable contains parameters used to start up the JVM running
> Maven and can be used to globally supply additional options to it.
> {quote}
>
> Another typo in
> {quote}Located with in the projects top level folder, the files
> {{maven.config}}, {{jvm.config}}, and {{extensions.xml}} contain project
> specific configuration for running Maven.
> {quote}
> It should be `within` instead of `with in`.
>
> And another one in
> {quote}You don’t need to remember of using this options in {{MAVEN_OPTS}} or
> switching between different configurations. in the end, add the following:
> {quote}
> How about?
> {quote}You don’t need to use these options in \{{MAVEN_OPTS,}}nor switching
> between different configurations.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-399) Fix the `banned dependencies rule` link at ` Optional Dependencies and Dependency Exclusions`
[
https://issues.apache.org/jira/browse/MNGSITE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edinson E. Padrón Urdaneta updated MNGSITE-399:
---
Description:
Currently the link is constructed this way
{code:java}
[banned dependencies
rule](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
{code}
{{But even though that's valid Markdown syntax, the file is an APT (Almost
Plain Text) instead of MD.}}
{{The correct syntax should be}}
{code:java}
{{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
dependencies rule}}
{code}
was:
Currently the link is constructed this way
{quote}{{[banned dependencies
rule]([https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)]}}
{quote}
{{But even though that's valid Markdown syntax, the file is an APT (Almost
Plain Text) instead of MD.}}
{{The correct syntax should be}}
{quote}{{{\{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
dependencies rule
{quote}
> Fix the `banned dependencies rule` link at ` Optional Dependencies and
> Dependency Exclusions`
> -
>
> Key: MNGSITE-399
> URL: https://issues.apache.org/jira/browse/MNGSITE-399
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Edinson E. Padrón Urdaneta
>Priority: Major
> Labels: documentation
>
> Currently the link is constructed this way
> {code:java}
> [banned dependencies
> rule](https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)
> {code}
> {{But even though that's valid Markdown syntax, the file is an APT (Almost
> Plain Text) instead of MD.}}
>
> {{The correct syntax should be}}
> {code:java}
> {{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
> dependencies rule}}
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNGSITE-399) Fix the `banned dependencies rule` link at ` Optional Dependencies and Dependency Exclusions`
Edinson E. Padrón Urdaneta created MNGSITE-399:
--
Summary: Fix the `banned dependencies rule` link at ` Optional
Dependencies and Dependency Exclusions`
Key: MNGSITE-399
URL: https://issues.apache.org/jira/browse/MNGSITE-399
Project: Maven Project Web Site
Issue Type: Bug
Reporter: Edinson E. Padrón Urdaneta
Currently the link is constructed this way
{quote}{{[banned dependencies
rule]([https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html)]}}
{quote}
{{But even though that's valid Markdown syntax, the file is an APT (Almost
Plain Text) instead of MD.}}
{{The correct syntax should be}}
{quote}{{{\{{https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html}banned
dependencies rule
{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-865) Line up all IT's with Maven versions
[ https://issues.apache.org/jira/browse/MSHARED-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-865: Description: Only use the latest version of each line like 3.0.5, 3.1.1, 3.2.5, 3.3.9, 3.5.4, 3.6.3. > Line up all IT's with Maven versions > > > Key: MSHARED-865 > URL: https://issues.apache.org/jira/browse/MSHARED-865 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.13.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: maven-artifact-transfer-0.13.0 > > > Only use the latest version of each line like 3.0.5, 3.1.1, 3.2.5, 3.3.9, > 3.5.4, 3.6.3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHARED-865) Line up all IT's with Maven versions
Karl Heinz Marbaise created MSHARED-865: --- Summary: Line up all IT's with Maven versions Key: MSHARED-865 URL: https://issues.apache.org/jira/browse/MSHARED-865 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-transfer Affects Versions: maven-artifact-transfer-0.13.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-artifact-transfer-0.13.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599241723 > What JDK should I use? JDK 11 or above, I am using 13 now > In the logs I see some timeouts. How long should take it in herddb-core? It depends on the machine, but it takes up to 20 minutes. Logs will contain stacktraces expectially for tests that test error conditions. btw you can see the problem after 10-30 seconds, because you can see that the lines with "Finished...Errors..Failures" do not appear anymore. I hope you can have time to investigate and find the culprit, unfortunately I don't have much time. But I can be an happy tester other than reviewer :-) 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] [Updated] (MJAVADOC-643) make build Reproducible for secondary artifacts
[ https://issues.apache.org/jira/browse/MJAVADOC-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MJAVADOC-643: --- Description: in 3.2.0 with MJAVADOC_637, maven-javadoc-plugin-*.jar is reproducible: perfact, that's the main binary artifact but maven-javadoc-plugin-\*\-sources.jar and maven-javadoc-plugin-*-source-release.zip have some reproducibility issues https://lists.apache.org/thread.html/r88ab50ad35b283a1f585c3ffe3109b80c89cdb6d6ba2285db5956ff4%40%3Cdev.maven.apache.org%3E : would be nice to fix them was: in 3.2.0 with MJAVADOC_637, maven-javadoc-plugin-*.jar is reproducible: perfact, that's the main binary artifact but maven-javadoc-plugin-*-sources.jar and maven-javadoc-plugin-*-source-release.zip have some reproducibility issues: would be nice to fix them > make build Reproducible for secondary artifacts > --- > > Key: MJAVADOC-643 > URL: https://issues.apache.org/jira/browse/MJAVADOC-643 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.2.1 > > > in 3.2.0 with MJAVADOC_637, maven-javadoc-plugin-*.jar is reproducible: > perfact, that's the main binary artifact > but maven-javadoc-plugin-\*\-sources.jar and > maven-javadoc-plugin-*-source-release.zip have some reproducibility issues > https://lists.apache.org/thread.html/r88ab50ad35b283a1f585c3ffe3109b80c89cdb6d6ba2285db5956ff4%40%3Cdev.maven.apache.org%3E > : would be nice to fix them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-637) make build Reproducible
[ https://issues.apache.org/jira/browse/MJAVADOC-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059742#comment-17059742 ] Herve Boutemy edited comment on MJAVADOC-637 at 3/15/20, 5:22 PM: -- issues with secondary artifacts -sources.jar and -source-release.zip lead to another issue MJAVADOC-643 was (Author: hboutemy): issues with secondary artifacts -sources.jar and -source-release.zip lead to another issue > make build Reproducible > --- > > Key: MJAVADOC-637 > URL: https://issues.apache.org/jira/browse/MJAVADOC-637 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 3.1.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MJAVADOC-637) make build Reproducible
[ https://issues.apache.org/jira/browse/MJAVADOC-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MJAVADOC-637. -- Fix Version/s: (was: 3.2.1) 3.2.0 Resolution: Fixed issues with secondary artifacts -sources.jar and -source-release.zip lead to another issue > make build Reproducible > --- > > Key: MJAVADOC-637 > URL: https://issues.apache.org/jira/browse/MJAVADOC-637 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 3.1.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJAVADOC-643) make build Reproducible for secondary artifacts
Herve Boutemy created MJAVADOC-643: -- Summary: make build Reproducible for secondary artifacts Key: MJAVADOC-643 URL: https://issues.apache.org/jira/browse/MJAVADOC-643 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Herve Boutemy Fix For: 3.2.1 in 3.2.0 with MJAVADOC_637, maven-javadoc-plugin-*.jar is reproducible: perfact, that's the main binary artifact but maven-javadoc-plugin-*-sources.jar and maven-javadoc-plugin-*-source-release.zip have some reproducibility issues: would be nice to fix them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599215216 @eolivelli It looks like the PING has killed the JVM for some reason but the PING should be disabled since M4. `at java.base@14-ea/java.util.concurrent.FutureTask.run(FutureTask.java:264)`. That's strange. 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-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599213776 @eolivelli What JDK should I use? In the logs I see some timeouts. How long should take it in `herddb-core`? ``` Caused by: java.util.concurrent.TimeoutException at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1957) at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2092) at herddb.network.Channel.sendMessageWithPduReply(Channel.java:88) ``` I have found some important issue: ``` # Created at 2020-03-15T14:41:17.867 Channel closed while writing the event ':maven-surefire-event:bye: '. ``` and some system properties are missed (jdk.debug=release). ``` # Created at 2020-03-15T14:41:16.717 Channel closed while writing the event ':maven-surefire-event:sys-prop:normal-run:UTF-8:amRrLmRlYnVn:cmVsZWFzZQ==: '. ``` I think it happens due to very asynchronous mode but still this type of events happens before BYE event. It looks like the BYE event disapears due to the channel is closed due to some error. Let's investigate it deeper. 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-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599196530 Thx for testing it, I will reproduce the error with your project. Maybe it would be worth to enable TCP/IP by default shortly on my local PC and see all test failures. We have cc 800 ITs. The config parameter `forkNode` was chosen as non-boolean for several reasons: - we do not want to be overloaded team with user's requests. The attribute `implementation` would make us disburden, see #74 and the comment from Andreas. That's why we have a single parameter with default implementation which can be switched to user's impl. Instead string value as `stdio` is not a class. With the string value, you closed your door for further and readable configuration of the channel because you cannot add nested elements with for instance some custom elements that we do not know in advance yet. With this style you have nice structural written instead of writing/encoding all (class name, communication attributes, port, IP, token) in one string value. This way, the nested elements would become setters/getters of the `forkNode`. The class `ForkNodeFactory` must have no-args constructor to be "injectable" but the setters would pass the custom data other way than the constructor which solves the problem too. - we can support `remote JAR`. Adding more and more configuration parameters is not currently the way to go. If we can encapsulate few related config parameters, why not to do it. Here in the case of `forkNode` the streams are related to the process executing the CLI. If such a requirement comes that the JAR wants to be executed remotely, then most probably the user would like to change the communication protocol with higher security level and the `CommandlineExecutor` would be added to the factory of fork nodes. - I think that there would be small number of projects which will use TCP/IP in the beginning. After we complete the version 3.0.0, we should use TCP/IP as the default implementation and then there would be some project which would just use "remote JAR" or distrubuted execution over virtual nodes like VMs or Docker, or so. But this would be our responsibility. And the rest of the world would be fine with the default TCP/IP embedded in Surefire. 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] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059649#comment-17059649
]
Hudson commented on MSHARED-863:
Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » master #57
See
https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/master/57/
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-864) Refactor and simplify code in Maven3{0,1}DependencyResolver
[
https://issues.apache.org/jira/browse/MSHARED-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-864:
Description:
* In the classes {{Maven30DependencyResolver.java}},
{{Maven31DependencyResolver.java}} code can be cleaned up.
* Refactoring in {{Invoker.java}} is also possible.
The code calls {{setDependencies( List dependencies )}} of
{{CollectRequest}} which allows to give {{null}}
was:
* In the classes {{Maven30DependencyResolver.java}},
{{Maven31DependencyResolver.java}} code can be cleaned up.
* Refactoring in {{Invoker.java}} is also possible.
> Refactor and simplify code in Maven3{0,1}DependencyResolver
> ---
>
> Key: MSHARED-864
> URL: https://issues.apache.org/jira/browse/MSHARED-864
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.13.0
>
>
> * In the classes {{Maven30DependencyResolver.java}},
> {{Maven31DependencyResolver.java}} code can be cleaned up.
> * Refactoring in {{Invoker.java}} is also possible.
> The code calls {{setDependencies( List dependencies )}} of
> {{CollectRequest}} which allows to give {{null}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MSHARED-863.
---
Resolution: Done
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059641#comment-17059641
]
Karl Heinz Marbaise commented on MSHARED-863:
-
Done in
[3145488100f2a247414f692f2c9e1452631282fe|https://gitbox.apache.org/repos/asf?p=maven-artifact-transfer.git;a=commitdiff;h=3145488100f2a247414f692f2c9e1452631282fe]
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059637#comment-17059637
]
Karl Heinz Marbaise commented on MSHARED-863:
-
Separated the code refactoring into MSHARED-864
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-863:
Affects Version/s: (was: maven-artifact-transfer-0.12.0)
maven-artifact-transfer-0.13.0
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-863:
Fix Version/s: maven-artifact-transfer-0.13.0
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.12.0
>Reporter: Piotr Zygielo
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: maven-artifact-transfer-0.13.0
>
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-864) Refactor and simplify code in Maven30DependencyResolver
[
https://issues.apache.org/jira/browse/MSHARED-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-864:
Description:
* In the classes {{Maven30DependencyResolver.java}},
{{Maven31DependencyResolver.java}} code can be cleaned up.
* Refactoring in {{Invoker.java}} is also possible.
was:
* In the classes {{Maven30DependencyResolver.java},
{{Maven31DependencyResolver.java}} code can be cleaned up.
* Refactoring in {{Invoker.java}} is also possible.
> Refactor and simplify code in Maven30DependencyResolver
> ---
>
> Key: MSHARED-864
> URL: https://issues.apache.org/jira/browse/MSHARED-864
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.13.0
>
>
> * In the classes {{Maven30DependencyResolver.java}},
> {{Maven31DependencyResolver.java}} code can be cleaned up.
> * Refactoring in {{Invoker.java}} is also possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-864) Refactor and simplify code in Maven3{0,1}DependencyResolver
[
https://issues.apache.org/jira/browse/MSHARED-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-864:
Summary: Refactor and simplify code in Maven3{0,1}DependencyResolver (was:
Refactor and simplify code in Maven30DependencyResolver)
> Refactor and simplify code in Maven3{0,1}DependencyResolver
> ---
>
> Key: MSHARED-864
> URL: https://issues.apache.org/jira/browse/MSHARED-864
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.13.0
>
>
> * In the classes {{Maven30DependencyResolver.java}},
> {{Maven31DependencyResolver.java}} code can be cleaned up.
> * Refactoring in {{Invoker.java}} is also possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MSHARED-864) Refactor and simplify code in Maven30DependencyResolver
[
https://issues.apache.org/jira/browse/MSHARED-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MSHARED-864:
---
Assignee: Karl Heinz Marbaise
> Refactor and simplify code in Maven30DependencyResolver
> ---
>
> Key: MSHARED-864
> URL: https://issues.apache.org/jira/browse/MSHARED-864
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.13.0
>
>
> * In the classes {{Maven30DependencyResolver.java},
> {{Maven31DependencyResolver.java}} code can be cleaned up.
> * Refactoring in {{Invoker.java}} is also possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-864) Refactor and simplify code in Maven30DependencyResolver
[
https://issues.apache.org/jira/browse/MSHARED-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-864:
Description:
* In the classes {{Maven30DependencyResolver.java},
{{Maven31DependencyResolver.java}} code can be cleaned up.
* Refactoring in {{Invoker.java}} is also possible.
was:The code in the method {{resolveDependenciess}} contains duplicated parts
which can be refactored.
> Refactor and simplify code in Maven30DependencyResolver
> ---
>
> Key: MSHARED-864
> URL: https://issues.apache.org/jira/browse/MSHARED-864
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.13.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-0.13.0
>
>
> * In the classes {{Maven30DependencyResolver.java},
> {{Maven31DependencyResolver.java}} code can be cleaned up.
> * Refactoring in {{Invoker.java}} is also possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo closed pull request #9: ignore .checkstyle
elharo closed pull request #9: ignore .checkstyle URL: https://github.com/apache/maven-shared-utils/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-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599196530 Thx for testing it, I will reproduce the error with your project. Maybe it would be worth to enable TCP/IP by default shortly on my local PC and see all test failures. We have cc 800 ITs. The config parameter `forkNode` was chosen as non-boolean for several reasons: - we do not want to be overloaded team with user's requests. The attribute `implementation` would make us disburden, see #74 and the comment from Andreas. That's why we have a single parameter with default implementation which can be switched to user's impl. Instead string value as `stdio` is not a class. With the string value, you closed your door for further and readable configuration of the channel because you cannot add nested elements with for instance some custom elements that we do not know in advance yet. With this style you have nice structural written instead of writing/encoding all (class name, communication attributes, port, IP, token) in one string value. This way, the nested elements would become setters/getters of the `forkNode`. The class `ForkNodeFactory` must have no-args constructor to be "injectable" but the setters would pass the custom data other way than the constructor which solves the problem too. - we can support `remote JAR`. Adding more and more configuration parameters is not currently the way to go. If we can encapsulate few related config parameters, why not to do it. Here in the case of `forkNode` the streams are related to the process executing the CLI. If such a requirement comes that the JAR wants to be executed remotely, then most probably the user would like to change the communication protocol with higher security level and the `CommandlineExecutor` would be added to the factory of fork nodes. - I think that there would small number of projects which will use TCP/IP in the beginning. After we complete the version 3.0.0, we should use TCP/IP as the default implementation and then there would be some project which would just use "remote JAR" or distrubuted execution over virtual nodes like VMs or Docker, or so. But this would be our responsibility. And the rest of the world would be fine with the default TCP/IP embedded in Surefire. 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-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599196530 Thx for testing it, I will reproduce the error with your project. Maybe it would be worth to enable TCP/IP by default shortly on my local PC and see all test failures. We have cc 800 ITs. The config parameter `forkNode` was chosen as non-boolean for several reasons: - we do not want to be overloaded team with user's requests. The attribute `implementation` would make us disburden, see #74 and the comment from Andreas. That's why we have a single parameter with default implementation which can be switched to user's impl. Instead string value as `stdio` is not a class. With the string value, you closed your door for further and readable configuration of the channel because you cannot add nested elements with for instance some custom elements that we do not know in advance yet. With this style you have nice structural written instead of writing/encoding all (class name, communication attributes, port, IP, token) in one string value. This way, the nested elements would become setters/getters of the `forkNode`. The class `ForkNodeFactory` must have no-args constructor to be "injectable" but the setters would pass the custom data other way than the constructor which solves the problem too. - we can support `remote JAR`. Adding more and more configuration parameters is not currently the way to go. If we can encapsulate few related config parameters, why not to do it. Here in the case of `forkNode` the streams are related to the process executing the CLI. If such a requirement comes that the JAR wants to be executed remotely, then most probably the user would like to change the communication protocol with higher security level and the `CommandlineExecutor` would be added to the factory of fork nodes. - I think that there would small number of projects which will use TCP/IP in the beginning. After we complete the version 3.0.0, we should use TCP/IP as the default implementation and then there would be some project which would just use "remote JAR" or distrubuted execution over virtual nodes like VMs or Docker, or so. But this would be our responsibility. And the rest of the world would be fine with the default TCP/IP embedded in Surefire. https://github.com/apache/maven-surefire/pull/74 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-surefire] eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599188414 I am sorry @Tibor17 but it is not working properly. I am testing here: https://github.com/diennea/herddb branch "fix/try-surefire" If you run "mvn clean install -Dmaven.test.redirectTestOutputToFile=true" you will see that when the build reaches the core project (herddb-core) there is no report of tests finish, only test start events. The build is not using parallel tests, it is using junit4 + single thread + reuseForks = **false** it is very simple. Unfortunately if you set reuseForks=true some test has problem so I cannot test that combination I see these logs: `[DEBUG] Closing the fork 1 after not saying Good Bye.` It looks like the problem appears after the **second** test class, but I am not sure 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-surefire] eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599186839 I am still testing on some project. Please see my comment, it is better to merge to master with a simpler "configuration" model 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-surefire] eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
eolivelli commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599186792 In order to activate TCP communication the user has to add this to the configuration of surefire: `` My suggestions: - to me the word "forkNode" does not tell much, what about "forkCommunicationMode" ? - better not to have a classname, but a string Examples: for new TCP implementation: `tcp` for legacy: `stdio` stdio stands for "Standard I/O" I think that this way: - it is self explaining for users - we will be free to reroute to a different classname or even class model/abstraction Very good that by default we are keeping the "legacy" implementation super great work @Tibor17 ! 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-invoker-plugin] olamy merged pull request #15: [MINVOKER-254] Bump groovy to the latest in 2.4
olamy merged pull request #15: [MINVOKER-254] Bump groovy to the latest in 2.4 URL: https://github.com/apache/maven-invoker-plugin/pull/15 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-invoker-plugin] pzygielo commented on issue #15: [MINVOKER-254] Bump groovy to the latest in 2.4
pzygielo commented on issue #15: [MINVOKER-254] Bump groovy to the latest in 2.4 URL: https://github.com/apache/maven-invoker-plugin/pull/15#issuecomment-599180075 @olamy - may I ask for review please? As follow-up to #11. 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-shared-utils] Tibor17 commented on a change in pull request #11: [SUREFIRE-1556] fail fast on empty element names
Tibor17 commented on a change in pull request #11: [SUREFIRE-1556] fail fast on
empty element names
URL: https://github.com/apache/maven-shared-utils/pull/11#discussion_r392650583
##
File path:
src/test/java/org/apache/maven/shared/utils/xml/PrettyPrintXmlWriterTest.java
##
@@ -40,26 +37,24 @@
*/
public class PrettyPrintXmlWriterTest
{
-StringWriter w;
+private StringWriter w = new StringWriter();;
-PrettyPrintXMLWriter writer;
+private PrettyPrintXMLWriter writer = new PrettyPrintXMLWriter( w );
-@Before
-public void before()
-throws Exception
-{
-w = new StringWriter();
-writer = new PrettyPrintXMLWriter( w );
-}
-
-@After
-public void after()
-throws Exception
+
+@Test
Review comment:
@elharo
In practice the last line with main code must be followed by `e.expect`. So
yes there is guarantee. It is clear that only that one line has to throw the
exception. If it does not, then the `ExpectedException` fails the build. That's
why it was designed in JUnit4. You can use the new `assertThrows` but it has
another meaning - wrapping the exception and checking a new errors or
exceptions.
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
