[GitHub] [maven] gnodet commented on pull request #399: [MNG-7034] StackOverflowError thrown if a cycle exists in BOM imports
gnodet commented on pull request #399: URL: https://github.com/apache/maven/pull/399#issuecomment-740437944 @pzygielo thx for reviewing. What's the next steps to get this merged ? 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
[jira] [Commented] (MNG-7035) Migrate unit tests to Unit 4
[ https://issues.apache.org/jira/browse/MNG-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245712#comment-17245712 ] Guillaume Nodet commented on MNG-7035: -- The pull request is quite big, but none of the non-classes has been touched, so the risks are fairly minor. It would be nice if someone could review it because any change in the tests will likely break it ... > Migrate unit tests to Unit 4 > > > Key: MNG-7035 > URL: https://issues.apache.org/jira/browse/MNG-7035 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1865) ChecksumCalculator getSha1 does not compute checksums correctly
[
https://issues.apache.org/jira/browse/SUREFIRE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1865.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=1da3462303afe17c030cb884953f11133b8b4796
> ChecksumCalculator getSha1 does not compute checksums correctly
> ---
>
> Key: SUREFIRE-1865
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1865
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Gian Merlino
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> ChecksumCalculator does the following in getSha1:
> {code}
> md.update( configValue.getBytes( ISO_8859_1 ), 0, configValue.length() );
> {code}
> This isn't using the right length, because {{configValue.length()}} is a
> length in characters, not bytes. This will lead to the wrong length being
> used for any strings that contain characters that aren't encoded in a single
> byte.
> Additionally, I believe that this class can be used to compute checksums on
> strings that fall outside the ISO_8859_1 character set, so UTF_8 would be a
> better choice.
> I ran into this when defining a test property that contained Cyrillic
> characters and emojis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
Tibor17 commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-740211317 @gianm Thx for contributing! 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
[GitHub] [maven-surefire] Tibor17 merged pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
Tibor17 merged pull request #327: URL: https://github.com/apache/maven-surefire/pull/327 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
[jira] [Updated] (SUREFIRE-1865) ChecksumCalculator getSha1 does not compute checksums correctly
[
https://issues.apache.org/jira/browse/SUREFIRE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1865:
---
Fix Version/s: 3.0.0-M6
> ChecksumCalculator getSha1 does not compute checksums correctly
> ---
>
> Key: SUREFIRE-1865
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1865
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Gian Merlino
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> ChecksumCalculator does the following in getSha1:
> {code}
> md.update( configValue.getBytes( ISO_8859_1 ), 0, configValue.length() );
> {code}
> This isn't using the right length, because {{configValue.length()}} is a
> length in characters, not bytes. This will lead to the wrong length being
> used for any strings that contain characters that aren't encoded in a single
> byte.
> Additionally, I believe that this class can be used to compute checksums on
> strings that fall outside the ISO_8859_1 character set, so UTF_8 would be a
> better choice.
> I ran into this when defining a test property that contained Cyrillic
> characters and emojis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SUREFIRE-1865) ChecksumCalculator getSha1 does not compute checksums correctly
[
https://issues.apache.org/jira/browse/SUREFIRE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1865:
--
Assignee: Tibor Digana
> ChecksumCalculator getSha1 does not compute checksums correctly
> ---
>
> Key: SUREFIRE-1865
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1865
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Gian Merlino
>Assignee: Tibor Digana
>Priority: Major
>
> ChecksumCalculator does the following in getSha1:
> {code}
> md.update( configValue.getBytes( ISO_8859_1 ), 0, configValue.length() );
> {code}
> This isn't using the right length, because {{configValue.length()}} is a
> length in characters, not bytes. This will lead to the wrong length being
> used for any strings that contain characters that aren't encoded in a single
> byte.
> Additionally, I believe that this class can be used to compute checksums on
> strings that fall outside the ISO_8859_1 character set, so UTF_8 would be a
> better choice.
> I ran into this when defining a test property that contained Cyrillic
> characters and emojis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPOM-244) Upload SHA-512 to Staging Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245543#comment-17245543 ] Michael Osipov commented on MPOM-244: - No, you need to replace Resolver completely, but this isn't an issue with 3.6.3. > Upload SHA-512 to Staging Repository > > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - all attached artifacts and > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-244) Upload SHA-512 to Staging Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245534#comment-17245534 ] Konrad Windszus commented on MPOM-244: -- That sounds good. Is it possible to update to a newer resolver with the approach from MNG-5771 or does this require waiting for Maven 4? > Upload SHA-512 to Staging Repository > > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - all attached artifacts and > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
Tibor17 commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-740165186 I am investigating this error but i think it has nothing to do with your changes. Anyway the `EventConsumerThread` which sits in the particular unit test will be changed soon, so i take it as a hint for me from the build process. ;-) 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
[GitHub] [maven-surefire] gianm commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
gianm commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-740157615 Hmm, now there is an error with one of the Windows builds https://github.com/apache/maven-surefire/pull/327/checks?check_run_id=1512498690. Any idea what is going on there? I read the log but I'm not sure what it means. 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
[GitHub] [maven-surefire] Tibor17 commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
Tibor17 commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-740154064 @gianm thx, now it looks fine as a complete change. 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
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245396#comment-17245396
]
Michael Osipov commented on WAGON-575:
--
Some assumptions do not apply which I have made. Resets are properly performed.
I am still rejecting the PR after rereading all comments and our codebsae and
will explain why:
* First of all {{TransferFailedException}} wraps:
{code}
catch ( IOException | HttpException | InterruptedException e )
{
fireTransferError( resource, e, TransferEvent.REQUEST_PUT );
throw new TransferFailedException( formatTransferFailedMessage(
url, getProxyInfo() ), e );
}
{code}
Not all I/O exceptions can be recovered. {{HttpException}} is so generic that
most of the subtypes cannot be recovered from. This is not a way to go.
Especially not on such a high level because the changeset in the PR applies to
all stream wagons. Basically [~olegk] has already provide the way to go. One
needs to utilize
{{org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.createRetryHandler()}}
inside
{{org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData(int,
InputData)}} to make work what you have in mind. That is something I would
really consider to include when there is a test depicting that it works. This
would not require to introduce any new user visiable changes.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at
[GitHub] [maven-surefire] gianm commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
gianm commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-740083248 > @gianm > Pls add your test `ChecksumCalculatorTest` to the [JUnit4SuiteTest](https://github.com/apache/maven-surefire/blob/c76ae87d3234bc27daea1cd7a175cdc4fa6608a4/maven-surefire-common/src/test/java/org/apache/maven/surefire/JUnit4SuiteTest.java). OK, I've made that change. The tests didn't seem to be in any particular order, so I added the new one to the end of the list. 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
[GitHub] [maven-scm] cquoss commented on pull request #109: SCM-947
cquoss commented on pull request #109: URL: https://github.com/apache/maven-scm/pull/109#issuecomment-740074752 Another point: Where lies the documentation for the changelog goal of the maven-scm-plugin? An update here should be part of / done in parallel by me / for this pull request. Please guide me. 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
[GitHub] [maven-scm] cquoss edited a comment on pull request #109: SCM-947
cquoss edited a comment on pull request #109: URL: https://github.com/apache/maven-scm/pull/109#issuecomment-740069340 Something in Travis CI seems broken, unrelated to my changes. For builds with Java 6 and 7 the config does not seem to fit any more. install-jdk script is the culprit here. Being asked to install feature "7" (or "6" or "8") it rejects and states only 9 to 16 are allowed. This misconfiguration needs some fixing. 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
[GitHub] [maven-scm] cquoss opened a new pull request #110: [SCM-948] Make the limit parameter work for git and svn exe
cquoss opened a new pull request #110: URL: https://github.com/apache/maven-scm/pull/110 These changes would be sufficient for me to make parameter limit work with goal changelog for providers git and svn exe. This might seem to be an egoistic point of view and i am open to discussion and willing to spend some more time to it when someone points me to what else might be useful to the community here. 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
[GitHub] [maven-scm] cquoss commented on pull request #109: SCM-947
cquoss commented on pull request #109: URL: https://github.com/apache/maven-scm/pull/109#issuecomment-740069340 Something in Travis CI seems broken, unrelated to my changes. For builds with Java 6 and 7 the config does not seem to fit any more. 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
[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245321#comment-17245321
]
Igor Dvorzhak edited comment on WAGON-575 at 12/7/20, 4:19 PM:
---
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
I think that this PR does not need to deal with `InputStream` and progress
tracking because it retries whole file download e2e?
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
was (Author: medb):
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
These PR is not dealing with `InputStream` and progress tracking because it
retries whole file download e2e.
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245321#comment-17245321
]
Igor Dvorzhak commented on WAGON-575:
-
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
These PR is not dealing with `InputStream` and progress tracking because it
retries whole file download e2e.
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at
[GitHub] [maven-assembly-plugin] elharo commented on pull request #38: MASSEMBLY-945 - speed improvements
elharo commented on pull request #38: URL: https://github.com/apache/maven-assembly-plugin/pull/38#issuecomment-740008378 Far more often than not, microoptimizations like this result in no measurable impact. All claims of performance improvements need numbers. 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
[jira] [Commented] (MCHECKSTYLE-387) Deprecate method setUpCheckstyleClassloader in 3.1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245262#comment-17245262
]
Hudson commented on MCHECKSTYLE-387:
Build succeeded in Jenkins: Maven » Maven TLP » maven-checkstyle-plugin »
master #22
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/master/22/
> Deprecate method setUpCheckstyleClassloader in 3.1.2
>
>
> Key: MCHECKSTYLE-387
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-387
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 3.1.1
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Current situation
> In 3.1.1, the PR [https://github.com/apache/maven-checkstyle-plugin/pull/18]
> added a {{try-catch}}-block to the to-be-removed method call
> {{Checker::setClassLoader}}.
> Since users should be encuraged to upgrade and maven-plugin-developers should
> know that this method should be removed some time, a warning is to be issued
> if the method call was successful (i.e. when not entering the catch block).
> h2. Caveat and drawbacks
> * Users will have to update their {{checkstyle.xml}} file because of
> incompatible changes introduced in {{8.24}}.
> * Otherwise the warning might confuse users.
> * Once the method call to {{Checker::setClassLoader}} is removed,
> {{checkstyle}} versions prior to 8.26 (Source:
> [https://checkstyle.org/releasenotes.html#Release_8.26]) cannot be used
> anymore (Source:
> [https://github.com/checkstyle/checkstyle/commit/145160f5e21b80c27dc93a1904fe33b9afd4f212]
> and [https://github.com/checkstyle/checkstyle/issues/3773]). But this issue
> is not about removing this method call any time soon.
> => it will probably work fine for any 8.x version because this method existed
> for a deprecated check only.
> h2. Related issues
> *
> [MCHECKSTYLE-381|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-381]]
> The mentioned previous commit.
> *
> [MCHECKSTYLE-384|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-384]]:
> Once this maven-checkstyle-plugin updates to checkstyle > 8.24, the default
> installation for users will break existing installations unless users use
> this method of downgrading their checkstyle version:
> [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html.]
>
> * Also track [https://github.com/checkstyle/checkstyle/issues/7190.] This
> will tell when the checkstyle team removes that method.
> h2. Documentation
> * maven-checkstyle-plugin is compatible with all checkstyle versions by
> functionality.
> * maven-checkstyle-plugin >= 3.1.2 will complain if checkstyle < 8.29 is
> being used, which is the default (since it requires checkstyle 8.19).
> * If we are ever going to remove the method {{Checker::setClassLoader}},
> this means that earlier versions than checkstyle 8.26 are not supported. They
> will probably work just fine, but the method call became a 'real' no-op in
> 8.26. Might be worth documentation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MCHECKSTYLE-387) Deprecate method setUpCheckstyleClassloader in 3.1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MCHECKSTYLE-387.
--
Fix Version/s: 3.1.2
Assignee: Benjamin Marwell
Resolution: Fixed
> Deprecate method setUpCheckstyleClassloader in 3.1.2
>
>
> Key: MCHECKSTYLE-387
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-387
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 3.1.1
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.1.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Current situation
> In 3.1.1, the PR [https://github.com/apache/maven-checkstyle-plugin/pull/18]
> added a {{try-catch}}-block to the to-be-removed method call
> {{Checker::setClassLoader}}.
> Since users should be encuraged to upgrade and maven-plugin-developers should
> know that this method should be removed some time, a warning is to be issued
> if the method call was successful (i.e. when not entering the catch block).
> h2. Caveat and drawbacks
> * Users will have to update their {{checkstyle.xml}} file because of
> incompatible changes introduced in {{8.24}}.
> * Otherwise the warning might confuse users.
> * Once the method call to {{Checker::setClassLoader}} is removed,
> {{checkstyle}} versions prior to 8.26 (Source:
> [https://checkstyle.org/releasenotes.html#Release_8.26]) cannot be used
> anymore (Source:
> [https://github.com/checkstyle/checkstyle/commit/145160f5e21b80c27dc93a1904fe33b9afd4f212]
> and [https://github.com/checkstyle/checkstyle/issues/3773]). But this issue
> is not about removing this method call any time soon.
> => it will probably work fine for any 8.x version because this method existed
> for a deprecated check only.
> h2. Related issues
> *
> [MCHECKSTYLE-381|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-381]]
> The mentioned previous commit.
> *
> [MCHECKSTYLE-384|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-384]]:
> Once this maven-checkstyle-plugin updates to checkstyle > 8.24, the default
> installation for users will break existing installations unless users use
> this method of downgrading their checkstyle version:
> [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html.]
>
> * Also track [https://github.com/checkstyle/checkstyle/issues/7190.] This
> will tell when the checkstyle team removes that method.
> h2. Documentation
> * maven-checkstyle-plugin is compatible with all checkstyle versions by
> functionality.
> * maven-checkstyle-plugin >= 3.1.2 will complain if checkstyle < 8.29 is
> being used, which is the default (since it requires checkstyle 8.19).
> * If we are ever going to remove the method {{Checker::setClassLoader}},
> this means that earlier versions than checkstyle 8.26 are not supported. They
> will probably work just fine, but the method call became a 'real' no-op in
> 8.26. Might be worth documentation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-checkstyle-plugin] bmarwell commented on pull request #28: [MCHECKSTYLE-387] emit a warning when using an old version of checkstyle
bmarwell commented on pull request #28: URL: https://github.com/apache/maven-checkstyle-plugin/pull/28#issuecomment-739970299 Merged via https://github.com/apache/maven-checkstyle-plugin/commit/7688eb9a621ff4932710339988fcd29e9c00d767 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
[GitHub] [maven-checkstyle-plugin] bmarwell closed pull request #28: [MCHECKSTYLE-387] emit a warning when using an old version of checkstyle
bmarwell closed pull request #28: URL: https://github.com/apache/maven-checkstyle-plugin/pull/28 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
[GitHub] [maven-checkstyle-plugin] bmarwell commented on pull request #28: [MCHECKSTYLE-387] emit a warning when using an old version of checkstyle
bmarwell commented on pull request #28: URL: https://github.com/apache/maven-checkstyle-plugin/pull/28#issuecomment-739969289 CI succeeded after rebase: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-checkstyle-plugin/job/MCHECKSTYLE-387/ 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
[jira] [Commented] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
[
https://issues.apache.org/jira/browse/MINSTALL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245225#comment-17245225
]
Ben Tatham commented on MINSTALL-169:
-
I took a stab at fixing this, but it is very complicated (and has separate code
for install and deploy cases).
I found that an easier workaround for a custom lifecycle with a custom plugin
is to set the packaging during a mojo itself, which then tricks the
install/deploy plugins to do the right thing:
For those searching later:
```
@Parameter(defaultValue = "${project}", readonly = true)
private MavenProject project;
...
project.setPackaging("pom")
```
Note that you should _not_ also set main artifact (`project.setArtifact`) to
the pom file, because this will cause the install/deploy mojos to
install/deploy the pom twice (which will cause problems on deploy with
non-snapshot versions (depending on your repo manager settings).
> Handle non-pom packaging with only a pom artifact
> -
>
> Key: MINSTALL-169
> URL: https://issues.apache.org/jira/browse/MINSTALL-169
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Reporter: Ben Tatham
>Priority: Major
>
> Note: this story affects maven-install-plugin and maven-deploy-plugin equally.
> Currently, in
> [DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82],
> if a project does not have literally "pom" as packaging, then if there are
> no other artifacts, install:install fails (as does deploy:deploy) with
> {code:java}
> NoFileAssignedException: The packaging plugin for this project did not assign
> a main file to the project but it has attachments. Change packaging to
> 'pom'.{code}
>
> However, for some custom lifecycles (and therefore different packaging
> types), we might want to be able to have a lifecycle that just
> installs/deploys the pom file alone with no additional artifacts.
> Further, if a plugin explicitly sets the main artifact (via
> MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself
> (which I tried as a work around), then install and deploy perform the same
> action twice (which would then break deploy, if the maven central repo blocks
> duplicate pushes, as we have setup in our Nexus environment for release
> (non-snapshot) artifacts)
> Our use case might be weird, but we want to be able to use maven to lookup
> version updates for it, even though the artifacts themselves are not in maven
> (our use case is docker, helm charts, etc).
> I see this as a relatively simple fix in the above mentioned class, and am
> happy to contribute a pull request for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
[
https://issues.apache.org/jira/browse/MINSTALL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245225#comment-17245225
]
Ben Tatham edited comment on MINSTALL-169 at 12/7/20, 2:01 PM:
---
I took a stab at fixing this, but it is very complicated (and has separate code
for install and deploy cases).
I found that an easier workaround for a custom lifecycle with a custom plugin
is to set the packaging during a mojo itself, which then tricks the
install/deploy plugins to do the right thing:
For those searching later:
{code:java}
@Parameter(defaultValue = "${project}", readonly = true)
private MavenProject project;
...
project.setPackaging("pom")
...
{code}
Note that you should _not_ also set main artifact (`project.setArtifact`) to
the pom file, because this will cause the install/deploy mojos to
install/deploy the pom twice (which will cause problems on deploy with
non-snapshot versions (depending on your repo manager settings).
was (Author: bentat...@nanometrics.ca):
I took a stab at fixing this, but it is very complicated (and has separate code
for install and deploy cases).
I found that an easier workaround for a custom lifecycle with a custom plugin
is to set the packaging during a mojo itself, which then tricks the
install/deploy plugins to do the right thing:
For those searching later:
```
@Parameter(defaultValue = "${project}", readonly = true)
private MavenProject project;
...
project.setPackaging("pom")
```
Note that you should _not_ also set main artifact (`project.setArtifact`) to
the pom file, because this will cause the install/deploy mojos to
install/deploy the pom twice (which will cause problems on deploy with
non-snapshot versions (depending on your repo manager settings).
> Handle non-pom packaging with only a pom artifact
> -
>
> Key: MINSTALL-169
> URL: https://issues.apache.org/jira/browse/MINSTALL-169
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Reporter: Ben Tatham
>Priority: Major
>
> Note: this story affects maven-install-plugin and maven-deploy-plugin equally.
> Currently, in
> [DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82],
> if a project does not have literally "pom" as packaging, then if there are
> no other artifacts, install:install fails (as does deploy:deploy) with
> {code:java}
> NoFileAssignedException: The packaging plugin for this project did not assign
> a main file to the project but it has attachments. Change packaging to
> 'pom'.{code}
>
> However, for some custom lifecycles (and therefore different packaging
> types), we might want to be able to have a lifecycle that just
> installs/deploys the pom file alone with no additional artifacts.
> Further, if a plugin explicitly sets the main artifact (via
> MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself
> (which I tried as a work around), then install and deploy perform the same
> action twice (which would then break deploy, if the maven central repo blocks
> duplicate pushes, as we have setup in our Nexus environment for release
> (non-snapshot) artifacts)
> Our use case might be weird, but we want to be able to use maven to lookup
> version updates for it, even though the artifacts themselves are not in maven
> (our use case is docker, helm charts, etc).
> I see this as a relatively simple fix in the above mentioned class, and am
> happy to contribute a pull request for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-assembly-plugin] bmarwell commented on pull request #38: MASSEMBLY-945 - speed improvements
bmarwell commented on pull request #38: URL: https://github.com/apache/maven-assembly-plugin/pull/38#issuecomment-739924424 > have you measured the improvements? if so, what are the numbers? Null-length arrays are known to be faster since at least 2013 iirc. * https://shipilev.net/blog/2016/arrays-wisdom-ancients/ (updated 2016) * https://stackoverflow.com/a/29444594/1549977 (from 2013) In my opinion measurements are not needed here because of this. 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
[GitHub] [maven-assembly-plugin] elharo commented on pull request #38: MASSEMBLY-945 - speed improvements
elharo commented on pull request #38: URL: https://github.com/apache/maven-assembly-plugin/pull/38#issuecomment-739920167 have you measured the improvements? if so, what are the numbers? 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
[GitHub] [maven-assembly-plugin] elharo merged pull request #34: declare dependencies
elharo merged pull request #34: URL: https://github.com/apache/maven-assembly-plugin/pull/34 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
[GitHub] [maven-jlink-plugin] sparsick commented on pull request #23: [MJLINK-57] Migrate to slf4j
sparsick commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-739917323 @slachiewicz Maven 3.0 as minimum came from this [discussion](https://github.com/apache/maven-jlink-plugin/pull/9/files/fe528b2c2e3b003c146e4e322e3bcd8bcba05b77#r513751225) in another PR. 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
[GitHub] [maven-surefire] Tibor17 commented on pull request #327: [SUREFIRE-1865] ChecksumCalculator getSha1 does not compute checksums correctly.
Tibor17 commented on pull request #327: URL: https://github.com/apache/maven-surefire/pull/327#issuecomment-739907654 @gianm Pls add your test `ChecksumCalculatorTest` to the [JUnit4SuiteTest](https://github.com/apache/maven-surefire/blob/c76ae87d3234bc27daea1cd7a175cdc4fa6608a4/maven-surefire-common/src/test/java/org/apache/maven/surefire/JUnit4SuiteTest.java). 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
[GitHub] [maven-scm] cquoss opened a new pull request #109: SCM-947
cquoss opened a new pull request #109: URL: https://github.com/apache/maven-scm/pull/109 Pull request for SCM-947. Make all parameter of changelog request available in changelog mojo. 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
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #19: [MJLINK-58] Remove usage of plexus utils, use commons lang or native …
sparsick commented on a change in pull request #19: URL: https://github.com/apache/maven-jlink-plugin/pull/19#discussion_r537373774 ## File path: pom.xml ## @@ -109,6 +109,11 @@ commons-lang3 3.6 + Review comment: Oh, I see. Thank you for explanation. Then it is fine for me. 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
[GitHub] [maven-jlink-plugin] slachiewicz commented on pull request #23: [MJLINK-57] Migrate to slf4j
slachiewicz commented on pull request #23: URL: https://github.com/apache/maven-jlink-plugin/pull/23#issuecomment-739809104 To be on safe side, we may also bump min Maven to 3.1.1 (as another ticket) 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
[GitHub] [maven-jlink-plugin] bmarwell commented on a change in pull request #19: [MJLINK-58] Remove usage of plexus utils, use commons lang or native …
bmarwell commented on a change in pull request #19: URL: https://github.com/apache/maven-jlink-plugin/pull/19#discussion_r537365831 ## File path: pom.xml ## @@ -109,6 +109,11 @@ commons-lang3 3.6 + Review comment: On slack there was a discussion that commons could either be shaded or removed altogether for some methods. Currently it is just being used for a few `StringUtils.isNotEmpty( output )` checks. If feasible, the whole dependencies could be replaced by other means. 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
[jira] [Updated] (MEJB-130) Plugin does not accept ejbVersion 4.0
[ https://issues.apache.org/jira/browse/MEJB-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Zygielo updated MEJB-130: --- Description: EJB being now with Jakarta is released with new spec under the version 4.0 ([https://repo.maven.apache.org/maven2/jakarta/ejb/jakarta.ejb-api/4.0.0/], [https://projects.eclipse.org/projects/ee4j.ejb/releases/4.0]) However plugin is not prepared to deal with that. Failing IT presented as first commit in https://github.com/apache/maven-ejb-plugin/pull/11. was: EJB being now with Jakarta is released new spec under the version 4.0 ([https://repo.maven.apache.org/maven2/jakarta/ejb/jakarta.ejb-api/4.0.0/], [https://projects.eclipse.org/projects/ee4j.ejb/releases/4.0]) However plugin is not prepared to deal with that. Failing IT presented as first commit in https://github.com/apache/maven-ejb-plugin/pull/11. > Plugin does not accept ejbVersion 4.0 > - > > Key: MEJB-130 > URL: https://issues.apache.org/jira/browse/MEJB-130 > Project: Maven EJB Plugin > Issue Type: Bug >Reporter: Piotr Zygielo >Priority: Major > > EJB being now with Jakarta is released with new spec under the version 4.0 > ([https://repo.maven.apache.org/maven2/jakarta/ejb/jakarta.ejb-api/4.0.0/], > [https://projects.eclipse.org/projects/ee4j.ejb/releases/4.0]) > However plugin is not prepared to deal with that. > Failing IT presented as first commit in > https://github.com/apache/maven-ejb-plugin/pull/11. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ejb-plugin] pzygielo commented on pull request #11: [MEJB-130] Accept ejbVersion 4.x
pzygielo commented on pull request #11: URL: https://github.com/apache/maven-ejb-plugin/pull/11#issuecomment-739791557 May I ask for review, please? 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
[jira] [Created] (MEJB-130) Plugin does not accept ejbVersion 4.0
Piotr Zygielo created MEJB-130: -- Summary: Plugin does not accept ejbVersion 4.0 Key: MEJB-130 URL: https://issues.apache.org/jira/browse/MEJB-130 Project: Maven EJB Plugin Issue Type: Bug Reporter: Piotr Zygielo EJB being now with Jakarta is released new spec under the version 4.0 ([https://repo.maven.apache.org/maven2/jakarta/ejb/jakarta.ejb-api/4.0.0/], [https://projects.eclipse.org/projects/ee4j.ejb/releases/4.0]) However plugin is not prepared to deal with that. Failing IT presented as first commit in https://github.com/apache/maven-ejb-plugin/pull/11. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ejb-plugin] pzygielo opened a new pull request #11: Accept ejbVersion 4.x
pzygielo opened a new pull request #11: URL: https://github.com/apache/maven-ejb-plugin/pull/11 - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MEJB) filedfor the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, withoutpulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MEJB-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MEJB-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of thecommit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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
[GitHub] [maven-release] michael-o commented on a change in pull request #62: [MRELEASE-899] Feature/lineseparator
michael-o commented on a change in pull request #62:
URL: https://github.com/apache/maven-release/pull/62#discussion_r537335786
##
File path:
maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
##
@@ -387,4 +403,27 @@ protected void prepareRelease( boolean generateReleasePoms
)
}
}
+private String resolveLineSeparator()
+{
+if ( lineSeparator == null )
+{
+return System.getProperty( "line.separator" );
+}
+
+switch ( lineSeparator )
Review comment:
I prefer not to have an option at all: Same as source always, implicit.
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
[GitHub] [maven-release] K-J-Henken commented on a change in pull request #62: [MRELEASE-899] Feature/lineseparator
K-J-Henken commented on a change in pull request #62:
URL: https://github.com/apache/maven-release/pull/62#discussion_r537334647
##
File path:
maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
##
@@ -387,4 +403,27 @@ protected void prepareRelease( boolean generateReleasePoms
)
}
}
+private String resolveLineSeparator()
+{
+if ( lineSeparator == null )
+{
+return System.getProperty( "line.separator" );
+}
+
+switch ( lineSeparator )
Review comment:
Hey, i think the "same as source" option is a good idea in general but
not as the default option because it would change the current behavior.
Maybe I will implement it soon, but not in this request.
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
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245047#comment-17245047
]
Michael Osipov commented on WAGON-575:
--
I am not really happy with the PR:
* It ist not configurable
* It solves a symptom on the wrong spot.
* It may retry even if th request has not been retried. Consider your
credentials are incorrect and it will try 5 times, your account gets locked.
* Wagon also tracks progress. If those counters aren't reset it will fail with
another exception. Don't know whether this applies here.
I would prefer to solve it by HttpClient means if this is possible. Moreover,
if the failure is in flight the caller must be able to recover from this,
meanning that Wagon receives an output stream and it needs to track where it
failed to resule download. You cannot rewind the output stream you have
received. If I am wrong, please explain.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at
[GitHub] [maven-filtering] michael-o commented on a change in pull request #4: [MRESOURCES-250] - Add ability to flatten folder structure into target directory when copying resources
michael-o commented on a change in pull request #4:
URL: https://github.com/apache/maven-filtering/pull/4#discussion_r537310677
##
File path:
src/test/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFilteringTest.java
##
@@ -489,6 +489,88 @@ public void testIncludeOneFileAndDirectory()
}
+public void testFlattenDirectoryStructure()
+throws Exception
+{
+File baseDir = new File( "c:\\foo\\bar" );
Review comment:
IS this portable?
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
[GitHub] [maven-jlink-plugin] sparsick commented on a change in pull request #19: [MJLINK-58] Remove usage of plexus utils, use commons lang or native …
sparsick commented on a change in pull request #19: URL: https://github.com/apache/maven-jlink-plugin/pull/19#discussion_r537309765 ## File path: pom.xml ## @@ -109,6 +109,11 @@ commons-lang3 3.6 + Review comment: @bmarwell What do you mean with "drop commons altogether"? Do you want to remove them from the pom? If so, I wouldn't recommend it because they are used in the plugin and therefore, they should be explicitly named in the pom. 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
[GitHub] [maven-jlink-plugin] bmarwell commented on a change in pull request #21: [MJLINK-52] Add classifier support
bmarwell commented on a change in pull request #21:
URL: https://github.com/apache/maven-jlink-plugin/pull/21#discussion_r537306217
##
File path: src/main/java/org/apache/maven/plugins/jlink/JLinkMojo.java
##
@@ -428,11 +437,12 @@ private JLinkExecutor getExecutor()
return getJlinkExecutor();
}
-private boolean projectHasAlreadySetAnArtifact()
+private boolean projectHasAlreadySetAnArtifact( File
createZipArchiveFromImage )
{
-if ( getProject().getArtifact().getFile() != null )
+File projectArtifact = getProject().getArtifact().getFile();
+if ( projectArtifact != null && projectArtifact.isFile() )
{
-return getProject().getArtifact().getFile().isFile();
+return projectArtifact.getName().equals(
createZipArchiveFromImage.getName() );
Review comment:
@elharo
1. I changed it back to a `@Nullable` File.
2. I think I should iterate the Set `getProject().getArtifacts()` here, if
I am not mistaken? There can be more than one artifact if I read the methods
correctly.
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
