[GitHub] [maven-scm] feliperoos commented on issue #31: SCM-706 finer-grained handling of file rename status for gitexe provider...
feliperoos commented on issue #31: SCM-706 finer-grained handling of file
rename status for gitexe provider...
URL: https://github.com/apache/maven-scm/pull/31#issuecomment-471092108
+1, unable to run with 2.5.3 even with release:prepare.
Command I'm using is
`mvn release:clean release:prepare release:perform -Prelease
`
Pom has a very basic profile to state the plugin
```
release
false
org.apache.maven.plugins
maven-release-plugin
2.5.3
v@{project.version}
```
Building on Jenkins, I get
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on
project lib3cp-java: Cannot prepare the release because you have local
modifications :
[ERROR] [release-pom.xml:deleted]
```
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-enforcer] rfscholte commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
rfscholte commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-471019062 I had me doubts about this feature, but the commmunity was asking for it and it didn't really do any harm, but it is kind of un-Maven-ish. Being able to enforce rules from commandline means you cannot configure them. Maybe this feature should be pushed to a higher level (maven-core) to solve this for plugins in general. 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] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788069#comment-16788069
]
Robert Scholte commented on MJAVADOC-584:
-
{quote}... how many sub packages does the expression "*.util.*" includes ? The
documentation suggest only one.{quote}
Did you try it? Looking at the expressions (at first not the documentation)
what would make sense?
I'm challenging you a bit here, my experience is that people are bad readers
and only "recognize" expressions. Once we agree we can adjust documentation
and/or expression resolution.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787875#comment-16787875
]
Thomas Mortagne commented on MJAVADOC-584:
--
I'm not sure we understand each other here. I'm not discussing what is the best
syntax, my only concern is finding how I can get my exclude working after
upgrading to 3.1.0.
One thing which is written in the current documentation ("any other wildcard
must match exactly one folder") seems to suggest that there is no way to
exclude something located in all sub folders of a package "internal". Is that
true ? Is the document wrong/misleading ?
bq. One thing that came up: is *.util allowed and what does it mean? It should
have a different meaning compared to *.util.*, right?
Sure but again what may concern is how many sub packages does the expression
"*.util.*" includes ? The documentation suggest only one.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-enforcer] destebanm edited a comment on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
destebanm edited a comment on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-470917137 Hi! I have built the snapshot (as @Mazorius suggested) and the CLI is working but I don´t know how to use it, hehehe. I am able to run commands like that: `mvn enforcer:enforce -Drules=alwaysFail` but I would like to run this with the CLI ``` x.y:logger:(,10.93) x.y:soap-utils:(,10.93) x.y:correlation-id:(,10.93) ``` Is there any kind of documentation about how to use the CLI?? Thanks!! 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-enforcer] destebanm commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli
destebanm commented on issue #36: [MENFORCER-142] documentation - add example for checking rules via cli URL: https://github.com/apache/maven-enforcer/pull/36#issuecomment-470917137 Hi! I have built the snapshot and the CLI is working but I don´t know how to use it. I am able to run commands like that: `mvn enforcer:enforce -Drules=alwaysFail` but I would like to run this with the CLI ``` x.y:logger:(,10.93) x.y:soap-utils:(,10.93) x.y:correlation-id:(,10.93) ``` Is there any kind of documentation about how to use the CLI?? Thanks!! 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-jarsigner-plugin] bdt-stru edited a comment on issue #1: Implement maxTries parameter
bdt-stru edited a comment on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470883852 @lasselindqvist thanks for sharing your changes. that made it easier for me to also add the retryDelay parameter. https://github.com/apache/maven-jarsigner-plugin/pull/3 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-jarsigner-plugin] bdt-stru edited a comment on issue #1: Implement maxTries parameter
bdt-stru edited a comment on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470883852 @lasselindqvist thanks for sharing you changes. that made it easier for me to also add the retryDelay parameter. https://github.com/apache/maven-jarsigner-plugin/pull/3 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-jarsigner-plugin] bdt-stru edited a comment on issue #1: Implement maxTries parameter
bdt-stru edited a comment on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470883852 https://github.com/apache/maven-jarsigner-plugin/pull/3 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-jarsigner-plugin] bdt-stru opened a new pull request #3: adds maxTries and retryDelay
bdt-stru opened a new pull request #3: adds maxTries and retryDelay URL: https://github.com/apache/maven-jarsigner-plugin/pull/3 includes improvements to previous pull request https://github.com/apache/maven-jarsigner-plugin/pull/1 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] [Comment Edited] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787775#comment-16787775
]
Robert Scholte edited comment on MJAVADOC-584 at 3/8/19 10:50 AM:
--
Having a closer look at the example page, trying to understand the idea behind
the exclude expressions:"
* com.mycompany.myapp.package1.\* means exclude every subpackage of
{{com.mycompany.myapp.package1}}, but this package itself is included.
* com.mycompany.myapp.package2 means exclude every package starting with
{{com.mycompany.myapp.package2}}
* \*.util.\* means exclude any package that contains {{util}}
Do you see the difference between the meaning of an expression ending with
{{.\*}} depending if it starts with {{\*.}}? IMHO this is inconsistent. One
thing that came up: is {{\*.util}} allowed and what does it mean? It should
have a different meaning compared to {{\*.util.\*}}, right?
was (Author: rfscholte):
Having a closer look at the example page, trying to understand the idea behind
the exclude expressions:"
* com.mycompany.myapp.package1.\* means exclude every subpackage of
{{com.mycompany.myapp.package1}}, but this package itself is included.
* com.mycompany.myapp.package2 means exclude every package starting with
{{com.mycompany.myapp.package2}}
* \*.util.\* means exclude any package that contains {{util}}
Do you see the difference between the meaning of an expression ending with
{{.\*}} depending if it starts with {{\*.}}? IMHO this is inconsistent. One
thing that came up: is {{\*.util }} allowed and what does it mean? It should
have a different meaning compared to {{\*.util.\*}}, right?
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787775#comment-16787775
]
Robert Scholte commented on MJAVADOC-584:
-
Having a closer look at the example page, trying to understand the idea behind
the exclude expressions:"
* com.mycompany.myapp.package1.\* means exclude every subpackage of
{{com.mycompany.myapp.package1}}, but this package itself is included.
* com.mycompany.myapp.package2 means exclude every package starting with
{{com.mycompany.myapp.package2}}
* \*.util.\* means exclude any package that contains {{util}}
Do you see the difference between the meaning of an expression ending with
{{.\*}} depending if it starts with {{\*.}}? IMHO this is inconsistent. One
thing that came up: is {{\*.util }} allowed and what does it mean? It should
have a different meaning compared to {{\*.util.\*}}, right?
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-jarsigner-plugin] bdt-stru commented on issue #1: Implement maxTries parameter
bdt-stru commented on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470883852 Implement retryDelay parameter https://github.com/lasselindqvist/maven-jarsigner-plugin/pull/1 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] [Resolved] (MSCRIPTING-1) Allow scripting in files
[ https://issues.apache.org/jira/browse/MSCRIPTING-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrico Olivelli resolved MSCRIPTING-1. -- Resolution: Fixed Committed ! thank you [~popovr] I guess you will be the first user of this plugin, any contribution will be very appreciated Thank you very much > Allow scripting in files > > > Key: MSCRIPTING-1 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-1 > Project: Maven Scripting > Issue Type: Improvement >Reporter: Rusi Popov >Assignee: Enrico Olivelli >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Allow providing the scripts in external files. Use the engine name to > override the engine if the file name extension does not refer/decode to a > valid engine name or not define any at all. > For extension-to-engine mapping use javax.script.ScriptEngineManager as of > JSR-223 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSCRIPTING-1) Allow scripting in files
[ https://issues.apache.org/jira/browse/MSCRIPTING-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787718#comment-16787718 ] Enrico Olivelli commented on MSCRIPTING-1: -- [~popovr] FYI I have deployed a snapstop to the Public Apache Snapshot Repository, so you can try it by your self before an official release > Allow scripting in files > > > Key: MSCRIPTING-1 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-1 > Project: Maven Scripting > Issue Type: Improvement >Reporter: Rusi Popov >Assignee: Enrico Olivelli >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Allow providing the scripts in external files. Use the engine name to > override the engine if the file name extension does not refer/decode to a > valid engine name or not define any at all. > For extension-to-engine mapping use javax.script.ScriptEngineManager as of > JSR-223 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSCRIPTING-1) Allow scripting in files
[ https://issues.apache.org/jira/browse/MSCRIPTING-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated MSCRIPTING-1: Labels: pull-request-available (was: ) > Allow scripting in files > > > Key: MSCRIPTING-1 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-1 > Project: Maven Scripting > Issue Type: Improvement >Reporter: Rusi Popov >Assignee: Enrico Olivelli >Priority: Major > Labels: pull-request-available > > Allow providing the scripts in external files. Use the engine name to > override the engine if the file name extension does not refer/decode to a > valid engine name or not define any at all. > For extension-to-engine mapping use javax.script.ScriptEngineManager as of > JSR-223 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-scripting-plugin] eolivelli closed pull request #3: [MSCRIPTING-1] Allow scripting in files
eolivelli closed pull request #3: [MSCRIPTING-1] Allow scripting in files URL: https://github.com/apache/maven-scripting-plugin/pull/3 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-scripting-plugin] eolivelli commented on issue #3: [MSCRIPTING-1] Allow scripting in files
eolivelli commented on issue #3: [MSCRIPTING-1] Allow scripting in files URL: https://github.com/apache/maven-scripting-plugin/pull/3#issuecomment-470864006 @rpopov committed as b20e1c3dc647ddc3e522f286cc6252321509dd96 I will setup for a first release You can follow up Maven dev@ mailing list about the release cc @rfscholte 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] (MRESOLVER-67) The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11
[
https://issues.apache.org/jira/browse/MRESOLVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787705#comment-16787705
]
Hudson commented on MRESOLVER-67:
-
Build succeeded in Jenkins: Maven TLP » maven-resolver » master #3
See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/3/
> The Maven resolver API 1.3.2 JAR deployed on Maven central has been built
> with Java 11
> --
>
> Key: MRESOLVER-67
> URL: https://issues.apache.org/jira/browse/MRESOLVER-67
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.3.2
>Reporter: Thomas Mortagne
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 1.3.3
>
>
> bq. Build-Jdk: 11.0.1
> Makes it unusable in Java 8. Example of problem:
> {quote}
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy(AbstractTransporter.java:254)
> {quote}
> See
> https://mail-archives.apache.org/mod_mbox/maven-dev/201903.mbox/%3c64fbf6c9-0868-5da9-b42a-77500458b...@apache.org%3e
> for more details.
> I see 1.3.2 is not marked as released on Jira. Maybe it was not even supposed
> to be on Maven central in the first place ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787693#comment-16787693
]
Thomas Mortagne commented on MJAVADOC-584:
--
bq. I don't mind adjusting the evaluation, as long as it makes sense and that
you can control exclusion of any package.
I'm fine changing my configuration, I just want to make sure what I think is a
very common use case is still taken into account: exclude everything which is
part of a package containing an "internal" element in the path.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRESOLVER-67) The Maven resolver API 1.3.2 JAR deployed on Maven central has been built with Java 11
[
https://issues.apache.org/jira/browse/MRESOLVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRESOLVER-67.
---
Resolution: Fixed
Assignee: Robert Scholte
Fixed in
[fff273068617c0e133fb62a70bc71e8968db199a|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=fff273068617c0e133fb62a70bc71e8968db199a]
We might consider fixing this as a MRJAR + maven.compiler.release in the
future, but for now this is sufficient.
> The Maven resolver API 1.3.2 JAR deployed on Maven central has been built
> with Java 11
> --
>
> Key: MRESOLVER-67
> URL: https://issues.apache.org/jira/browse/MRESOLVER-67
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.3.2
>Reporter: Thomas Mortagne
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 1.3.3
>
>
> bq. Build-Jdk: 11.0.1
> Makes it unusable in Java 8. Example of problem:
> {quote}
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
> at
> org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy(AbstractTransporter.java:254)
> {quote}
> See
> https://mail-archives.apache.org/mod_mbox/maven-dev/201903.mbox/%3c64fbf6c9-0868-5da9-b42a-77500458b...@apache.org%3e
> for more details.
> I see 1.3.2 is not marked as released on Jira. Maybe it was not even supposed
> to be on Maven central in the first place ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1647) When using junit5, delay loading testClass and use myown classLoader
[
https://issues.apache.org/jira/browse/SUREFIRE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787677#comment-16787677
]
Shengli Cao commented on SUREFIRE-1647:
---
https://github.com/apache/maven-surefire/pull/222
> When using junit5, delay loading testClass and use myown classLoader
> -
>
> Key: SUREFIRE-1647
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1647
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1, 3.0.0-M2
>Reporter: Shengli Cao
>Priority: Critical
>
> org.junit.platform.engine.discovery.DiscoverySelectors#selectClass(java.lang.String)
> and
> org.junit.platform.engine.discovery.DiscoverySelectors#selectClass(java.lang.Class)
> are different.
> If you use selectClass(java.lang.String) , it will load class by
> org.junit.platform.engine.discovery.ClassSelector#getJavaClass. The code is
> as follow:
> {{public Class getJavaClass() \{ if (this.javaClass == null) {
> this.javaClass = ReflectionUtils.loadClass(this.className).orElseThrow( () ->
> new PreconditionViolationException("Could not load class with name: " +
> this.className)); } return this.javaClass; } }}
> And the classloader fetched by
> {{Thread.currentThread().getContextClassLoader()}} will load this class. In
> this way, it will delay loading class
> But selectClass(java.lang.Class) will get class directly.
>
> In my situation, I need load Class by another classLoader so i need to delay
> loading testClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-jarsigner-plugin] bdt-stru commented on issue #1: Implement maxTries parameter
bdt-stru commented on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470851984 i do need this enhancement because tsa timeouts on me quite often. the retrydelay parameter is definitly mandatory too with default value of 0. someone will probably need it. turns out im the guy who also needs the delay. tsa.starfieldtech.com currently starts timeouting after many requests. having dozens of jars to sign it stops long before it is even close to finishing. 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] [Created] (SUREFIRE-1647) When using junit5, delay loading testClass and use myown classLoader
Shengli Cao created SUREFIRE-1647:
-
Summary: When using junit5, delay loading testClass and use myown
classLoader
Key: SUREFIRE-1647
URL: https://issues.apache.org/jira/browse/SUREFIRE-1647
Project: Maven Surefire
Issue Type: Improvement
Components: JUnit 5.x support
Affects Versions: 3.0.0-M2, 2.22.1
Reporter: Shengli Cao
org.junit.platform.engine.discovery.DiscoverySelectors#selectClass(java.lang.String)
and
org.junit.platform.engine.discovery.DiscoverySelectors#selectClass(java.lang.Class)
are different.
If you use selectClass(java.lang.String) , it will load class by
org.junit.platform.engine.discovery.ClassSelector#getJavaClass. The code is as
follow:
{{public Class getJavaClass() \{ if (this.javaClass == null) {
this.javaClass = ReflectionUtils.loadClass(this.className).orElseThrow( () ->
new PreconditionViolationException("Could not load class with name: " +
this.className)); } return this.javaClass; } }}
And the classloader fetched by
{{Thread.currentThread().getContextClassLoader()}} will load this class. In
this way, it will delay loading class
But selectClass(java.lang.Class) will get class directly.
In my situation, I need load Class by another classLoader so i need to delay
loading testClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-jarsigner-plugin] Xyrio removed a comment on issue #1: Implement maxTries parameter
Xyrio removed a comment on issue #1: Implement maxTries parameter URL: https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-470472426 i do need this enhancement because tsa timeouts on me quite often. the retrydelay parameter is definitly mandatory too with default value of 0. someone will probably need it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
