Re: Latest snapshot build (archive, not Maven artifact)
Why is the CI stuff in a dedicated repo and not on the main repo? Could we try to change it? That would make Maven more "normal" and more accessible in term of contribution. I found https://github.com/apache/maven/blob/master/Jenkinsfile in the main repo. What is the purprose of this file vs the repo you linked? Also, I see https://github.com/apache/maven-jenkins-lib/pull/1/files was merged a year ago and then commented out https://github.com/apache/maven-jenkins-lib/commit/317a0e9eff8b1d793141291a4b335bf9b478ccd6 . Does anyone know what failure was happening? Was it some missing credentials in the settings.xml ? Unfortunately, I do not have enough knowledge about Apache infra to help if the issue is credentials.
Re: Latest snapshot build (archive, not Maven artifact)
PR welcome the code is at https://github.com/apache/maven-jenkins-lib Regards, Hervé Le lundi 27 mai 2019, 11:40:00 CEST Mickael Istria a écrit : > Up! > What's blocking for publication of snapshots from master to some snapshot > repo? I'd gladly try to help. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Yeah, sounds like a good idea to take full control of the line breaks in files, if they should be used to test line-break related features, since git might convert them on certain platforms if configured to do so (I tend to use Cygwin's git so I personally get unix-style line breaks). Looking forward to the next release of this plugin, thanks for your work on this and other things in the Maven ecosystem! - Eric L On Mon, May 27, 2019 at 10:35 PM Enrico Olivelli wrote: > Il lun 27 mag 2019, 22:27 Eric Lilja ha scritto: > > > I mean that we don't need to convert any line breaks in any files in > > maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21. > > However, we could extend the tests for "file-ends-with-newline" to > > explicitly cover all valid combinations of > > system-line-break/file-line-break. Like if my system line break is > > windows-style and the file ends with unix-style line break, the test > should > > pass, and vice versa. This to let the tests actually showcase (and test, > > obviously) how the feature actually works from 8.21 onwards (look at the > > bugifx I linked previously: > > https://github.com/checkstyle/checkstyle/issues/4073) > > > > This is the work, gently carried on by 2 guys from Checkstyle community. > > https://github.com/apache/maven-checkstyle-plugin/pull/16 > > The idea is to convert a bunch of files to linux EOL. IIUC git is able to > convert EOL automatically on windows, so having a clear convention for all > of the files helps keeping an uniform way of dealing with this problem. > > The integration test about MCHECKSTYLE-54 has been changed in a way that > now it is testing only the issue and not other stuff (like incidentally was > checking for EOLs due to the usage of the default checkstyle rules) > > Thank you for continuing this discussion for the health of the project > > Enrico > > > > > > - Eric L > > > > On Mon, May 27, 2019 at 10:17 PM Eric Lilja > wrote: > > > > > Hi Enrico! Just out of curiosity, what do you mean by " We are also > > fixing > > > EOL in the checkstyle plugin code base"? No change in the plugin is > > > required with regards to EOLs to make tests pass, simply bump to > version > > > 8.21 of checkstyle itself (but there were two other errors, seemingly > not > > > related to EOL characters). Cheers! > > > > > > - Eric L > > > > > > On Mon, May 27, 2019 at 8:37 PM Enrico Olivelli > > > wrote: > > > > > >> Eric > > >> Thank you > > >> > > >> We are also fixing EOL in the checkstyle plugin code base > > >> > > >> Enrico > > >> > > >> > > >> > > >> Il lun 27 mag 2019, 11:34 Eric Lilja ha > scritto: > > >> > > >> > Just to inform you that this problem has been resolved in version > 8.21 > > >> of > > >> > checkstyle, which was just released, and I've confirmed the fix > works > > by > > >> > running the ITs on the checkstyle-plugin (checked out master on > > Cygwin). > > >> > There are two other failures, though (was one failure with 8.20 if I > > >> recall > > >> > correctly, apart from the EOL issue still present in that version). > > >> > > > >> > https://github.com/checkstyle/checkstyle/issues/4073 > > >> > > > >> > - Eric L > > >> > > > >> > On Thu, May 16, 2019 at 1:33 AM Tibor Digana < > tibordig...@apache.org> > > >> > wrote: > > >> > > > >> > > Enrico, I checked the Checkstyle rules again (default value = > > system) > > >> and > > >> > > Robert is right, please adjust the IT sources on the fly. > > >> > > Not sure why INFRA or Jenkins sets the Windows EOL to LF. > > >> > > Therefore we could not find this issue in version 3.0.0 (Jan 04) > > >> because > > >> > > the IT was created on Jan 17 and we run it on local Windows the > > first > > >> > time. > > >> > > > > >> > > The library is fine. I used several old versions of the plugin > > having > > >> > > identical results. > > >> > > Few links: > > >> > > > > >> > > > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile > > >> > > > > >> > > http://checkstyle.sourceforge.net/google_style.html > > >> > > > > >> > > > > >> > > > >> > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml > > >> > > > > >> > > > > >> > > > >> > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > > >> > > > > >> > > I expected platform independence because my company used > > >> sun_checks.xml > > >> > on > > >> > > Windows with Unix EOL in Git/IDE without this problem. > > >> > > The company improved sun_checks.xml long time ago, so I realized > > that > > >> > later > > >> > > that it is slightly different XML and different experience. Sorry. > > >> > > Cheers > > >> > > Tibor17 > > >> > > > > >> > > > > >> > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli < > > eolive...@gmail.com> > > >> > > wrote: > > >> > > > > >> > > > I will get a windows box and try to reproduce. > > >> > > > It is weird that on ASF Jenkins the build is passing even on > > windows > > >> > > > > > >> > >
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Il lun 27 mag 2019, 22:27 Eric Lilja ha scritto: > I mean that we don't need to convert any line breaks in any files in > maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21. > However, we could extend the tests for "file-ends-with-newline" to > explicitly cover all valid combinations of > system-line-break/file-line-break. Like if my system line break is > windows-style and the file ends with unix-style line break, the test should > pass, and vice versa. This to let the tests actually showcase (and test, > obviously) how the feature actually works from 8.21 onwards (look at the > bugifx I linked previously: > https://github.com/checkstyle/checkstyle/issues/4073) > This is the work, gently carried on by 2 guys from Checkstyle community. https://github.com/apache/maven-checkstyle-plugin/pull/16 The idea is to convert a bunch of files to linux EOL. IIUC git is able to convert EOL automatically on windows, so having a clear convention for all of the files helps keeping an uniform way of dealing with this problem. The integration test about MCHECKSTYLE-54 has been changed in a way that now it is testing only the issue and not other stuff (like incidentally was checking for EOLs due to the usage of the default checkstyle rules) Thank you for continuing this discussion for the health of the project Enrico > - Eric L > > On Mon, May 27, 2019 at 10:17 PM Eric Lilja wrote: > > > Hi Enrico! Just out of curiosity, what do you mean by " We are also > fixing > > EOL in the checkstyle plugin code base"? No change in the plugin is > > required with regards to EOLs to make tests pass, simply bump to version > > 8.21 of checkstyle itself (but there were two other errors, seemingly not > > related to EOL characters). Cheers! > > > > - Eric L > > > > On Mon, May 27, 2019 at 8:37 PM Enrico Olivelli > > wrote: > > > >> Eric > >> Thank you > >> > >> We are also fixing EOL in the checkstyle plugin code base > >> > >> Enrico > >> > >> > >> > >> Il lun 27 mag 2019, 11:34 Eric Lilja ha scritto: > >> > >> > Just to inform you that this problem has been resolved in version 8.21 > >> of > >> > checkstyle, which was just released, and I've confirmed the fix works > by > >> > running the ITs on the checkstyle-plugin (checked out master on > Cygwin). > >> > There are two other failures, though (was one failure with 8.20 if I > >> recall > >> > correctly, apart from the EOL issue still present in that version). > >> > > >> > https://github.com/checkstyle/checkstyle/issues/4073 > >> > > >> > - Eric L > >> > > >> > On Thu, May 16, 2019 at 1:33 AM Tibor Digana > >> > wrote: > >> > > >> > > Enrico, I checked the Checkstyle rules again (default value = > system) > >> and > >> > > Robert is right, please adjust the IT sources on the fly. > >> > > Not sure why INFRA or Jenkins sets the Windows EOL to LF. > >> > > Therefore we could not find this issue in version 3.0.0 (Jan 04) > >> because > >> > > the IT was created on Jan 17 and we run it on local Windows the > first > >> > time. > >> > > > >> > > The library is fine. I used several old versions of the plugin > having > >> > > identical results. > >> > > Few links: > >> > > > >> > > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile > >> > > > >> > > http://checkstyle.sourceforge.net/google_style.html > >> > > > >> > > > >> > > >> > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml > >> > > > >> > > > >> > > >> > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > >> > > > >> > > I expected platform independence because my company used > >> sun_checks.xml > >> > on > >> > > Windows with Unix EOL in Git/IDE without this problem. > >> > > The company improved sun_checks.xml long time ago, so I realized > that > >> > later > >> > > that it is slightly different XML and different experience. Sorry. > >> > > Cheers > >> > > Tibor17 > >> > > > >> > > > >> > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli < > eolive...@gmail.com> > >> > > wrote: > >> > > > >> > > > I will get a windows box and try to reproduce. > >> > > > It is weird that on ASF Jenkins the build is passing even on > windows > >> > > > > >> > > > Enrico > >> > > > > >> > > > -- Forwarded message - > >> > > > Da: Enrico Olivelli > >> > > > Date: mar 14 mag 2019, 13:58 > >> > > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version > >> > 3.1.0 > >> > > > To: Maven Developers List > >> > > > > >> > > > > >> > > > Eric and Tibor, > >> > > > Thank you so much for your effort in testing Maven Checkstyle > >> Plugin. > >> > > > > >> > > > This is the "official" VOTE thread, here we have to decide if the > >> > staged > >> > > > artifacts are good to be released or not. > >> > > > > >> > > > Feel free to cast a -1 if you think that the staged artifacts are > >> not > >> > > > "stable" or there is any showstopper problem for the release. > >> > > > > >> > > > Let's move this
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
I mean that we don't need to convert any line breaks in any files in maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21. However, we could extend the tests for "file-ends-with-newline" to explicitly cover all valid combinations of system-line-break/file-line-break. Like if my system line break is windows-style and the file ends with unix-style line break, the test should pass, and vice versa. This to let the tests actually showcase (and test, obviously) how the feature actually works from 8.21 onwards (look at the bugifx I linked previously: https://github.com/checkstyle/checkstyle/issues/4073) - Eric L On Mon, May 27, 2019 at 10:17 PM Eric Lilja wrote: > Hi Enrico! Just out of curiosity, what do you mean by " We are also fixing > EOL in the checkstyle plugin code base"? No change in the plugin is > required with regards to EOLs to make tests pass, simply bump to version > 8.21 of checkstyle itself (but there were two other errors, seemingly not > related to EOL characters). Cheers! > > - Eric L > > On Mon, May 27, 2019 at 8:37 PM Enrico Olivelli > wrote: > >> Eric >> Thank you >> >> We are also fixing EOL in the checkstyle plugin code base >> >> Enrico >> >> >> >> Il lun 27 mag 2019, 11:34 Eric Lilja ha scritto: >> >> > Just to inform you that this problem has been resolved in version 8.21 >> of >> > checkstyle, which was just released, and I've confirmed the fix works by >> > running the ITs on the checkstyle-plugin (checked out master on Cygwin). >> > There are two other failures, though (was one failure with 8.20 if I >> recall >> > correctly, apart from the EOL issue still present in that version). >> > >> > https://github.com/checkstyle/checkstyle/issues/4073 >> > >> > - Eric L >> > >> > On Thu, May 16, 2019 at 1:33 AM Tibor Digana >> > wrote: >> > >> > > Enrico, I checked the Checkstyle rules again (default value = system) >> and >> > > Robert is right, please adjust the IT sources on the fly. >> > > Not sure why INFRA or Jenkins sets the Windows EOL to LF. >> > > Therefore we could not find this issue in version 3.0.0 (Jan 04) >> because >> > > the IT was created on Jan 17 and we run it on local Windows the first >> > time. >> > > >> > > The library is fine. I used several old versions of the plugin having >> > > identical results. >> > > Few links: >> > > >> > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile >> > > >> > > http://checkstyle.sourceforge.net/google_style.html >> > > >> > > >> > >> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml >> > > >> > > >> > >> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml >> > > >> > > I expected platform independence because my company used >> sun_checks.xml >> > on >> > > Windows with Unix EOL in Git/IDE without this problem. >> > > The company improved sun_checks.xml long time ago, so I realized that >> > later >> > > that it is slightly different XML and different experience. Sorry. >> > > Cheers >> > > Tibor17 >> > > >> > > >> > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli >> > > wrote: >> > > >> > > > I will get a windows box and try to reproduce. >> > > > It is weird that on ASF Jenkins the build is passing even on windows >> > > > >> > > > Enrico >> > > > >> > > > -- Forwarded message - >> > > > Da: Enrico Olivelli >> > > > Date: mar 14 mag 2019, 13:58 >> > > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version >> > 3.1.0 >> > > > To: Maven Developers List >> > > > >> > > > >> > > > Eric and Tibor, >> > > > Thank you so much for your effort in testing Maven Checkstyle >> Plugin. >> > > > >> > > > This is the "official" VOTE thread, here we have to decide if the >> > staged >> > > > artifacts are good to be released or not. >> > > > >> > > > Feel free to cast a -1 if you think that the staged artifacts are >> not >> > > > "stable" or there is any showstopper problem for the release. >> > > > >> > > > Let's move this discussion to a separate thread, something like >> > > "Validation >> > > > failures in Windows over current checkstyle plugin master branch") >> > > > >> > > > Enrico >> > > > >> > > > >> > > > >> > > > >> > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja < >> > > mindcoo...@gmail.com> >> > > > ha scritto: >> > > > >> > > > > Tried overriding line.separator when running using >> > > -Dline.separator="\n", >> > > > > but then the builds fails (early) in maven-plugin-plugin: >> > > > > [ERROR] Failed to execute goal >> > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor >> > > > > (default-descriptor) on project maven-checkstyle-plugin: Execution >> > > > > default-descriptor of goal >> > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor >> failed: >> > > > > Requested line separator is invalid. -> [Help 1] >> > > > > [ERROR] >> > > > > [ERROR] To see the full stack trace of the errors, re-run Maven >> with >> > > the >> > > > -e >>
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Hi Enrico! Just out of curiosity, what do you mean by " We are also fixing EOL in the checkstyle plugin code base"? No change in the plugin is required with regards to EOLs to make tests pass, simply bump to version 8.21 of checkstyle itself (but there were two other errors, seemingly not related to EOL characters). Cheers! - Eric L On Mon, May 27, 2019 at 8:37 PM Enrico Olivelli wrote: > Eric > Thank you > > We are also fixing EOL in the checkstyle plugin code base > > Enrico > > > > Il lun 27 mag 2019, 11:34 Eric Lilja ha scritto: > > > Just to inform you that this problem has been resolved in version 8.21 of > > checkstyle, which was just released, and I've confirmed the fix works by > > running the ITs on the checkstyle-plugin (checked out master on Cygwin). > > There are two other failures, though (was one failure with 8.20 if I > recall > > correctly, apart from the EOL issue still present in that version). > > > > https://github.com/checkstyle/checkstyle/issues/4073 > > > > - Eric L > > > > On Thu, May 16, 2019 at 1:33 AM Tibor Digana > > wrote: > > > > > Enrico, I checked the Checkstyle rules again (default value = system) > and > > > Robert is right, please adjust the IT sources on the fly. > > > Not sure why INFRA or Jenkins sets the Windows EOL to LF. > > > Therefore we could not find this issue in version 3.0.0 (Jan 04) > because > > > the IT was created on Jan 17 and we run it on local Windows the first > > time. > > > > > > The library is fine. I used several old versions of the plugin having > > > identical results. > > > Few links: > > > > > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile > > > > > > http://checkstyle.sourceforge.net/google_style.html > > > > > > > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml > > > > > > > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > > > > > > I expected platform independence because my company used sun_checks.xml > > on > > > Windows with Unix EOL in Git/IDE without this problem. > > > The company improved sun_checks.xml long time ago, so I realized that > > later > > > that it is slightly different XML and different experience. Sorry. > > > Cheers > > > Tibor17 > > > > > > > > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli > > > wrote: > > > > > > > I will get a windows box and try to reproduce. > > > > It is weird that on ASF Jenkins the build is passing even on windows > > > > > > > > Enrico > > > > > > > > -- Forwarded message - > > > > Da: Enrico Olivelli > > > > Date: mar 14 mag 2019, 13:58 > > > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version > > 3.1.0 > > > > To: Maven Developers List > > > > > > > > > > > > Eric and Tibor, > > > > Thank you so much for your effort in testing Maven Checkstyle Plugin. > > > > > > > > This is the "official" VOTE thread, here we have to decide if the > > staged > > > > artifacts are good to be released or not. > > > > > > > > Feel free to cast a -1 if you think that the staged artifacts are not > > > > "stable" or there is any showstopper problem for the release. > > > > > > > > Let's move this discussion to a separate thread, something like > > > "Validation > > > > failures in Windows over current checkstyle plugin master branch") > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja < > > > mindcoo...@gmail.com> > > > > ha scritto: > > > > > > > > > Tried overriding line.separator when running using > > > -Dline.separator="\n", > > > > > but then the builds fails (early) in maven-plugin-plugin: > > > > > [ERROR] Failed to execute goal > > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor > > > > > (default-descriptor) on project maven-checkstyle-plugin: Execution > > > > > default-descriptor of goal > > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: > > > > > Requested line separator is invalid. -> [Help 1] > > > > > [ERROR] > > > > > [ERROR] To see the full stack trace of the errors, re-run Maven > with > > > the > > > > -e > > > > > switch. > > > > > [ERROR] Re-run Maven using the -X switch to enable full debug > > logging. > > > > > [ERROR] > > > > > [ERROR] For more information about the errors and possible > solutions, > > > > > please read the following articles: > > > > > [ERROR] [Help 1] > > > > > > > > > > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > > > > > > > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff > > > > > upgradeable...), but same error > > > > > > > > > > I also happened to notice this (probably unrelated, but wanted to > > bring > > > > it > > > > > to attention anyway so it can be fixed) warning: > > > > > [INFO] java-annotations mojo extractor found 4 mojo descriptors. > > > > > [WARNING] > > > > > > > > > > Unexpected situation: destinationDirectory not
Re: [MINSTALL/Artifact Transfer] Who installs GroupRepositoryMetadata
Am 2019-05-27 um 21:50 schrieb Karl Heinz Marbaise: Hi Michael, On 27.05.19 21:26, Michael Osipov wrote: Am 2019-05-27 um 20:53 schrieb Karl Heinz Marbaise: Hi Michael, On 26.05.19 23:15, Michael Osipov wrote: Folks, I am trying to investigate an issue with MINSTALL 3.0.0-M1 for MNG-6556 where the GroupRepositoryMetadata file is simply not written to disk, thus the IT for MNG-3372 is failing. As far as I can see everything in Maven 2 for this task has been moved to Maven Artifact Transfer, Maven31ArtifactInstaller. I do see in for ( ArtifactMetadata metadata : mavenArtifact.getMetadataList() ) everything I need is there, but the instanceof tests simply ignore this kind of metadata and it is never persisted to disk. I am a bit lost because it looks like a several issue in our codebase. Is the IT flawed and should exclude the Maven version which will include MNG-6556 or am I just too stupid to see the obvious? Here is a simple reproducer: * Clone MINSTALL I suppose you maven-install-plugin git repo? .. Yes. * Open pom.xml and add MINSTALL 3.0.0-M1 to override from parent * Delete org/apache/maven/plugins from your local repo * Use Maven 3.6.1 to install MINSTALL 3.0.0-M2-SNAPSHOT maven-metadata-local.xml will *not* be generated, remove change in pom.xml and repeat, metadata file is there. Would be nice if someone can confirm this. Hm...I've tried your steps: plugins (master)$ ls -la maven-install-plugin/ 3.0.0-M1/ 3.0.0-M2-SNAPSHOT/ maven-metadata-local.xml plugins (master)$ ls -la maven-install-plugin/3.0.0-M2-SNAPSHOT/ total 96 drwxr-xr-x 6 khmarbaise staff 192 May 27 20:35 . drwxr-xr-x 5 khmarbaise staff 160 May 27 20:35 .. -rw-r--r-- 1 khmarbaise staff 231 May 27 20:35 _remote.repositories -rw-r--r-- 1 khmarbaise staff 29457 May 27 20:35 maven-install-plugin-3.0.0-M2-SNAPSHOT.jar -rw-r--r-- 1 khmarbaise staff 6346 May 27 20:30 maven-install-plugin-3.0.0-M2-SNAPSHOT.pom -rw-r--r-- 1 khmarbaise staff 739 May 27 20:35 maven-metadata-local.xml plugins (master)$ cat maven-install-plugin/3.0.0-M2-SNAPSHOT/maven-metadata-local.xml org.apache.maven.plugins maven-install-plugin 3.0.0-M2-SNAPSHOT true 20190527183515 jar 3.0.0-M2-SNAPSHOT 20190527183515 pom 3.0.0-M2-SNAPSHOT 20190527183515 plugins (master)$ and I get a written maven-metadata-local.xml file? Do I miss something? Yes, you do. I mean this maven-metadata-local.xml: Other Name other-plugin other-plugin This is generated a level above the group id. This has to present, but is not. Ah sorry missed that ... You are right now I see the issue ... But the question is: Why is this file needed and in particular by whom? I have to admit that I haven't dived into the IT's for that...are those files only checked by the IT's or is this related to something different? Pre 3.0.0 have written those files to disk. The IT fail for MNG-3372, maybe the IT is broken. IT fails with: PS D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-3372\direct-using-prefix\project> mvn mng3372:test "-Dmaven.repo.local=D:\Entwicklung\Projekte\maven-integration-testing\repo" -s ..\settings.xml [INFO] Scanning for projects... Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/its/mng3372/maven-metadata.xml Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml (14 kB at 35 kB/s) Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml (20 kB at 51 kB/s) [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1.114 s [INFO] Finished at: 2019-05-27T22:10:19+02:00 [INFO] [ERROR] No plugin found for prefix 'mng3372' in the current project and in the plugin groups [org.apache.maven.its.mng3372, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (C:\Users\mosipov\.m2\repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1]
Re: [MINSTALL/Artifact Transfer] Who installs GroupRepositoryMetadata
Hi Michael, On 27.05.19 21:26, Michael Osipov wrote: Am 2019-05-27 um 20:53 schrieb Karl Heinz Marbaise: Hi Michael, On 26.05.19 23:15, Michael Osipov wrote: Folks, I am trying to investigate an issue with MINSTALL 3.0.0-M1 for MNG-6556 where the GroupRepositoryMetadata file is simply not written to disk, thus the IT for MNG-3372 is failing. As far as I can see everything in Maven 2 for this task has been moved to Maven Artifact Transfer, Maven31ArtifactInstaller. I do see in for ( ArtifactMetadata metadata : mavenArtifact.getMetadataList() ) everything I need is there, but the instanceof tests simply ignore this kind of metadata and it is never persisted to disk. I am a bit lost because it looks like a several issue in our codebase. Is the IT flawed and should exclude the Maven version which will include MNG-6556 or am I just too stupid to see the obvious? Here is a simple reproducer: * Clone MINSTALL I suppose you maven-install-plugin git repo? .. Yes. * Open pom.xml and add MINSTALL 3.0.0-M1 to override from parent * Delete org/apache/maven/plugins from your local repo * Use Maven 3.6.1 to install MINSTALL 3.0.0-M2-SNAPSHOT maven-metadata-local.xml will *not* be generated, remove change in pom.xml and repeat, metadata file is there. Would be nice if someone can confirm this. Hm...I've tried your steps: plugins (master)$ ls -la maven-install-plugin/ 3.0.0-M1/ 3.0.0-M2-SNAPSHOT/ maven-metadata-local.xml plugins (master)$ ls -la maven-install-plugin/3.0.0-M2-SNAPSHOT/ total 96 drwxr-xr-x 6 khmarbaise staff 192 May 27 20:35 . drwxr-xr-x 5 khmarbaise staff 160 May 27 20:35 .. -rw-r--r-- 1 khmarbaise staff 231 May 27 20:35 _remote.repositories -rw-r--r-- 1 khmarbaise staff 29457 May 27 20:35 maven-install-plugin-3.0.0-M2-SNAPSHOT.jar -rw-r--r-- 1 khmarbaise staff 6346 May 27 20:30 maven-install-plugin-3.0.0-M2-SNAPSHOT.pom -rw-r--r-- 1 khmarbaise staff 739 May 27 20:35 maven-metadata-local.xml plugins (master)$ cat maven-install-plugin/3.0.0-M2-SNAPSHOT/maven-metadata-local.xml org.apache.maven.plugins maven-install-plugin 3.0.0-M2-SNAPSHOT true 20190527183515 jar 3.0.0-M2-SNAPSHOT 20190527183515 pom 3.0.0-M2-SNAPSHOT 20190527183515 plugins (master)$ and I get a written maven-metadata-local.xml file? Do I miss something? Yes, you do. I mean this maven-metadata-local.xml: Other Name other-plugin other-plugin This is generated a level above the group id. This has to present, but is not. Ah sorry missed that ... You are right now I see the issue ... But the question is: Why is this file needed and in particular by whom? I have to admit that I haven't dived into the IT's for that...are those files only checked by the IT's or is this related to something different? Kind regards Karl Heinz Marbaise Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MINSTALL/Artifact Transfer] Who installs GroupRepositoryMetadata
Am 2019-05-27 um 20:53 schrieb Karl Heinz Marbaise: Hi Michael, On 26.05.19 23:15, Michael Osipov wrote: Folks, I am trying to investigate an issue with MINSTALL 3.0.0-M1 for MNG-6556 where the GroupRepositoryMetadata file is simply not written to disk, thus the IT for MNG-3372 is failing. As far as I can see everything in Maven 2 for this task has been moved to Maven Artifact Transfer, Maven31ArtifactInstaller. I do see in for ( ArtifactMetadata metadata : mavenArtifact.getMetadataList() ) everything I need is there, but the instanceof tests simply ignore this kind of metadata and it is never persisted to disk. I am a bit lost because it looks like a several issue in our codebase. Is the IT flawed and should exclude the Maven version which will include MNG-6556 or am I just too stupid to see the obvious? Here is a simple reproducer: * Clone MINSTALL I suppose you maven-install-plugin git repo? .. Yes. * Open pom.xml and add MINSTALL 3.0.0-M1 to override from parent * Delete org/apache/maven/plugins from your local repo * Use Maven 3.6.1 to install MINSTALL 3.0.0-M2-SNAPSHOT maven-metadata-local.xml will *not* be generated, remove change in pom.xml and repeat, metadata file is there. Would be nice if someone can confirm this. Hm...I've tried your steps: plugins (master)$ ls -la maven-install-plugin/ 3.0.0-M1/ 3.0.0-M2-SNAPSHOT/ maven-metadata-local.xml plugins (master)$ ls -la maven-install-plugin/3.0.0-M2-SNAPSHOT/ total 96 drwxr-xr-x 6 khmarbaise staff 192 May 27 20:35 . drwxr-xr-x 5 khmarbaise staff 160 May 27 20:35 .. -rw-r--r-- 1 khmarbaise staff 231 May 27 20:35 _remote.repositories -rw-r--r-- 1 khmarbaise staff 29457 May 27 20:35 maven-install-plugin-3.0.0-M2-SNAPSHOT.jar -rw-r--r-- 1 khmarbaise staff 6346 May 27 20:30 maven-install-plugin-3.0.0-M2-SNAPSHOT.pom -rw-r--r-- 1 khmarbaise staff 739 May 27 20:35 maven-metadata-local.xml plugins (master)$ cat maven-install-plugin/3.0.0-M2-SNAPSHOT/maven-metadata-local.xml org.apache.maven.plugins maven-install-plugin 3.0.0-M2-SNAPSHOT true 20190527183515 jar 3.0.0-M2-SNAPSHOT 20190527183515 pom 3.0.0-M2-SNAPSHOT 20190527183515 plugins (master)$ and I get a written maven-metadata-local.xml file? Do I miss something? Yes, you do. I mean this maven-metadata-local.xml: Other Name other-plugin other-plugin This is generated a level above the group id. This has to present, but is not. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MINSTALL/Artifact Transfer] Who installs GroupRepositoryMetadata
Hi Michael, On 26.05.19 23:15, Michael Osipov wrote: Folks, I am trying to investigate an issue with MINSTALL 3.0.0-M1 for MNG-6556 where the GroupRepositoryMetadata file is simply not written to disk, thus the IT for MNG-3372 is failing. As far as I can see everything in Maven 2 for this task has been moved to Maven Artifact Transfer, Maven31ArtifactInstaller. I do see in for ( ArtifactMetadata metadata : mavenArtifact.getMetadataList() ) everything I need is there, but the instanceof tests simply ignore this kind of metadata and it is never persisted to disk. I am a bit lost because it looks like a several issue in our codebase. Is the IT flawed and should exclude the Maven version which will include MNG-6556 or am I just too stupid to see the obvious? Here is a simple reproducer: * Clone MINSTALL I suppose you maven-install-plugin git repo? .. * Open pom.xml and add MINSTALL 3.0.0-M1 to override from parent * Delete org/apache/maven/plugins from your local repo * Use Maven 3.6.1 to install MINSTALL 3.0.0-M2-SNAPSHOT maven-metadata-local.xml will *not* be generated, remove change in pom.xml and repeat, metadata file is there. Would be nice if someone can confirm this. Hm...I've tried your steps: plugins (master)$ ls -la maven-install-plugin/ 3.0.0-M1/ 3.0.0-M2-SNAPSHOT/ maven-metadata-local.xml plugins (master)$ ls -la maven-install-plugin/3.0.0-M2-SNAPSHOT/ total 96 drwxr-xr-x 6 khmarbaise staff192 May 27 20:35 . drwxr-xr-x 5 khmarbaise staff160 May 27 20:35 .. -rw-r--r-- 1 khmarbaise staff231 May 27 20:35 _remote.repositories -rw-r--r-- 1 khmarbaise staff 29457 May 27 20:35 maven-install-plugin-3.0.0-M2-SNAPSHOT.jar -rw-r--r-- 1 khmarbaise staff 6346 May 27 20:30 maven-install-plugin-3.0.0-M2-SNAPSHOT.pom -rw-r--r-- 1 khmarbaise staff739 May 27 20:35 maven-metadata-local.xml plugins (master)$ cat maven-install-plugin/3.0.0-M2-SNAPSHOT/maven-metadata-local.xml org.apache.maven.plugins maven-install-plugin 3.0.0-M2-SNAPSHOT true 20190527183515 jar 3.0.0-M2-SNAPSHOT 20190527183515 pom 3.0.0-M2-SNAPSHOT 20190527183515 plugins (master)$ and I get a written maven-metadata-local.xml file? Do I miss something? In artifact-transfer the generation of the checksum has been moved from install to deploy...? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Eric Thank you We are also fixing EOL in the checkstyle plugin code base Enrico Il lun 27 mag 2019, 11:34 Eric Lilja ha scritto: > Just to inform you that this problem has been resolved in version 8.21 of > checkstyle, which was just released, and I've confirmed the fix works by > running the ITs on the checkstyle-plugin (checked out master on Cygwin). > There are two other failures, though (was one failure with 8.20 if I recall > correctly, apart from the EOL issue still present in that version). > > https://github.com/checkstyle/checkstyle/issues/4073 > > - Eric L > > On Thu, May 16, 2019 at 1:33 AM Tibor Digana > wrote: > > > Enrico, I checked the Checkstyle rules again (default value = system) and > > Robert is right, please adjust the IT sources on the fly. > > Not sure why INFRA or Jenkins sets the Windows EOL to LF. > > Therefore we could not find this issue in version 3.0.0 (Jan 04) because > > the IT was created on Jan 17 and we run it on local Windows the first > time. > > > > The library is fine. I used several old versions of the plugin having > > identical results. > > Few links: > > > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile > > > > http://checkstyle.sourceforge.net/google_style.html > > > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml > > > > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > > > > I expected platform independence because my company used sun_checks.xml > on > > Windows with Unix EOL in Git/IDE without this problem. > > The company improved sun_checks.xml long time ago, so I realized that > later > > that it is slightly different XML and different experience. Sorry. > > Cheers > > Tibor17 > > > > > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli > > wrote: > > > > > I will get a windows box and try to reproduce. > > > It is weird that on ASF Jenkins the build is passing even on windows > > > > > > Enrico > > > > > > -- Forwarded message - > > > Da: Enrico Olivelli > > > Date: mar 14 mag 2019, 13:58 > > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version > 3.1.0 > > > To: Maven Developers List > > > > > > > > > Eric and Tibor, > > > Thank you so much for your effort in testing Maven Checkstyle Plugin. > > > > > > This is the "official" VOTE thread, here we have to decide if the > staged > > > artifacts are good to be released or not. > > > > > > Feel free to cast a -1 if you think that the staged artifacts are not > > > "stable" or there is any showstopper problem for the release. > > > > > > Let's move this discussion to a separate thread, something like > > "Validation > > > failures in Windows over current checkstyle plugin master branch") > > > > > > Enrico > > > > > > > > > > > > > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja < > > mindcoo...@gmail.com> > > > ha scritto: > > > > > > > Tried overriding line.separator when running using > > -Dline.separator="\n", > > > > but then the builds fails (early) in maven-plugin-plugin: > > > > [ERROR] Failed to execute goal > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor > > > > (default-descriptor) on project maven-checkstyle-plugin: Execution > > > > default-descriptor of goal > > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: > > > > Requested line separator is invalid. -> [Help 1] > > > > [ERROR] > > > > [ERROR] To see the full stack trace of the errors, re-run Maven with > > the > > > -e > > > > switch. > > > > [ERROR] Re-run Maven using the -X switch to enable full debug > logging. > > > > [ERROR] > > > > [ERROR] For more information about the errors and possible solutions, > > > > please read the following articles: > > > > [ERROR] [Help 1] > > > > > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > > > > > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff > > > > upgradeable...), but same error > > > > > > > > I also happened to notice this (probably unrelated, but wanted to > bring > > > it > > > > to attention anyway so it can be fixed) warning: > > > > [INFO] java-annotations mojo extractor found 4 mojo descriptors. > > > > [WARNING] > > > > > > > > Unexpected situation: destinationDirectory not defined in > > > > maven-plugin-help.properties during help mojo source generation but > > > > expected during XML descriptor generation. > > > > [WARNING] Please check helpmojo goal version used in previous build > > > phase. > > > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a > > > clean > > > > build at least once. > > > > [WARNING] Trying default location: target\generated-sources\plugin > > > > > > > > - Eric L > > > > > > > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja > > > wrote: > > > > > > > > > I tried bumping checkstyle to 8.20, plus a few of the plexus > > > > dependencies, > > > > > but that just brought an additional
Re: Latest snapshot build (archive, not Maven artifact)
Up! What's blocking for publication of snapshots from master to some snapshot repo? I'd gladly try to help.
Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)
Just to inform you that this problem has been resolved in version 8.21 of checkstyle, which was just released, and I've confirmed the fix works by running the ITs on the checkstyle-plugin (checked out master on Cygwin). There are two other failures, though (was one failure with 8.20 if I recall correctly, apart from the EOL issue still present in that version). https://github.com/checkstyle/checkstyle/issues/4073 - Eric L On Thu, May 16, 2019 at 1:33 AM Tibor Digana wrote: > Enrico, I checked the Checkstyle rules again (default value = system) and > Robert is right, please adjust the IT sources on the fly. > Not sure why INFRA or Jenkins sets the Windows EOL to LF. > Therefore we could not find this issue in version 3.0.0 (Jan 04) because > the IT was created on Jan 17 and we run it on local Windows the first time. > > The library is fine. I used several old versions of the plugin having > identical results. > Few links: > > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile > > http://checkstyle.sourceforge.net/google_style.html > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml > > https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml > > I expected platform independence because my company used sun_checks.xml on > Windows with Unix EOL in Git/IDE without this problem. > The company improved sun_checks.xml long time ago, so I realized that later > that it is slightly different XML and different experience. Sorry. > Cheers > Tibor17 > > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli > wrote: > > > I will get a windows box and try to reproduce. > > It is weird that on ASF Jenkins the build is passing even on windows > > > > Enrico > > > > -- Forwarded message - > > Da: Enrico Olivelli > > Date: mar 14 mag 2019, 13:58 > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0 > > To: Maven Developers List > > > > > > Eric and Tibor, > > Thank you so much for your effort in testing Maven Checkstyle Plugin. > > > > This is the "official" VOTE thread, here we have to decide if the staged > > artifacts are good to be released or not. > > > > Feel free to cast a -1 if you think that the staged artifacts are not > > "stable" or there is any showstopper problem for the release. > > > > Let's move this discussion to a separate thread, something like > "Validation > > failures in Windows over current checkstyle plugin master branch") > > > > Enrico > > > > > > > > > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja < > mindcoo...@gmail.com> > > ha scritto: > > > > > Tried overriding line.separator when running using > -Dline.separator="\n", > > > but then the builds fails (early) in maven-plugin-plugin: > > > [ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor > > > (default-descriptor) on project maven-checkstyle-plugin: Execution > > > default-descriptor of goal > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: > > > Requested line separator is invalid. -> [Help 1] > > > [ERROR] > > > [ERROR] To see the full stack trace of the errors, re-run Maven with > the > > -e > > > switch. > > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > > [ERROR] > > > [ERROR] For more information about the errors and possible solutions, > > > please read the following articles: > > > [ERROR] [Help 1] > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > > > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff > > > upgradeable...), but same error > > > > > > I also happened to notice this (probably unrelated, but wanted to bring > > it > > > to attention anyway so it can be fixed) warning: > > > [INFO] java-annotations mojo extractor found 4 mojo descriptors. > > > [WARNING] > > > > > > Unexpected situation: destinationDirectory not defined in > > > maven-plugin-help.properties during help mojo source generation but > > > expected during XML descriptor generation. > > > [WARNING] Please check helpmojo goal version used in previous build > > phase. > > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a > > clean > > > build at least once. > > > [WARNING] Trying default location: target\generated-sources\plugin > > > > > > - Eric L > > > > > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja > > wrote: > > > > > > > I tried bumping checkstyle to 8.20, plus a few of the plexus > > > dependencies, > > > > but that just brought an additional failure... (to > > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml) :-) > > > > > > > > I suppose the problem might be that the files has linux-style line > > breaks > > > > (this is desired for me, I don't want to convert to windows-style > line > > > > breaks locally), but the test think I should have windows-style line > > > > separators. It seems these files are generated by the tests because I > > >
