Re: [VOTE] Release Apache Maven Source Plugin version 3.2.1
ping Le lundi 16 décembre 2019, 19:37:00 CET Hervé BOUTEMY a écrit : > Hi, > > We solved 2 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924 > rsion=12346480=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1545/ > https://repository.apache.org/content/repositories/maven-1545/org/apache/mav > en/plugins/maven-source-plugin/3.2.1/maven-source-plugin-3.2.1-source-releas > e.zip > > Source release checksum(s): > maven-source-plugin-3.2.1-source-release.zip sha512: > 4d7252839cc74dae8100a47adadbe6fc2c8f4d57e930fa695e4e6c75a8571b1246a63aa25de > 0cf2d73601e599faea2a31be43b1fe442e36d463702d885ccf8b7 > > Staging site: > https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-antrun-plugin
Hi, MANTRUN-221 resolves a bug introduced by MANTRUN-178, where it incorrectly assumes that mavenProject.getProperties() will contain all properties present in the session. The PR is merged to master after it is approved. Please release the new version of maven-antrun-plugin as soon as possible. Thanks, Shivaji Thanneeru 610-314-9159
Re: maven-antrun-plugin
Ok, no problem. On Fri, Dec 20, 2019 at 11:44 AM Enrico Olivelli wrote: > Shivaji, > Unfortunately I don't have time these days, I hope any other committer can > volunteer > > If no one volunteers I can pick this up, but in January > > Enrico > > Il ven 20 dic 2019, 17:12 Shivaji Thanneeru > ha scritto: > >> Hi, >> MANTRUN-221 resolves a bug introduced by MANTRUN-178, where it incorrectly >> assumes that mavenProject.getProperties() will contain all properties >> present in the session. The PR is merged to master after it is >> approved. >> Please release the new version of maven-antrun-plugin as soon as possible. >> >> Thanks, >> >> Shivaji Thanneeru >> 610-314-9159 >> >> -- Thanks, Shivaji Thanneeru 610-314-9159
Re: maven-antrun-plugin
Shivaji, Unfortunately I don't have time these days, I hope any other committer can volunteer If no one volunteers I can pick this up, but in January Enrico Il ven 20 dic 2019, 17:12 Shivaji Thanneeru ha scritto: > Hi, > MANTRUN-221 resolves a bug introduced by MANTRUN-178, where it incorrectly > assumes that mavenProject.getProperties() will contain all properties > present in the session. The PR is merged to master after it is approved. > Please release the new version of maven-antrun-plugin as soon as possible. > > Thanks, > > Shivaji Thanneeru > 610-314-9159 > >
Re: Second for --fail-on-severity
Approved on github +1 Enrico Il giorno mer 18 dic 2019 alle ore 23:53 Robert Scholte < rfscho...@apache.org> ha scritto: > Please review (and support) the following: > https://issues.apache.org/jira/browse/MNG-6065 > > > https://github.com/apache/maven/pull/287 > > https://github.com/apache/maven-integration-testing/pull/48 > > > https://builds.apache.org/job/maven-box/job/maven/job/MNG-6065/ > > > thanks, > Robert
Re: Yearly JIRA cleanup
sorry for typo, in the backlog they should not be closed because they are serious bugs and need to be fixed. On Fri, Dec 20, 2019 at 1:11 PM Tibor Digana wrote: > I want to review the closed issues as well i would like to come up with > those which should be reopened to a certain release version. > I guess the release version should be set in such case. > We have also backlog version and that's the place where the issues should > be closed be the version has not been proposed yet. > > On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold > wrote: > >> One thing we should try going forward is be more ready to won't fix >> and close bugs and RFEs we disagree with. I've seen several examples >> where the comments indicate the maintainers did not agree with the >> issue, but it still wasn't closed. E.g. >> >> https://issues.apache.org/jira/browse/SUREFIRE-1227 >> >> Closing an issue is not irrevocable. Issues can always be reopened, if >> the reporter or anyone else disagrees. Indeed it is more respectful to >> reporters to be politely honest with them about our true objections, >> rather than simply ignoring the issue and not responding. >> >> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold >> wrote: >> > >> > While working through the bugs I found this interesting bit of history: >> > >> > >> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 >> > >> > It seems like we've been here before. Some of the bugs that were >> > autoclosed then were reopened and are now scheduled for autoclose >> > again. Any thoughts about how we might update our processes to avoid >> > getting into this situation again? >> > >> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov >> wrote: >> > > >> > > Hi folks, >> > > >> > > after at least one year of silence, I'd like to perform another JIRA >> > > issue cleanup for issues which have been not touched for more than >> three >> > > years. >> > > >> > > Query: >> > > >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC >> > > >> > > Stats: >> > > >> > > 567 issues not touched for more than three years >> > > of which >> > > * 68 have fix version set >> > > * 36 were already reopened, should they be excluded? >> > > * 1 in progress by Karl >> > > >> > > Type breakdown: >> > > * 200 bugs >> > > * 164 improvements >> > > * 72 new features >> > > * 6 subtasks >> > > * 13 tasks >> > > * 12 wishes >> > > >> > > If there are issues still valid for you please leave a comment on the >> > > issue and they will not appear in the query anymore. >> > > Please also raise your voice if you have anything to discuss. >> > > >> > > If the issue is not modified or no objection has been raised, I will >> > > autoclose those issues with a comment by 2019-12-30. >> > > >> > > Michael >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: dev-h...@maven.apache.org >> > > >> > >> > >> > -- >> > Elliotte Rusty Harold >> > elh...@ibiblio.org >> >> >> >> -- >> Elliotte Rusty Harold >> elh...@ibiblio.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
Re: Yearly JIRA cleanup
I want to review the closed issues as well i would like to come up with those which should be reopened to a certain release version. I guess the release version should be set in such case. We have also backlog version and that's the place where the issues should be closed be the version has not been proposed yet. On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold wrote: > One thing we should try going forward is be more ready to won't fix > and close bugs and RFEs we disagree with. I've seen several examples > where the comments indicate the maintainers did not agree with the > issue, but it still wasn't closed. E.g. > > https://issues.apache.org/jira/browse/SUREFIRE-1227 > > Closing an issue is not irrevocable. Issues can always be reopened, if > the reporter or anyone else disagrees. Indeed it is more respectful to > reporters to be politely honest with them about our true objections, > rather than simply ignoring the issue and not responding. > > On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold > wrote: > > > > While working through the bugs I found this interesting bit of history: > > > > > https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 > > > > It seems like we've been here before. Some of the bugs that were > > autoclosed then were reopened and are now scheduled for autoclose > > again. Any thoughts about how we might update our processes to avoid > > getting into this situation again? > > > > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov > wrote: > > > > > > Hi folks, > > > > > > after at least one year of silence, I'd like to perform another JIRA > > > issue cleanup for issues which have been not touched for more than > three > > > years. > > > > > > Query: > > > > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC > > > > > > Stats: > > > > > > 567 issues not touched for more than three years > > > of which > > > * 68 have fix version set > > > * 36 were already reopened, should they be excluded? > > > * 1 in progress by Karl > > > > > > Type breakdown: > > > * 200 bugs > > > * 164 improvements > > > * 72 new features > > > * 6 subtasks > > > * 13 tasks > > > * 12 wishes > > > > > > If there are issues still valid for you please leave a comment on the > > > issue and they will not appear in the query anymore. > > > Please also raise your voice if you have anything to discuss. > > > > > > If the issue is not modified or no objection has been raised, I will > > > autoclose those issues with a comment by 2019-12-30. > > > > > > Michael > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Yearly JIRA cleanup
Please share the new query for this. It would give me fewer issues to look at. By the way, I've chopped the original list from over four hundred to just over two hundred, learned a lot about Maven in the process, found one or two gems that have serious impact at my day job, and identified one truly scary security issue someone badly needs to look at. On Fri, Dec 20, 2019 at 6:42 AM Michael Osipov wrote: > > I will exlude those. It does not makes sense to close/reopen again. > > Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold: > > While working through the bugs I found this interesting bit of history: > > > > https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 > > > > It seems like we've been here before. Some of the bugs that were > > autoclosed then were reopened and are now scheduled for autoclose > > again. Any thoughts about how we might update our processes to avoid > > getting into this situation again? > > > > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: > >> > >> Hi folks, > >> > >> after at least one year of silence, I'd like to perform another JIRA > >> issue cleanup for issues which have been not touched for more than three > >> years. > >> > >> Query: > >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC > >> > >> Stats: > >> > >> 567 issues not touched for more than three years > >> of which > >> * 68 have fix version set > >> * 36 were already reopened, should they be excluded? > >> * 1 in progress by Karl > >> > >> Type breakdown: > >> * 200 bugs > >> * 164 improvements > >> * 72 new features > >> * 6 subtasks > >> * 13 tasks > >> * 12 wishes > >> > >> If there are issues still valid for you please leave a comment on the > >> issue and they will not appear in the query anymore. > >> Please also raise your voice if you have anything to discuss. > >> > >> If the issue is not modified or no objection has been raised, I will > >> autoclose those issues with a comment by 2019-12-30. > >> > >> Michael > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Yearly JIRA cleanup
One thing we should try going forward is be more ready to won't fix and close bugs and RFEs we disagree with. I've seen several examples where the comments indicate the maintainers did not agree with the issue, but it still wasn't closed. E.g. https://issues.apache.org/jira/browse/SUREFIRE-1227 Closing an issue is not irrevocable. Issues can always be reopened, if the reporter or anyone else disagrees. Indeed it is more respectful to reporters to be politely honest with them about our true objections, rather than simply ignoring the issue and not responding. On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold wrote: > > While working through the bugs I found this interesting bit of history: > > https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 > > It seems like we've been here before. Some of the bugs that were > autoclosed then were reopened and are now scheduled for autoclose > again. Any thoughts about how we might update our processes to avoid > getting into this situation again? > > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: > > > > Hi folks, > > > > after at least one year of silence, I'd like to perform another JIRA > > issue cleanup for issues which have been not touched for more than three > > years. > > > > Query: > > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC > > > > Stats: > > > > 567 issues not touched for more than three years > > of which > > * 68 have fix version set > > * 36 were already reopened, should they be excluded? > > * 1 in progress by Karl > > > > Type breakdown: > > * 200 bugs > > * 164 improvements > > * 72 new features > > * 6 subtasks > > * 13 tasks > > * 12 wishes > > > > If there are issues still valid for you please leave a comment on the > > issue and they will not appear in the query anymore. > > Please also raise your voice if you have anything to discuss. > > > > If the issue is not modified or no objection has been raised, I will > > autoclose those issues with a comment by 2019-12-30. > > > > Michael > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Yearly JIRA cleanup
I will exlude those. It does not makes sense to close/reopen again. Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold: While working through the bugs I found this interesting bit of history: https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 It seems like we've been here before. Some of the bugs that were autoclosed then were reopened and are now scheduled for autoclose again. Any thoughts about how we might update our processes to avoid getting into this situation again? On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: Hi folks, after at least one year of silence, I'd like to perform another JIRA issue cleanup for issues which have been not touched for more than three years. Query: https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC Stats: 567 issues not touched for more than three years of which * 68 have fix version set * 36 were already reopened, should they be excluded? * 1 in progress by Karl Type breakdown: * 200 bugs * 164 improvements * 72 new features * 6 subtasks * 13 tasks * 12 wishes If there are issues still valid for you please leave a comment on the issue and they will not appear in the query anymore. Please also raise your voice if you have anything to discuss. If the issue is not modified or no objection has been raised, I will autoclose those issues with a comment by 2019-12-30. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Yearly JIRA cleanup
While working through the bugs I found this interesting bit of history: https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 It seems like we've been here before. Some of the bugs that were autoclosed then were reopened and are now scheduled for autoclose again. Any thoughts about how we might update our processes to avoid getting into this situation again? On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: > > Hi folks, > > after at least one year of silence, I'd like to perform another JIRA > issue cleanup for issues which have been not touched for more than three > years. > > Query: > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC > > Stats: > > 567 issues not touched for more than three years > of which > * 68 have fix version set > * 36 were already reopened, should they be excluded? > * 1 in progress by Karl > > Type breakdown: > * 200 bugs > * 164 improvements > * 72 new features > * 6 subtasks > * 13 tasks > * 12 wishes > > If there are issues still valid for you please leave a comment on the > issue and they will not appear in the query anymore. > Please also raise your voice if you have anything to discuss. > > If the issue is not modified or no objection has been raised, I will > autoclose those issues with a comment by 2019-12-30. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Eclipse import
Hi, Since things work with plain Maven, such questions would better be directed to the m2e-...@eclipse.org mailing-list. On Thu, Dec 19, 2019 at 11:35 PM Elliotte Rusty Harold wrote: > There seems to be something I'm missing about importing projects into > Eclipse. How do you perform this import? > I can build them at the command line, but they're full of > errors like > BookModel cannot be resolved to a typeBookContext.java > /doxia-book-renderer/src/main/java/org/apache/maven/doxia/book/context >line 113Java Problem > when I import them into Eclipse. m2e seems really confused about > missing lifecycle configurations. Those classes like BookModel are generated-source from modello plugin. By default and unless you install a m2e/modello connector or mark the lifecycle step as "execute", the step will be ignored, and m2e won't generate the sources in your IDE. >From here, there are several possible approaches: * Install a m2e/modello connector like https://github.com/tesla/m2eclipse-modello , you can hopefully achieve that with Window > Help > Preferences > Maven > Discovery > Open Catalog... (not sure it's there though). Note that even without those steps a quick-fix should be available in the pom for the modello plugin suggesting to install appropriate connector * Tentatively, you can configure the m2e lifecycle mapping for modello as "execute" so it will run the source generation on build https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html#execute-plugin-goal * or you can simply just build manually first, then import with m2e. m2e should mark the generated-sources folder as a regular source folder and you should be able to work on the main code referencing classes from this generated-sources folder. In any case, in Eclipse IDE in general, if it says it can't find a class, you can just instruct Eclipse IDE to use a specific folder of your project as a source path: right click on it > Build Path...> Use as source folder. Maybe just doing that is enough for your use-case. HTH
