[jira] [Commented] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732733#comment-16732733
]
Hervé Boutemy commented on SCM-777:
---
[~michael-o] I don't remember anything on that easily: do you need me to dig
more in details this WE? or are you confident enough?
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.2
>
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rpopov commented on a change in pull request #1: Allow scripting in files
rpopov commented on a change in pull request #1: Allow scripting in files URL: https://github.com/apache/maven-scripting-plugin/pull/1#discussion_r244915726 ## File path: pom.xml ## @@ -92,13 +93,6 @@ under the License. provided - - Review comment: Btw, there is no previous version of the plugin published on Maven Central, its version is 3.0.0-SNAPSHOT which assumes interface changes, that are not finalized. Now is the time to avoid using groovy. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] rpopov commented on a change in pull request #1: Allow scripting in files
rpopov commented on a change in pull request #1: Allow scripting in files URL: https://github.com/apache/maven-scripting-plugin/pull/1#discussion_r244914478 ## File path: pom.xml ## @@ -92,13 +93,6 @@ under the License. provided - - Review comment: I think that the groovy script interpreter is not necessary for the compilation and running of the plugin/ Instead it imposes the download of a significant graph of dependencies. The plugin allows using other than groovy languages and should treat them equally. The groovy sccript interpreter is moved to the test poms. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-561:
--
Priority: Critical (was: Major)
Increased priority due to the fact that there are no known workarounds and
linking to the JDK is a very common use-case.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Critical
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-561:
--
Description:
1. Open testcase
2. {{mvn javadoc:jar}}
3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
It doesn't look like one can link to the JDK as of version 11 because the URL
structure changed since Java 10.
Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
Java 11:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
discussion. If any syntax change is required in the pom, please consider
updating
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
accordingly.
was:
1. Open testcase
2. {{mvn javadoc:jar}}
3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
It doesn't look like one can link to the JDK as of version 11 because the URL
structure changed since Java 10.
Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
discussion. If any syntax change is required in the pom, please consider
updating
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
accordingly.
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Number.html
> Java 11:
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Number.html
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-561) Not possible to link to JDK classes since Java 11
[
https://issues.apache.org/jira/browse/MJAVADOC-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-561:
--
Description:
1. Open testcase
2. {{mvn javadoc:jar}}
3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
It doesn't look like one can link to the JDK as of version 11 because the URL
structure changed since Java 10.
Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
discussion. If any syntax change is required in the pom, please consider
updating
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
accordingly.
was:
1. Open testcase
2. {{mvn javadoc:jar}}
3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
It doesn't look like one can link to the JDK as of version 9 because the URL
changed slightly to accommodate Java modules.
Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
discussion. If any syntax change is required in the pom, please consider
updating
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
accordingly.
Summary: Not possible to link to JDK classes since Java 11 (was: Not
possible to link to JDK classes since Java 9)
> Not possible to link to JDK classes since Java 11
> -
>
> Key: MJAVADOC-561
> URL: https://issues.apache.org/jira/browse/MJAVADOC-561
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> 1. Open testcase
> 2. {{mvn javadoc:jar}}
> 3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
> It doesn't look like one can link to the JDK as of version 11 because the URL
> structure changed since Java 10.
> Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
> discussion. If any syntax change is required in the pom, please consider
> updating
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-561) Not possible to link to JDK classes since Java 9
Gili created MJAVADOC-561:
-
Summary: Not possible to link to JDK classes since Java 9
Key: MJAVADOC-561
URL: https://issues.apache.org/jira/browse/MJAVADOC-561
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.1.0
Reporter: Gili
Attachments: testcase.zip
1. Open testcase
2. {{mvn javadoc:jar}}
3. Notice that generated Javadoc contains broken link to {{java.lang.Number}}
It doesn't look like one can link to the JDK as of version 9 because the URL
changed slightly to accommodate Java modules.
Please see https://bugs.openjdk.java.net/browse/JDK-8191363 for a related
discussion. If any syntax change is required in the pom, please consider
updating
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/links-configuration.html
accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
dedabob commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-451033153 Changes rebased and squashed but a merge was required anyway. I hope it's fine, otherwise i could provide a patch file This is an automated message from the Apache Git Service. To respond to the message, please log on 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-555) Javadoc:aggregate fails if one of the modules does not contain module-info.java
[
https://issues.apache.org/jira/browse/MJAVADOC-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732526#comment-16732526
]
Gili commented on MJAVADOC-555:
---
Regarding #4, how would that work exactly? If you look at the testcase, you'll
notice that we're running the Javadoc tool against unpacked files. I don't see
how you would add a manifest file in this context.
I tried manually adding MANIFEST.MF containing *Automatic-Module-Name: module2*
but it did not make a difference.
Either MANIFEST.MF isn't being picked up by the Javadoc tool, or
*Automatic-Module-Name* is not sufficient in this case (i.e. we need
*module-info.java*).
> Javadoc:aggregate fails if one of the modules does not contain
> module-info.java
> ---
>
> Key: MJAVADOC-555
> URL: https://issues.apache.org/jira/browse/MJAVADOC-555
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unzip testcase
> # Run {{mvn clean install javadoc:aggregate}}
> # Build fails with: {{Exit code: 2 - javadoc: error - No source files for
> package module2}}
> Per MPLUGIN-341, Maven plugins cannot contain {{module.info.java}}. One of my
> projects builds under Java 11 and is fully modularized except for one module
> which is a Maven plugin. Due to the aforementioned issue, I cannot use
> {{javadoc:aggregate.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
[
https://issues.apache.org/jira/browse/MJAVADOC-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732519#comment-16732519
]
Gili commented on MJAVADOC-560:
---
The *javadoc:aggregate* documentation contains the same issues. Maybe other
goals as well.
> Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc
> documentation
> ---
>
> Key: MJAVADOC-560
> URL: https://issues.apache.org/jira/browse/MJAVADOC-560
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Priority: Major
>
> Looking at the documentation for javadoc:javadoc at
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I
> see three problems:
> # The documentation lists both *outputDirectory* and *reportOutputDirectory*
> parameters, having the same description. It's not clear what each one is used
> for or what happens if one property is changed without the other.
> # The default value of *outputDirectory* is listed as
> *${project.build.directory}/apidocs* but the value that is actually used is
> *${project.reporting.outputDirectory}/apidocs* (the value of
> *reportOutputDirectory*).
> # It was extremely difficult to find any documentation on
> *${project.reporting.outputDirectory}***, such as what its default value is.
> I eventually found [https://maven.apache.org/pom.html#Reporting] but Google
> does not link directly to this page/section because it doesn't contain an
> explicit reference to *${project.reporting}*.
> Suggested fix(es):
> # Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
> confusion.
> # Update the documentation so it lists the correct default value for
> *outputDirectory*.
> # Link directly from mention of *${project.reporting.outputDirectory}* to
> [https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
Gili created MJAVADOC-560:
-
Summary: Clarify outputDirectory, reportOutputDirectory in
javadoc:javadoc documentation
Key: MJAVADOC-560
URL: https://issues.apache.org/jira/browse/MJAVADOC-560
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.1.0
Reporter: Gili
Looking at the documentation for javadoc:javadoc at
[https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I see
three problems:
# The documentation lists both *outputDirectory* and *reportOutputDirectory*
parameters, having the same description. It's not clear what each one is used
for or what happens if one property is changed without the other.
# The default value of *outputDirectory* is listed as
*${project.build.directory}/apidocs* but the value that is actually used is
*${project.reporting.outputDirectory}/apidocs* (the value of
*reportOutputDirectory*).
# It was extremely difficult to find any documentation on
*${project.reporting.outputDirectory}***, such as what its default value is. I
eventually found [https://maven.apache.org/pom.html#Reporting] but Google does
not link directly to this page/section because it doesn't contain an explicit
reference to *${project.reporting}*.
Suggested fix(es):
# Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
confusion.
# Update the documentation so it lists the correct default value for
*outputDirectory*.
# Link directly from mention of *${project.reporting.outputDirectory}* to
[https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rpopov commented on issue #1: Allow scripting in files
rpopov commented on issue #1: Allow scripting in files URL: https://github.com/apache/maven-scripting-plugin/pull/1#issuecomment-451006710 > Hi @rpopov our JIRA is public, you can freely subscribe. > Please create an issue describing your idea. I registered in JIRA as a regular user and the MSCRIPT JIRA project is not available to me. I cannot register any issue in it.  This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (WAGON-540) Switch to modern-day encoding (UTF-8) of auth credentials
[ https://issues.apache.org/jira/browse/WAGON-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-540: - Fix Version/s: 3.3.1 > Switch to modern-day encoding (UTF-8) of auth credentials > - > > Key: WAGON-540 > URL: https://issues.apache.org/jira/browse/WAGON-540 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http >Affects Versions: 3.2.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.0, 3.3.1 > > > These days people use non-ASCII encodings for usernames and password. While > other auth schemes like NTLM or Kerberos use Unicode by default, Basic and > Digest were restricted to ASCII or ISO-8859-1 for a long time. Major browsers > (Chrome + FF) now have switched to UTF-8. We should do that too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-537: - Fix Version/s: 3.3.1 > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0, 3.3.1 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-538) Basic authentication fails if the password contains non-ASCII characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-538:
-
Fix Version/s: 3.3.1
> Basic authentication fails if the password contains non-ASCII characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.0, 3.3.1
>
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-539) Explicitly register only supported auth schemes
[
https://issues.apache.org/jira/browse/WAGON-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-539:
-
Fix Version/s: 3.3.1
> Explicitly register only supported auth schemes
> ---
>
> Key: WAGON-539
> URL: https://issues.apache.org/jira/browse/WAGON-539
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.0, 3.3.1
>
>
> We shall only register auth schemes Basic, Digest, NTLM which
> {{settings.xml}} supports. Other aren't really supported. More over, the
> SPNEGO support in HttpClient is broken and shall not be used: HTTPCLIENT-1625
> and HTTPCLIENT-1938.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-543: - Fix Version/s: 3.3.1 > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.1 > > Attachments: debugger screenshot.png > > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal JSCH 32K buffer > Reverting WAGON-537 fixes this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WAGON-544) Work around JSch issue #122
Michael Osipov created WAGON-544:
Summary: Work around JSch issue #122
Key: WAGON-544
URL: https://issues.apache.org/jira/browse/WAGON-544
Project: Maven Wagon
Issue Type: Task
Components: wagon-ssh
Affects Versions: 3.3.0
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.3.1
JSch's {{Channels$MyPipedInputStream#read()}} does not return -1 when EOF is
reached. This causes the reading thread to block and never to resume. This
happens only when more bytes are requested to be read than available from the
stream. It does not read at most bytes. So one has to know the last
less-than-the-buffer-length chunk and recalculate remaining bytes. This worked
conincidentially because it worked that way.
This is brittle, as long as the upstream bug is not fixed we will restore the
previous {{AbstractWagon#transfer()}} implementation in {{AbstractJschWagon}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732297#comment-16732297 ] Dan Tran commented on WAGON-543: Let's go with that option > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Assignee: Michael Osipov >Priority: Major > Attachments: debugger screenshot.png > > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal JSCH 32K buffer > Reverting WAGON-537 fixes this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732272#comment-16732272
]
Michael Osipov commented on WAGON-543:
--
I think the only option is to restore the old transfer method in
{{AbstractJschWagon}} only until the upstream issue is resolved.
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
> Attachments: debugger screenshot.png
>
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732239#comment-16732239
]
Michael Osipov commented on WAGON-543:
--
Running Wagon master against {{scpexe}} works flawlessly. So we need a
workaround for JSch until the upstream issue is resolved.
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
> Attachments: debugger screenshot.png
>
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732235#comment-16732235
]
Michael Osipov commented on WAGON-543:
--
I have modified the wagon-maven-plugin to use {{scpexe}} (wagon-ssh-external)
and applied {{no-channels}} to Wagon:
{noformat}
[mosipov@mika-ion ~/Projekte/wagon-maven-plugin/src/test/projects/ssh-it]$
~/apache-maven-3.6.1-SNAPSHOT/bin/mvn -Debug
-Dit-plugin.version=2.0.1-SNAPSHOT -s settings.xml
[INFO] Scanning for projects...
[INFO]
[INFO] < org.codehaus.mojo:wagon-maven-plugin >
[INFO] Building wagon-maven-plugin testing
[INFO] [ pom ]-
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:sshexec (ssh-exec) @
wagon-maven-plugin ---
[INFO] sshexec: rm -rf /tmp/wagon ...
[INFO] sshexec: mkdir -p /tmp/wagon/empty ...
[INFO] sshexec: touch /tmp/wagon/a.txt ...
[INFO] sshexec: touch /tmp/wagon/b.txt ...
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:list (ssh-list-1) @
wagon-maven-plugin ---
[INFO] Scanning remote file system: scpexe://localhost ...
[INFO] a.txt
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:list (ssh-list-2) @
wagon-maven-plugin ---
[INFO] Scanning remote file system: scpexe://localhost ...
[INFO] a.txt
[INFO] b.txt
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:upload-single (ssh-upload-single)
@ wagon-maven-plugin ---
[INFO] Uploading:
/usr/home/mosipov/Projekte/wagon-maven-plugin/src/test/projects/ssh-it/src/test/data/gt-32k.txt
scpexe://localhost/tmp/wagon/gt-32k.txt
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:download-single
(ssh-download-single) @ wagon-maven-plugin ---
[INFO] Downloading: scpexe://localhost/tmp/wagon/gt-32k.txt to
/usr/home/mosipov/Projekte/wagon-maven-plugin/src/test/projects/ssh-it/target/gt-32k.txt
[INFO]
[INFO] --- wagon-maven-plugin:2.0.1-SNAPSHOT:sshexec (ssh-exec-wagon-431) @
wagon-maven-plugin ---
[INFO] sshexec: cat /tmp/wagon/gt-32k.txt ...
4.0.0
org.codehaus.mojo
wagon-maven-plugin
pom
testing
package
org.apache.maven.wagon
wagon-ssh
2.11
org.codehaus.mojo
wagon-maven-plugin
1.1-SNAPSHOT
wagon-maven-plugin-ssh-test
scp://localhost:
ssh-exec
package
sshexec
true
rm -rf /tmp/wagon
mkdir -p /tmp/wagon/empty
touch /tmp/wagon/a.txt
touch /tmp/wagon/b.txt
ssh-list-1
package
list
/tmp/wagon
**
**/b.txt
ssh-list-2
package
list
/tmp/wagon
**
ssh-upload-single
package
upload-single
pom.xml
tmp/wagon/pom.xml
ssh-download-single
package
download-single
tmp/wagon/pom.xml
${project.build.directory}/pom.xml
ssh-exec-2
package
sshexec
true
cat /tmp/wagon/pom.xml
org.codehaus.mojo
wagon-maven-plugin
1.0
wagon-maven-plugin-ssh-test
scp://localhost:
ssh-exec
package
sshexec
true
rm -rf /tmp/wagon
mkdir -p /tmp/wagon/empty
touch /tmp/wagon/a.txt
touch /tmp/wagon/b.txt
ssh-list-1
package
list
/tmp/wagon
**
**/b.txt
ssh-list-2
package
list
/tmp/wagon
**
ssh-upload-single
package
upload-single
pom.xml
tmp/wagon/pom.xml
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1673#comment-1673
]
Michael Osipov commented on WAGON-543:
--
[~dantran], I have uploaded branch {{no-channels}} in Wagon where I have
reverted WAGON-537 and applied a small change on top of it. JSch still hangs
with non-NIO code. This is a bug a JSch. Please try the branch and tell me what
you think.
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
> Attachments: debugger screenshot.png
>
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-543) wagon-ssh download hangs
[ https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-543: - Attachment: debugger screenshot.png > wagon-ssh download hangs > > > Key: WAGON-543 > URL: https://issues.apache.org/jira/browse/WAGON-543 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 3.3.0 >Reporter: Dan Tran >Assignee: Michael Osipov >Priority: Major > Attachments: debugger screenshot.png > > > To reproduce this issue > 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git > 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with > 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0 > Assume your local account can ssh to same host with ssh key > other notes: > * No problem with maven 3.6.0 > * I also have internal ssh library wrapper of wagon-ssh to perform > sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0 > * The root cause likely is from WAGON-537 with changes at AbstractWagon > which may have side effect on internal JSCH 32K buffer > Reverting WAGON-537 fixes this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mickaelistria commented on issue #197: [MNG-6533] Test: ProjectBuildingException miss reference to MavenProject
mickaelistria commented on issue #197: [MNG-6533] Test: ProjectBuildingException miss reference to MavenProject URL: https://github.com/apache/maven/pull/197#issuecomment-450911058 > I reworked the PR, creating 2 initial little refactoring commits that make the later modification a lot easier to understand IMHO: see MNG-6533-2 branch. With that 2 commits, I now can understand the main "Prefer passing the interim project in ProjectBuildingResult" commit... Ok, thanks. > One little thing that I feel is not good: catch(Exception) in the last commit. is catching InvalidArtifactRTException not sufficient? IIRC, there were some cases where this wasn't sufficient and some other exceptions could happen in m2e using this API; but I don't remember how much this memory is true; so I need to double-check. I'll give it a try with `catch (InvalidArtifactRTException)` and see how m2e likes it or not on next Monday hopefully. If it seems to work as expected for m2e, I'm fine with changing it. If it doesn't I'll try to write extra-unit tests for the potential issues that are not covered by this exception. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732174#comment-16732174
]
Michael Osipov edited comment on WAGON-543 at 1/2/19 4:25 PM:
--
[~dantran], I believe the current code does not have a bug, but simply surfaced
a bug in the {{InputStream}} implementation of JSch. {{#read()}} is not
implemented as specified and does not return a -1 on EOF.
The fundamental difference is that the previous code requested to stream the
only remaining amount of bytes and the new one the at most amount of bytes
available to the buffer which is more than 916,
was (Author: michael-o):
[~dantran], I believe the current code does not hav a bug, but simply surfaced
a bug in the {{InputStream}} implementation of JSch. {{#read()}} is not
implemented as specified and does not return a -1 on EOF.
The fundamental difference is that the previous code request to stream the only
remaining amount of bytes and the new one the at most the amount of bytes
available to the buffer which is more than 916,
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
> Attachments: debugger screenshot.png
>
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732183#comment-16732183
]
Michael Osipov commented on WAGON-543:
--
The byte at position 916 is {{NUL}}.
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
> Attachments: debugger screenshot.png
>
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732193#comment-16732193
]
Michael Osipov commented on WAGON-543:
--
Thread dump at blocked state:
{noformat}
[mosipov@mika-ion ~]$ jstack 2030
2019-01-02 17:10:39
Full thread dump OpenJDK Server VM (24.95-b01 mixed mode):
"Attach Listener" daemon prio=5 tid=0x74415000 nid=0x7442a000 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
"Connect thread localhost session" prio=5 tid=0x2967ec00 nid=0x73dfd400
runnable [0xbb429000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:153)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at com.jcraft.jsch.IO.getByte(IO.java:82)
at com.jcraft.jsch.Session.read(Session.java:926)
at com.jcraft.jsch.Session.run(Session.java:1403)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" daemon prio=5 tid=0x2967d000 nid=0x296b5400 runnable
[0x]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" daemon prio=5 tid=0x2967c800 nid=0x296b5100 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" daemon prio=5 tid=0x2967bc00 nid=0x296b4e00 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
"JDWP Command Reader" daemon prio=5 tid=0x74616000 nid=0x7462e000 runnable
[0x]
java.lang.Thread.State: RUNNABLE
"JDWP Event Helper Thread" daemon prio=5 tid=0x2967b400 nid=0x296b4b00 runnable
[0x]
java.lang.Thread.State: RUNNABLE
"JDWP Transport Listener: dt_socket" daemon prio=5 tid=0x2967ac00
nid=0x296b4800 runnable [0x]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=5 tid=0x2967a800 nid=0x296b4500 runnable
[0x]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=5 tid=0x2967a000 nid=0x296b4200 in Object.wait()
[0xbb8d6000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x30edc300> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked <0x30edc300> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
"Reference Handler" daemon prio=5 tid=0x29679800 nid=0x296b3f00 in
Object.wait() [0xbb927000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x30edbec8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked <0x30edbec8> (a java.lang.ref.Reference$Lock)
"main" prio=5 tid=0x29679000 nid=0x28614300 in Object.wait() [0xbbbfc000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x5c18e420> (a com.jcraft.jsch.Channel$MyPipedInputStream)
at java.io.PipedInputStream.read(PipedInputStream.java:327)
- locked <0x5c18e420> (a com.jcraft.jsch.Channel$MyPipedInputStream)
at java.io.PipedInputStream.read(PipedInputStream.java:378)
- locked <0x5c18e420> (a com.jcraft.jsch.Channel$MyPipedInputStream)
at
java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
- locked <0x5c1a6158> (a java.lang.Object)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:598)
at
org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:395)
at
org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.getTransfer(ScpWagon.java:184)
at
org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:338)
at
org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:307)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:97)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at
org.codehaus.mojo.wagon.DownloadSingleMojo.execute(DownloadSingleMojo.java:90)
at
org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute(AbstractSingleWagonMojo.java:63)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
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
[jira] [Commented] (WAGON-543) wagon-ssh download hangs
[
https://issues.apache.org/jira/browse/WAGON-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732174#comment-16732174
]
Michael Osipov commented on WAGON-543:
--
[~dantran], I believe the current code does not hav a bug, but simply surfaced
a bug in the {{InputStream}} implementation of JSch. {{#read()}} is not
implemented as specified and does not return a -1 on EOF.
The fundamental difference is that the previous code request to stream the only
remaining amount of bytes and the new one the at most the amount of bytes
available to the buffer which is more than 916,
> wagon-ssh download hangs
>
>
> Key: WAGON-543
> URL: https://issues.apache.org/jira/browse/WAGON-543
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 3.3.0
>Reporter: Dan Tran
>Assignee: Michael Osipov
>Priority: Major
>
> To reproduce this issue
> 1. checkout https://github.com/mojohaus/wagon-maven-plugin.git
> 2. Locally build maven 3.6.1-SNAPSHOT with wagon 3.3.0 and run it with
> 3. cd src/test/project/ssh-it; mvn -Dit-plugin.version=2.0.0
> Assume your local account can ssh to same host with ssh key
> other notes:
> * No problem with maven 3.6.0
> * I also have internal ssh library wrapper of wagon-ssh to perform
> sshexe/upload/download activities. Seeing the same issue with wagon 3.3.0
> * The root cause likely is from WAGON-537 with changes at AbstractWagon
> which may have side effect on internal JSCH 32K buffer
> Reverting WAGON-537 fixes this issue
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on issue #2: [MJAR-238] Allow setting of module main class
eolivelli commented on issue #2: [MJAR-238] Allow setting of module main class URL: https://github.com/apache/maven-jar-plugin/pull/2#issuecomment-450897788 @plamentotev check out the logs here: https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/ This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (DOXIA-575) Add support for (X)HTML5
[ https://issues.apache.org/jira/browse/DOXIA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732135#comment-16732135 ] Graham Leggett commented on DOXIA-575: -- A quick bump, and a happy new year! :) The patch consists of: - Xhtml5 code that started life as a copy of the html4 driver. - Updates to support new tags that are valid in HTML5 but ignored by the html4 driver. - Minor changes to switch HTML4 header syntax to HTML5 header syntax. To make it easier to review, apply the patch and then compare the new xhtml5 driver class file to the existing xhtml4 driver class file. The changes should be pretty straightforward. > Add support for (X)HTML5 > > > Key: DOXIA-575 > URL: https://issues.apache.org/jira/browse/DOXIA-575 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.8 >Reporter: Graham Leggett >Priority: Major > Attachments: DOXIA-575.patch > > > Doxia currently generates XHTML v1.1, and does not support any of the new > HTML5 tags. > Update Doxia to support HTML5.2 as per https://www.w3.org/TR/html52/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-787) Add optional buildEnvironment information to the manifest
[
https://issues.apache.org/jira/browse/MSHARED-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732105#comment-16732105
]
Michael Osipov edited comment on MSHARED-787 at 1/2/19 2:38 PM:
If I don't hear any objections by the end of next week, I'd go on and merge
this.
was (Author: michael-o):
If I don't hear any objections by the end of next week, I'd go on and merge it.
> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> People are demanding to have more control about the build information
> (MSHARED-362). We should add the following to control this:
> {{ which is by default disabled. It will
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Created-By: Apache Maven ${maven.version}
> Build-Jdk: ${java.version} (${java.vm.vendor})
> Build-Os: ${os.name} (${os.version}; (${os.arch}){noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-787) Add optional buildEnvironment information to the manifest
[
https://issues.apache.org/jira/browse/MSHARED-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-787:
---
Fix Version/s: maven-archiver-3.3.1
> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.3.1
>
>
> People are demanding to have more control about the build information
> (MSHARED-362). We should add the following to control this:
> {{ which is by default disabled. It will
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Created-By: Apache Maven ${maven.version}
> Build-Jdk: ${java.version} (${java.vm.vendor})
> Build-Os: ${os.name} (${os.version}; (${os.arch}){noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-787) Add optional buildEnvironment information to the manifest
[
https://issues.apache.org/jira/browse/MSHARED-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732105#comment-16732105
]
Michael Osipov commented on MSHARED-787:
If I don't hear any objections by the end of next week, I'd go on and merge it.
> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> People are demanding to have more control about the build information
> (MSHARED-362). We should add the following to control this:
> {{ which is by default disabled. It will
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Created-By: Apache Maven ${maven.version}
> Build-Jdk: ${java.version} (${java.vm.vendor})
> Build-Os: ${os.name} (${os.version}; (${os.arch}){noformat}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732075#comment-16732075
]
Michael Osipov commented on SCM-777:
[~schaller], that's great. If I don't hear any objections from the other folks,
I will merge this next week.
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.2
>
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732021#comment-16732021
]
Andreas Schaller commented on SCM-777:
--
[~michael-o] your fix works for me, thanks!
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.2
>
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450839532 Okay so I will continue with this ticket and eventually merge it to master. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450838658 @eolivelli I have done that actually in places I have found. Feel free to work on that kind of stuff and request a review by some fellow committer. You should always consider compared to our huge user base we receive a very small amount of usable contributions. Please go on, triage that ticket and merge the commit with the ticket id. @jsoref thanks again! This is an automated message from the Apache Git Service. To respond to the message, please log on 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] eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450837815 @michael-o fine to me, let's merge this one. Thank you for your clarification. I feel it would be useful to raise this point to dev list and clean up other plugins. So that when a committer works on a plugin he has a change to clean up line endings writes to stdout This is an automated message from the Apache Git Service. To respond to the message, please log on 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] michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450836787 No one needs to complain to make things better. I fixed a lot of stuff last year in Maven SCM where no one complained, but I have stumbled upon because they were just broken in that specific constellation. Having a consistent `stdout` which can be written to a file is a good thing. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450835806 @michael-o does any user ever reported any problem with the output of this plugin ? I think that somehow on Windows (on Linux I am sure it is already working well) there is something which is making the output nicer. Something that is already translating the new line to the corresponding platform dependant value. I think that that constant is to be used when writing to a file for instance, not to stdout. So if no one ever complained why changing the code ? We could introduce some regression hard to debug. What's your opinion ? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-777:
---
Fix Version/s: 1.11.2
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.2
>
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731939#comment-16731939
]
Michael Osipov edited comment on SCM-777 at 1/2/19 10:56 AM:
-
[~hboutemy], [~olamy], I know it has been sometime since you implemented those
tickets. Can you remember what the purpose of the boolean property
{{Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL )}} is and why not a simply
not-null check on {{System.getProperty(
"scmCheckWorkingDirectoryUrl.currentWorkingDirectory" )}} hasn't been
performed? It pretty much seems like that proper documenation has been lost and
a regression has been introduced.
I have pushed a branch with a simple solution to the problem. Works for me,
though it does not fail properly if the target dir is not a working copy.
[~schaller], can you confirm that this solves your issue?
was (Author: michael-o):
[~hboutemy], [~olamy], I know it has been sometime since you implemented those
tickets. Can you remember what the purpose of the boolean property
`Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL )` is and why not a simply
not-null check on `System.getProperty(
"scmCheckWorkingDirectoryUrl.currentWorkingDirectory" )` hasn't been performed?
It pretty much seems like that proper documenation has been lost and a
regression has been introduced.
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-777) scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-777:
---
Summary: scm:validate ignores scmCheckWorkingDirectoryUrl configuration in
favor of system property (was: Maven plugin's scm:validate ignores
scmCheckWorkingDirectoryUrl configuration in favor of system property)
> scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of
> system property
> --
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException
[
https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731937#comment-16731937
]
Tibor Digana edited comment on SUREFIRE-1496 at 1/2/19 10:54 AM:
-
[~scolebou...@joda.org]
[~earcam]
[~triceo85]
I have not seen in the jira issue description that the build was broken because
of the message in the dump file.
IMHO the message is printed by JVM before Surefire wraps StdOut but then it is
the issue where the user should investigate the message and his project.
Regarding the process pipes, our plan is to use TCP/IP sockets instead of pipes
in the interprocess communication in the near future.
Pls refer to the Roadmap on the front page
https://maven.apache.org/surefire/maven-surefire-plugin/
was (Author: tibor17):
[~scolebou...@joda.org]
[~earcam]
[~triceo85]
I have not seen in the jira issue description that the build was broken because
of the message in the dump file.
IMHO the message is printed by JVM before Surefire wraps StdOut but then it is
the issue where the user should investigate the message and his project.
Regarding the process pipes, our plan is to use TCP/IP sockets instead of pipes
in the interprocess communication in the new future.
Pls refer to the Roadmap on the front page
https://maven.apache.org/surefire/maven-surefire-plugin/
> Dump file error for java.lang.module.ResolutionException
>
>
> Key: SUREFIRE-1496
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> Scenario:
> * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
> * `org.foo.a` requires `org.foo.b`
> * `org.foo.b` exports package `org.foo.b.c`
> * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
> * when surefire is run on module `org.foo.a` a dump file error occurs:
>
> {noformat}
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'Error occurred during initialization of boot layer'.
> java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma
> after third character in command 'Error occurred during initialization of
> boot layer'.
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Created on 2018-03-07T11:32:36.053
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'java.lang.module.ResolutionException: Module org.foo.a contains package
> org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'.
> {noformat}
>
> While the scenario is one that JPMS rejects, surefire should handle it
> better. The compiler compiles the code just fine because it doesn't see the
> resources as a package. Surefire is thus the first part of Maven that sees it
> as a "package" that clashes with the module org.foo.b.
> Clearly, some part of surefire needs to be taught to about
> java.lang.module.ResolutionException, as the error is tricky to find/see
> because it is a dump file.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731939#comment-16731939
]
Michael Osipov commented on SCM-777:
[~hboutemy], [~olamy], I know it has been sometime since you implemented those
tickets. Can you remember what the purpose of the boolean property
`Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL )` is and why not a simply
not-null check on `System.getProperty(
"scmCheckWorkingDirectoryUrl.currentWorkingDirectory" )` hasn't been performed?
It pretty much seems like that proper documenation has been lost and a
regression has been introduced.
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException
[
https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731937#comment-16731937
]
Tibor Digana commented on SUREFIRE-1496:
[~scolebou...@joda.org]
[~earcam]
[~triceo85]
I have not seen in the jira issue description that the build was broken because
of the message in the dump file.
IMHO the message is printed by JVM before Surefire wraps StdOut but then it is
the issue where the user should investigate the message and his project.
Regarding the process pipes, our plan is to use TCP/IP sockets instead of pipes
in the interprocess communication in the new future.
Pls refer to the Roadmap on the front page
https://maven.apache.org/surefire/maven-surefire-plugin/
> Dump file error for java.lang.module.ResolutionException
>
>
> Key: SUREFIRE-1496
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> Scenario:
> * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
> * `org.foo.a` requires `org.foo.b`
> * `org.foo.b` exports package `org.foo.b.c`
> * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
> * when surefire is run on module `org.foo.a` a dump file error occurs:
>
> {noformat}
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'Error occurred during initialization of boot layer'.
> java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma
> after third character in command 'Error occurred during initialization of
> boot layer'.
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Created on 2018-03-07T11:32:36.053
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'java.lang.module.ResolutionException: Module org.foo.a contains package
> org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'.
> {noformat}
>
> While the scenario is one that JPMS rejects, surefire should handle it
> better. The compiler compiles the code just fine because it doesn't see the
> resources as a package. Surefire is thus the first part of Maven that sees it
> as a "package" that clashes with the module org.foo.b.
> Clearly, some part of surefire needs to be taught to about
> java.lang.module.ResolutionException, as the error is tricky to find/see
> because it is a dump file.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450832136 @eolivelli why? Line ending consistency is important. There a hundreds of spots in our codebase which are inconsistent. I, therefore, appreciate this PR. I have worked extensively on Maven SCM and noticed how important that is. The issues were trivial, but took me days to identify and fix. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] michael-o edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450832136 @eolivelli why? Line ending consistency is important. There a hundreds of spots in our codebase which is inconsistent. I, therefore, appreciate this PR. I have worked extensively on Maven SCM an noticed how important that is. The issue were trivial, but took me days to identify and fix. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450832136 @eolivelli why? Line ending consistency is important. There a hundreds of spots in our codebase which is inconsistent. I, therefore, appreciate this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException
[
https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731927#comment-16731927
]
Lukas Petrovicky commented on SUREFIRE-1496:
I am also running into (possibly) a similar problem, with the same symptoms.
(Dump file error when migrating a codebase to JPMS.) That said, it is very hard
for me to investigate the issue, since (as [~earcam] says above) the error
gives no indication as to the cause and IDEA compiles and runs the tests just
fine.
Any chance the error message could be improved to show the offending STDOUT in
its entirety?
> Dump file error for java.lang.module.ResolutionException
>
>
> Key: SUREFIRE-1496
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.21.0
>Reporter: Stephen Colebourne
>Priority: Major
>
> Scenario:
> * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
> * `org.foo.a` requires `org.foo.b`
> * `org.foo.b` exports package `org.foo.b.c`
> * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
> * when surefire is run on module `org.foo.a` a dump file error occurs:
>
> {noformat}
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'Error occurred during initialization of boot layer'.
> java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma
> after third character in command 'Error occurred during initialization of
> boot layer'.
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.(ForkClient.java:511)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Created on 2018-03-07T11:32:36.053
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream
> 'java.lang.module.ResolutionException: Module org.foo.a contains package
> org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'.
> {noformat}
>
> While the scenario is one that JPMS rejects, surefire should handle it
> better. The compiler compiles the code just fine because it doesn't see the
> resources as a package. Surefire is thus the first part of Maven that sees it
> as a "package" that clashes with the module org.foo.b.
> Clearly, some part of surefire needs to be taught to about
> java.lang.module.ResolutionException, as the error is tricky to find/see
> because it is a dump file.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6547) MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml
[ https://issues.apache.org/jira/browse/MNG-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bo Wang updated MNG-6547: - Description: When I try to rewrite a _pom.xml_ to add a plugin configuration via *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, which triggers error of *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify (verify-sorted-pom).* I diff the pom.xml files and find that the order of the two tags ** and ** is changed, i.e.: *The original section:* generate-thrift ***...*** **generate-sources** ... *The error output:* generate-thrift **generate-sources** ***...*** ... The tested _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a copy of accumo-trace v1.5.1. The simple bug-trigger code example _[^Rewriter.java] and the tested [^pom.xml]_ are attached. was: When I try to rewrite a _pom.xml_ to add a plugin configuration via *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, which triggers error of *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify (verify-sorted-pom).* I diff the pom.xml files and find that the order of two tags ** and ** are changed, i.e.: *The original section:* generate-thrift ** exec ** **generate-sources** ... *The error output:* generate-thrift **generate-sources** ** exec ** ... The tested _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a copy of accumo-trace v1.5.1. The simple bug-trigger code example _[^Rewriter.java] and the tested [^pom.xml]_ are attached. > MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml > --- > > Key: MNG-6547 > URL: https://issues.apache.org/jira/browse/MNG-6547 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0, 3.6.0 > Environment: java version "1.7.0_79" > Java(TM) SE Runtime Environment (build 1.7.0_79-b15) > Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) >Reporter: Bo Wang >Priority: Major > Attachments: Rewriter.java, pom.xml > > > When I try to rewrite a _pom.xml_ to add a plugin configuration via > *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, > which triggers error of > *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify > (verify-sorted-pom).* > I diff the pom.xml files and find that the order of the two tags ** > and ** is changed, i.e.: > *The original section:* > > generate-thrift > ***...*** > **generate-sources** > ... > > *The error output:* > > generate-thrift > **generate-sources** > ***...*** > ... > > > The tested > _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a > copy of accumo-trace v1.5.1. The simple bug-trigger code example > _[^Rewriter.java] and the tested [^pom.xml]_ are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6547) MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml
[ https://issues.apache.org/jira/browse/MNG-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bo Wang updated MNG-6547: - Description: When I try to rewrite a _pom.xml_ to add a plugin configuration via *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, which triggers error of *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify (verify-sorted-pom).* I diff the pom.xml files and find that the order of the two tags ** and ** is changed, i.e.: *The original section:* generate-thrift ***...*** **generate-sources** ... *The error output:* generate-thrift **generate-sources** ***...*** ... The tested _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a copy from _[accumo-trace|https://github.com/apache/accumulo/tree/1.5.1/trace]_ v1.5.1. The simple bug-trigger code example _[^Rewriter.java] and the tested [^pom.xml]_ are attached. was: When I try to rewrite a _pom.xml_ to add a plugin configuration via *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, which triggers error of *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify (verify-sorted-pom).* I diff the pom.xml files and find that the order of the two tags ** and ** is changed, i.e.: *The original section:* generate-thrift ***...*** **generate-sources** ... *The error output:* generate-thrift **generate-sources** ***...*** ... The tested _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a copy of accumo-trace v1.5.1. The simple bug-trigger code example _[^Rewriter.java] and the tested [^pom.xml]_ are attached. > MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml > --- > > Key: MNG-6547 > URL: https://issues.apache.org/jira/browse/MNG-6547 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.0, 3.6.0 > Environment: java version "1.7.0_79" > Java(TM) SE Runtime Environment (build 1.7.0_79-b15) > Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) >Reporter: Bo Wang >Priority: Major > Attachments: Rewriter.java, pom.xml > > > When I try to rewrite a _pom.xml_ to add a plugin configuration via > *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, > which triggers error of > *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify > (verify-sorted-pom).* > I diff the pom.xml files and find that the order of the two tags ** > and ** is changed, i.e.: > *The original section:* > > generate-thrift > ***...*** > **generate-sources** > ... > > *The error output:* > > generate-thrift > **generate-sources** > ***...*** > ... > > > The tested > _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a > copy from > _[accumo-trace|https://github.com/apache/accumulo/tree/1.5.1/trace]_ v1.5.1. > The simple bug-trigger code example _[^Rewriter.java] and the tested > [^pom.xml]_ are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6547) MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml
Bo Wang created MNG-6547: Summary: MavenProject.writeModel(Writer writer) outputs an error-sorted pom.xml Key: MNG-6547 URL: https://issues.apache.org/jira/browse/MNG-6547 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0, 3.5.0 Environment: java version "1.7.0_79" Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) Reporter: Bo Wang Attachments: Rewriter.java, pom.xml When I try to rewrite a _pom.xml_ to add a plugin configuration via *MavenProject.write(Writer writer)*, the method outputs a wrong pom.xml, which triggers error of *com.google.code.sortpom:maven-sortpom-plugin:2.1.0:verify (verify-sorted-pom).* I diff the pom.xml files and find that the order of two tags ** and ** are changed, i.e.: *The original section:* generate-thrift ** exec ** **generate-sources** ... *The error output:* generate-thrift **generate-sources** ** exec ** ... The tested _[pom.xml|https://github.com/apache/accumulo/blob/1.5.1/trace/pom.xml]_ is a copy of accumo-trace v1.5.1. The simple bug-trigger code example _[^Rewriter.java] and the tested [^pom.xml]_ are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
eolivelli commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450826573 Seems to me and to the contributor himself that this change is not needed. Are there any other cases in other plugins ? We should keep consistent behavior among all the plugins. I am -0 on this patch. Feel free to commit but I think we can leave without it. I appreciate the work and patience of @jsoref . Thank you This is an automated message from the Apache Git Service. To respond to the message, please log on 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] eolivelli edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
eolivelli edited a comment on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450826573 Seems to me and to the contributor himself that this change is not needed. Are there any other cases in other plugins ? We should keep consistent behavior among all the plugins. I am -0 on this patch. Feel free to commit but I think we can live without it. I appreciate the work and patience of @jsoref . Thank you This is an automated message from the Apache Git Service. To respond to the message, please log on 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] Tibor17 commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
Tibor17 commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450821200 No objections from me. Go ahead! This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731877#comment-16731877
]
Andreas Schaller commented on SCM-777:
--
Yes, I know...
here's a minimal test case:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
my.group
my-artifact
1.0.0-SNAPSHOT
pom
scm:svn:https://svn-path
scm:svn:https://svn-path
https://svn-path
maven-scm-plugin
1.11.1
check scm
validate
validate
true
true
{code}
Running _mvn validate_ on this pom (on an incorrect svn path) will show an
error as expected, but if you remove the _systemPropertyies_ configuration it
dosn't work anymore.
And by the way. Happy new Year! :)
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened SCM-777:
Assignee: Michael Osipov
Thanks for the case, reopening...
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Assignee: Michael Osipov
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731877#comment-16731877
]
Michael Osipov edited comment on SCM-777 at 1/2/19 9:40 AM:
Yes, I know...
here's a minimal test case:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
my.group
my-artifact
1.0.0-SNAPSHOT
pom
scm:svn:https://svn-path
scm:svn:https://svn-path
https://svn-path
maven-scm-plugin
1.11.1
check scm
validate
validate
true
true
{code}
Running _mvn validate_ on this pom (on an incorrect svn path) will show an
error as expected, but if you remove the _systemProperties_ configuration it
dosn't work anymore.
And by the way. Happy new Year! :)
was (Author: schaller):
Yes, I know...
here's a minimal test case:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
my.group
my-artifact
1.0.0-SNAPSHOT
pom
scm:svn:https://svn-path
scm:svn:https://svn-path
https://svn-path
maven-scm-plugin
1.11.1
check scm
validate
validate
true
true
{code}
Running _mvn validate_ on this pom (on an incorrect svn path) will show an
error as expected, but if you remove the _systemPropertyies_ configuration it
dosn't work anymore.
And by the way. Happy new Year! :)
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-450820038 Something is still fishy about this: mosipov@mikaw10 MINGW64 /d/Entwicklung/Projekte/maven-javadoc-plugin (PR_MJAVADOC-527) $ git rebase master First, rewinding head to replay your work on top of it... Applying: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc .git/rebase-apply/patch:68: trailing whitespace. warning: 1 line adds whitespace errors. error: Failed to merge in the changes. Using index info to reconstruct a base tree... M src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java Falling back to patching base and 3-way merge... Auto-merging src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java CONFLICT (content): Merge conflict in src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java Patch failed at 0001 [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc The copy of the patch that failed is found in: .git/rebase-apply/patch Resolve all conflicts manually, mark them as resolved with "git add/rm ", then run "git rebase --continue". You can instead skip this commit: run "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort". Can you please check again? This is an automated message from the Apache Git Service. To respond to the message, please log on 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] michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?
michael-o commented on issue #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead? URL: https://github.com/apache/maven-enforcer/pull/48#issuecomment-450818400 @eolivelli @Tibor17 anything holding us off merging @jsoref's work? Looks good to me now. This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731857#comment-16731857
]
Michael Osipov commented on SCM-777:
[~schaller], if you can provide me a test case, I'd be happy to validate and
reopen. A lot of issues get overcome by events and most reporters do not even
react on questions. We are horribly short in people taking care of bugs --
that's the sad truth.
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-777) Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration in favor of system property
[
https://issues.apache.org/jira/browse/SCM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731833#comment-16731833
]
Andreas Schaller commented on SCM-777:
--
This bug is reported over 4 years ago and you close it because there is no
reaction within 4 month, really?
However, I tested scm-plugin 1.11.1 with maven 3.6.0 and still had to provide
the system property manually to get _mvn validate_ work as expected.
> Maven plugin's scm:validate ignores scmCheckWorkingDirectoryUrl configuration
> in favor of system property
> -
>
> Key: SCM-777
> URL: https://issues.apache.org/jira/browse/SCM-777
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
>Affects Versions: 1.9.1
> Environment: Java 7 x64 on Windows 7
>Reporter: Mark Herman
>Priority: Major
>
> org.apache.maven.scm.manager.AbstractScmManager.checkWorkingDirectoryUrl()
> uses... {code} Boolean.getBoolean( CHECK_WORKING_DIRECTORY_URL ) {code}
> ...in order to check if it should check the repository on scm:validate. This
> will only react to the system property, and not to the maven configuration.
> *Result:* no maven config will enable the check working directory option,
> only passing it in as a jvm argument.
> *Expected:* this should work:
> {code}
>
> org.apache.maven.plugins
> maven-scm-plugin
>
> true
>
>
>
> validate
>
> true
>
>
>
> validate
>
>
>
>
> {code}
> *Workaround:* Use section. Tried
> and for some reason that didn't appear to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
