[jira] [Commented] (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057641#comment-17057641
]
Ryabokon Roman commented on MNG-4142:
-
maven 3.6.1 This issue still persists :(
I spent about 2 weeks searching for the problem, discovered by accident. The
problem is the same, only we do not have a snapshot, but a release
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1757) maven-surefire-plugin versions starting from 2.22.0 do not run JUnit5 Test Suites junit-platform-runner
[
https://issues.apache.org/jira/browse/SUREFIRE-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057480#comment-17057480
]
Tibor Digana edited comment on SUREFIRE-1757 at 3/11/20, 11:55 PM:
---
[~DenysGalyuk]
The class {{TestPlanScannerFilter}} was introduced in April 2018 which is
related to 2.22.0 and higher.
It would be a good question for the JUnit5 developers, why the Line 56 returns
empty TestPlan.
was (Author: tibor17):
[~DenysGalyuk]
The class {{TestPlanScannerFilter}} was introduced in April 2018 which is
related to 2.22.0 and higher.
It would be a good question , why the Line 56 returns empty TestPlan.
> maven-surefire-plugin versions starting from 2.22.0 do not run JUnit5 Test
> Suites junit-platform-runner
> ---
>
> Key: SUREFIRE-1757
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1757
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3,
> 3.0.0-M4
>Reporter: Denys Galyuk
>Assignee: Tibor Digana
>Priority: Major
> Attachments: Build_Failure.png, Build_Success.png, tag.7z
>
>
> h1. {color:#00875A}plugin works with version 2.19.1 (or 2.20, or
> 2.21.0){color}
> I've attached the project archive to the bug report.
> h2. *Preconditions:*
> h3. pom.xml
> # *{color:#00875A}maven-surefire-plugin 2.19.1{color}* (or 2.20, or 2.21.0)
> # maven-compiler-plugin 3.8.1
> # junit-platform-runner 1.6.0
> # junit-jupiter-engine 5.6.0
> {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/xsd/maven-4.0.0.xsd";>
>4.0.0
>tag
>tag
>1.0-SNAPSHOT
>
>
>
>org.junit.jupiter
>junit-jupiter-engine
>5.6.0
>test
>
>
>
>org.junit.platform
>junit-platform-runner
>1.6.0
>test
>
>
>
>
>
>
>org.apache.maven.plugins
>maven-compiler-plugin
>3.8.1
>
>1.8
>1.8
>UTF-8
>
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
>
>
>
>
>
>
>
>
>
>2.21.0
>
>
>
>
>
>
> {code}
> h3. Test class base on JUnit5: @Test,@Tag,@Tags
> {code:java}package tests.testsuites.suite1;
> import org.junit.jupiter.api.Tag;
> import org.junit.jupiter.api.Tags;
> import org.junit.jupiter.api.Test;
> import static org.junit.jupiter.api.Assertions.assertTrue;
> public class Suite2TestNameTagsTests {
>@Test
>@Tag("UAT")
>void suite2_1Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_1Test(UAT tag)");
>assertTrue(true);
>}
>@Test
>@Tag("SMOKE")
>void suite2_2Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_2Test(SMOKE tag)");
>assertTrue(true);
>}
>@Test
>@Tags({@Tag("SMOKE"), @Tag("UAT")})
>void suite2_3Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_3Test(SMOKE and UAT
> tags)");
>assertTrue(true);
>}
> }{code}
> h3. JUnit5 Test Suite based on: @RunWith, @SelectPackages, @IncludeTags
> {code:java}package tests.suites;
> import org.junit.platform.runner.JUnitPlatform;
> import org.junit.platform.suite.api.IncludeTags;
> import org.junit.platform.suite.api.SelectPackages;
> import org.junit.runner.RunWith;
> @RunWith(JUnitPlatform.class)
> @SelectPackages("tests")
> @IncludeTags({"SMOKE","UAT"})
> public class SmokeAndUatSuiteTest {
> }{code}
> h3. Steps to reproduce: (Run the created test suite with maven)
> # Open terminal or GitBASH in the project folder
> # Run the command mvn clean test -Dtest=TestSuite
> h4. Actual Result: (something like this)
> {color:#00875A}*BUILD SUCCESS*
> *Tests run: 6, Failures: 0, Errors: 0, Skipped: 0*{color}
> {code}$ mvn clean test -Dtest=SmokeAndUatSuiteTest
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< tag:tag
> >---
> [INFO] Building tag 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ tag ---
> [INFO] Deleting C:\Users\galyuk\IdeaProjects\tag\target
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ tag ---
> [WARNING]
[jira] [Commented] (SUREFIRE-1757) maven-surefire-plugin versions starting from 2.22.0 do not run JUnit5 Test Suites junit-platform-runner
[
https://issues.apache.org/jira/browse/SUREFIRE-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057480#comment-17057480
]
Tibor Digana commented on SUREFIRE-1757:
[~DenysGalyuk]
The class {{TestPlanScannerFilter}} was introduced in April 2018 which is
related to 2.22.0 and higher.
It would be a good question , why the Line 56 returns empty TestPlan.
> maven-surefire-plugin versions starting from 2.22.0 do not run JUnit5 Test
> Suites junit-platform-runner
> ---
>
> Key: SUREFIRE-1757
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1757
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3,
> 3.0.0-M4
>Reporter: Denys Galyuk
>Assignee: Tibor Digana
>Priority: Major
> Attachments: Build_Failure.png, Build_Success.png, tag.7z
>
>
> h1. {color:#00875A}plugin works with version 2.19.1 (or 2.20, or
> 2.21.0){color}
> I've attached the project archive to the bug report.
> h2. *Preconditions:*
> h3. pom.xml
> # *{color:#00875A}maven-surefire-plugin 2.19.1{color}* (or 2.20, or 2.21.0)
> # maven-compiler-plugin 3.8.1
> # junit-platform-runner 1.6.0
> # junit-jupiter-engine 5.6.0
> {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/xsd/maven-4.0.0.xsd";>
>4.0.0
>tag
>tag
>1.0-SNAPSHOT
>
>
>
>org.junit.jupiter
>junit-jupiter-engine
>5.6.0
>test
>
>
>
>org.junit.platform
>junit-platform-runner
>1.6.0
>test
>
>
>
>
>
>
>org.apache.maven.plugins
>maven-compiler-plugin
>3.8.1
>
>1.8
>1.8
>UTF-8
>
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
>
>
>
>
>
>
>
>
>
>2.21.0
>
>
>
>
>
>
> {code}
> h3. Test class base on JUnit5: @Test,@Tag,@Tags
> {code:java}package tests.testsuites.suite1;
> import org.junit.jupiter.api.Tag;
> import org.junit.jupiter.api.Tags;
> import org.junit.jupiter.api.Test;
> import static org.junit.jupiter.api.Assertions.assertTrue;
> public class Suite2TestNameTagsTests {
>@Test
>@Tag("UAT")
>void suite2_1Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_1Test(UAT tag)");
>assertTrue(true);
>}
>@Test
>@Tag("SMOKE")
>void suite2_2Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_2Test(SMOKE tag)");
>assertTrue(true);
>}
>@Test
>@Tags({@Tag("SMOKE"), @Tag("UAT")})
>void suite2_3Test() {
>System.out.println("Suite2TestNameTagsTests:suite2_3Test(SMOKE and UAT
> tags)");
>assertTrue(true);
>}
> }{code}
> h3. JUnit5 Test Suite based on: @RunWith, @SelectPackages, @IncludeTags
> {code:java}package tests.suites;
> import org.junit.platform.runner.JUnitPlatform;
> import org.junit.platform.suite.api.IncludeTags;
> import org.junit.platform.suite.api.SelectPackages;
> import org.junit.runner.RunWith;
> @RunWith(JUnitPlatform.class)
> @SelectPackages("tests")
> @IncludeTags({"SMOKE","UAT"})
> public class SmokeAndUatSuiteTest {
> }{code}
> h3. Steps to reproduce: (Run the created test suite with maven)
> # Open terminal or GitBASH in the project folder
> # Run the command mvn clean test -Dtest=TestSuite
> h4. Actual Result: (something like this)
> {color:#00875A}*BUILD SUCCESS*
> *Tests run: 6, Failures: 0, Errors: 0, Skipped: 0*{color}
> {code}$ mvn clean test -Dtest=SmokeAndUatSuiteTest
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< tag:tag
> >---
> [INFO] Building tag 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ tag ---
> [INFO] Deleting C:\Users\galyuk\IdeaProjects\tag\target
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ tag ---
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ tag ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO
[jira] [Assigned] (MSHARED-862) DirectoryScannerTest looks flaky
[ https://issues.apache.org/jira/browse/MSHARED-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MSHARED-862: - Assignee: Elliotte Rusty Harold > DirectoryScannerTest looks flaky > > > Key: MSHARED-862 > URL: https://issues.apache.org/jira/browse/MSHARED-862 > Project: Maven Shared Components > Issue Type: Test > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > e.g. > [https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/depre/lastCompletedBuild/testReport/org.apache.maven.shared.utils.io/DirectoryScannerTest/] > > More specifically it looks like > [checkSymlinkBehaviour|https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/depre/lastCompletedBuild/testReport/org.apache.maven.shared.utils.io/DirectoryScannerTest/windows_jdk13___Build_windows_jdk13___checkSymlinkBehaviour] > passes on Linux VMs and fails on Windows VMs. Whether that's a failing in > the test or the code I don't know yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-610) Support multirelease jar
[ https://issues.apache.org/jira/browse/MJAVADOC-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057447#comment-17057447 ] Hudson commented on MJAVADOC-610: - Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #95 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/95/ > Support multirelease jar > > > Key: MJAVADOC-610 > URL: https://issues.apache.org/jira/browse/MJAVADOC-610 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When having a multirelease jar, all sourcefolders need to be added. Now only > the main sourcefolder is added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-javadoc-plugin] olamy merged pull request #40: MJAVADOC-610
olamy merged pull request #40: MJAVADOC-610 URL: https://github.com/apache/maven-javadoc-plugin/pull/40 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-javadoc-plugin] olamy opened a new pull request #40: MJAVADOC-610
olamy opened a new pull request #40: MJAVADOC-610 URL: https://github.com/apache/maven-javadoc-plugin/pull/40 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-shared-utils] elharo opened a new pull request #21: system independent file separator
elharo opened a new pull request #21: system independent file separator URL: https://github.com/apache/maven-shared-utils/pull/21 @rfscholte see if we can make DirectoryScannerTest pass on Windows This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-shared-utils] elharo closed pull request #12: deps: update JUnit
elharo closed pull request #12: deps: update JUnit URL: https://github.com/apache/maven-shared-utils/pull/12 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNGSITE-396) http://maven.apache.org/POM/4.0.0 is down
[ https://issues.apache.org/jira/browse/MNGSITE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057306#comment-17057306 ] Michael Osipov commented on MNGSITE-396: No it should not. There is no requirement that it has to exist physically. > http://maven.apache.org/POM/4.0.0 is down > - > > Key: MNGSITE-396 > URL: https://issues.apache.org/jira/browse/MNGSITE-396 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sarantos >Priority: Major > > I don't believe I need to say any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-396) http://maven.apache.org/POM/4.0.0 is down
[ https://issues.apache.org/jira/browse/MNGSITE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057219#comment-17057219 ] Sarantos commented on MNGSITE-396: -- I know very well what am I talking about, there should be something there like, this is reserved for pom 4.0 xmlns or something, not this : h2. Page Not Found We're sorry, but the page you requested cannot be found. This may be because: * The page has moved, was outdated, or has not been created yet * You typed the address incorrectly * You followed a link from another site that pointed to this page. If you came to this page by following a broken link on our site, you can report the problem. I thought you actually had a page that said something or at least nothing, not a page not found error, thats why I filled in the report. > http://maven.apache.org/POM/4.0.0 is down > - > > Key: MNGSITE-396 > URL: https://issues.apache.org/jira/browse/MNGSITE-396 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sarantos >Priority: Major > > I don't believe I need to say any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNGSITE-396) http://maven.apache.org/POM/4.0.0 is down
[ https://issues.apache.org/jira/browse/MNGSITE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNGSITE-396. -- Resolution: Invalid There is nothing to be down. You are not aware of XML namespace concepts. > http://maven.apache.org/POM/4.0.0 is down > - > > Key: MNGSITE-396 > URL: https://issues.apache.org/jira/browse/MNGSITE-396 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Sarantos >Priority: Major > > I don't believe I need to say any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
[
https://issues.apache.org/jira/browse/MDEPLOY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057186#comment-17057186
]
Michael Osipov commented on MDEPLOY-266:
So, I have checked the code. MDEPLOY calls Maven Artifact Transfer which calls
Maven Resolver which calls Maven Wagon. The deeper you get the less information
of the Maven source you have. Wagon is competely decoupled from. There is no
notion of repo id, {{settings.xml}} or whatsoever. One needs to identify where
the required information needs to be collected...
> More verbose output for deployment to trace down errors (esp. 401)
> --
>
> Key: MDEPLOY-266
> URL: https://issues.apache.org/jira/browse/MDEPLOY-266
> Project: Maven Deploy Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.2
>Reporter: Jörg Hohwiller
>Priority: Major
>
> There are many reasons why a deployment of maven artifacts can fail:
> * network error
> * error on server side in repo server
> * no login configured
> * wrong login configured
> * no password configured
> * wrong password configured (password may be encrypted so even almost
> impossible to determine)
> * repository ID in distribution-management and server ID in settings.xml do
> not match
> * etc.
> It is really hard to check all the possibilities (please note that the
> distributionManagement may be configured in a parent^N pom and out of sight
> so you need to print the effective-pom. Many Maven users even do not have a
> clue how to do that). However, maven-deploy-plugin only prints that the
> deployment failed and an HTTP status code (typically 401). But this is very
> little information. Tons of users are therefore waisting their own time and
> especially also the time of others (e.g. OSSRH team) to trace down the reason.
> It should be trivial for maven-deploy-plugin to log some more information:
> * ID of repository that deployment is going to use
> * whether a server tag from settings.xml could be resolved for this ID
> * the login that is used for the deployment or a WARNING if login is
> undefined
> * WARNING if password is undefined (obviously you should not log the
> password)
> With this simple information users could save many hours/days of valuable
> time to trace down errors more easily.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
[ https://issues.apache.org/jira/browse/MDEPLOY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056950#comment-17056950 ] Michael Osipov commented on MDEPLOY-266: I need to see how the code is structured in MDEPLOY. I will get back to you in the next couple of days. > More verbose output for deployment to trace down errors (esp. 401) > -- > > Key: MDEPLOY-266 > URL: https://issues.apache.org/jira/browse/MDEPLOY-266 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.8.2 >Reporter: Jörg Hohwiller >Priority: Major > > There are many reasons why a deployment of maven artifacts can fail: > * network error > * error on server side in repo server > * no login configured > * wrong login configured > * no password configured > * wrong password configured (password may be encrypted so even almost > impossible to determine) > * repository ID in distribution-management and server ID in settings.xml do > not match > * etc. > It is really hard to check all the possibilities (please note that the > distributionManagement may be configured in a parent^N pom and out of sight > so you need to print the effective-pom. Many Maven users even do not have a > clue how to do that). However, maven-deploy-plugin only prints that the > deployment failed and an HTTP status code (typically 401). But this is very > little information. Tons of users are therefore waisting their own time and > especially also the time of others (e.g. OSSRH team) to trace down the reason. > It should be trivial for maven-deploy-plugin to log some more information: > * ID of repository that deployment is going to use > * whether a server tag from settings.xml could be resolved for this ID > * the login that is used for the deployment or a WARNING if login is > undefined > * WARNING if password is undefined (obviously you should not log the > password) > With this simple information users could save many hours/days of valuable > time to trace down errors more easily. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNGSITE-396) http://maven.apache.org/POM/4.0.0 is down
Sarantos created MNGSITE-396: Summary: http://maven.apache.org/POM/4.0.0 is down Key: MNGSITE-396 URL: https://issues.apache.org/jira/browse/MNGSITE-396 Project: Maven Project Web Site Issue Type: Bug Reporter: Sarantos I don't believe I need to say any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
[ https://issues.apache.org/jira/browse/MDEPLOY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056850#comment-17056850 ] Jörg Hohwiller commented on MDEPLOY-266: > The request is quite broad. I was asking for four concrete and obvious aspects to write to the log. You can even consider the second as optional. The last two points should be trivial if you know the place in the code that is triggering the HTTP request. Already implementing these two would be a great improvement. I can not see why this should be too "broad"... > As a last resort, one can always enable wire and context logging for the > HttpClient. The problem is that coders are facing this problems in external environments such as travis-ci.org or Jenkins. They are technically unable to "enable wire and context logging" and in travis-ci.org this would even expose the password to the public if they could. Further I am proposing a feature that should be enabled by default. So if the problem occurred I get the proper eror details. Isn't it a best practice to give contextual information in case of an error? Why not for maven? > More verbose output for deployment to trace down errors (esp. 401) > -- > > Key: MDEPLOY-266 > URL: https://issues.apache.org/jira/browse/MDEPLOY-266 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.8.2 >Reporter: Jörg Hohwiller >Priority: Major > > There are many reasons why a deployment of maven artifacts can fail: > * network error > * error on server side in repo server > * no login configured > * wrong login configured > * no password configured > * wrong password configured (password may be encrypted so even almost > impossible to determine) > * repository ID in distribution-management and server ID in settings.xml do > not match > * etc. > It is really hard to check all the possibilities (please note that the > distributionManagement may be configured in a parent^N pom and out of sight > so you need to print the effective-pom. Many Maven users even do not have a > clue how to do that). However, maven-deploy-plugin only prints that the > deployment failed and an HTTP status code (typically 401). But this is very > little information. Tons of users are therefore waisting their own time and > especially also the time of others (e.g. OSSRH team) to trace down the reason. > It should be trivial for maven-deploy-plugin to log some more information: > * ID of repository that deployment is going to use > * whether a server tag from settings.xml could be resolved for this ID > * the login that is used for the deployment or a WARNING if login is > undefined > * WARNING if password is undefined (obviously you should not log the > password) > With this simple information users could save many hours/days of valuable > time to trace down errors more easily. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-610) Support multirelease jar
[ https://issues.apache.org/jira/browse/MJAVADOC-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056770#comment-17056770 ] Hudson commented on MJAVADOC-610: - Build failed in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-610 #4 See https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-610/4/ > Support multirelease jar > > > Key: MJAVADOC-610 > URL: https://issues.apache.org/jira/browse/MJAVADOC-610 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > > When having a multirelease jar, all sourcefolders need to be added. Now only > the main sourcefolder is added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MJAVADOC-610) Support multirelease jar
[ https://issues.apache.org/jira/browse/MJAVADOC-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAVADOC-610. - Fix Version/s: (was: 3.2.0) Resolution: Won't Fix Using openjdk 11 works . There is a bug which has been fixed but not reported in Oracle Jdk > Support multirelease jar > > > Key: MJAVADOC-610 > URL: https://issues.apache.org/jira/browse/MJAVADOC-610 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > > When having a multirelease jar, all sourcefolders need to be added. Now only > the main sourcefolder is added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-863) Possible NPEx in Maven30DependencyResolver.resolveDependencies
[
https://issues.apache.org/jira/browse/MSHARED-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056714#comment-17056714
]
Robert Scholte commented on MSHARED-863:
Did I wrote that? I guess there's a good reason why I changed it from 'never'
to 'can be'. Most likely related to how Aether code works.
> Possible NPEx in Maven30DependencyResolver.resolveDependencies
> --
>
> Key: MSHARED-863
> URL: https://issues.apache.org/jira/browse/MSHARED-863
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.12.0
>Reporter: Piotr Zygielo
>Priority: Major
>
> Possible NPEx in
> [Maven30DependencyResolver.resolveDependencies|https://github.com/apache/maven-artifact-transfer/blob/dc0d6bd30b855e147576c4e9cdfacf1382d69f07/src/main/java/org/apache/maven/shared/transfer/dependencies/resolve/internal/Maven30DependencyResolver.java#L156]
> {code:java}
> List aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> if ( mavenDependencies != null )
> {
> aetherDependencies = new ArrayList(
> mavenDependencies.size() );
> ...
> {code}
> Line 161
> {code:java}
> if ( mavenDependencies != null )
> {code}
> suggests that {{mavenDependencies}} can be {{null}}.
> However in such case previous {{mavenDependencies.size()}} results in
> {{NPEx}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
