Re: [Imaging]: Integrating JIRA issues with GitHub issues
Hi, Unfortunately I don't think that's possible. The code is hosted at ASF, and synced with GitHub. The issues are also hosted at ASF infra, but I don't believe we have any sort of issues-mirroring service available at ASF. I agree it would be convenient to have everything in a single place, but I find it hard as the way GitHub and JIRA handle issues is very different (e.g. both have labels, but JIRA has custom fields, so should we add a comment any time a custom field value such as fixVersion is updated in the JIRA issue? Or would we have a mapping in this case, and link with milestone in GitHub?). Cheers Bruno On Sunday, 16 August 2020, 3:03:03 pm NZST, Shukant Pal wrote: I see that bugs are tracked using JIRA. Is there any chance you could sync GitHub issues with the JIRA bug tracker. As far as I can see, you would normally browse the code at GitHub & having all the issues with it would be fantastic. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Imaging]: Integrating JIRA issues with GitHub issues
I see that bugs are tracked using JIRA. Is there any chance you could sync GitHub issues with the JIRA bug tracker. As far as I can see, you would normally browse the code at GitHub & having all the issues with it would be fantastic. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING][DAEMON] Update Java 6 to 7
I use Daemon at work quite a bit so yes I've done more than look at it ;-) Right now we can't tell if it will even build and run on Java > 11 since as of Java 12 onwards javac doesn't support building for Java 6. So this -1 is not a good technical argument IMO. The fact that we can't even run a build on the current Java version (14) *is* a good argument moving to Java 7. Gary On Sat, Aug 15, 2020, 16:14 sebb wrote: > On Sat, 15 Aug 2020 at 19:01, Gary Gregory wrote: > > > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote: > > > > > On 10/08/2020 17:26, Gary Gregory wrote: > > > > As recently done for [EMAIL], I propose we update [LOGGING] and > [DAEMON] > > > > from Java 6 to 7 to streamline building on CIs. > > > > > > -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated > > > requirement to run on Java 6. > > > > > > > Yikes ;-) how long is rein in antiquity planned to last? ;-) > > > > We might need a branch for Tomcat so the project can move ahead in a more > > modern setting IMO. > > -1 > > Have you looked at DAEMON recently? > It has just 10 Java files under src/main. > > Is it really worth converting these to require a later version of Java? > > > > > Gary > > > > > > > > Are there any features / bugs in Jira that require this increase? > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
If we want ARM builds for a component, then by all means let's us Travis until GitHub catches up. Gary On Sat, Aug 15, 2020, 16:51 Geoffrey Blake wrote: > Not familiar with Apache CI, but github actions do not support Arm builds. > Arm should be recognized as a first class build target these days. Travis > allows Arm builds so not sure about the reasoning for moving off. > > -Geoff > > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote: > > > Agreed on the GitHub Actions. Neutral about how snapshot sites are > > > > published since there are multiple methods of doing the same thing, > > > > though if that's also simple to set up via the action to commit the > > > > output to the gh-pages branch, I'd say go for it! > > > > > > > > On Sat, 15 Aug 2020 at 13:07, Gary Gregory > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > In order to ease maintenance, I propose that we drop Travis CI in favor > > of > > > > > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like > plenty > > > > > to me. The exception would be a component with an existing complex > Travis > > > > > build that was not or cannot be reproduced in GitHub Actions. > > > > > > > > > > Looking ahead, I think we should consider publishing SNAPSHOT sites to > > > > > GitHub.io. > > > > > > > > > > Gary > > > > > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
"When you say pushing SNAPSHOT to github.io would that be a nightly or weekly or merge triggered releases?" Same as normal build triggers: commits. Gary On Sat, Aug 15, 2020, 17:30 John Patrick wrote: > Personally I wouldn't use GitHub Actions, it seems wrong coupling > yourself to what is hosting your code. I'm not saying anything is > wrong with GitHub Actions it just feels like vendor lock in. > > When you say pushing SNAPSHOT to github.io would that be a nightly or > weekly or merge triggered releases? > > John > > > On Sat, 15 Aug 2020 at 22:09, Gilles Sadowski > wrote: > > > > 2020-08-15 22:51 UTC+02:00, Geoffrey Blake : > > > Not familiar with Apache CI, but github actions do not support Arm > builds. > > > Arm should be recognized as a first class build target these days. > Travis > > > allows Arm builds so not sure about the reasoning for moving off. > > > > Also, is Travis computing time a donation to the ASF? > > If so, we could continue using it for providing "convenience" > > builds for various architectures and thus spare some load on > > the Jenkins cluster, using the latter only for ensuring an > > independent build in a stable environment, and the generation > > of snapshots. > > > > Regards, > > Gilles > > > > > > > > -Geoff > > > > > > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote: > > > > > >> Agreed on the GitHub Actions. Neutral about how snapshot sites are > > >> > > >> published since there are multiple methods of doing the same thing, > > >> > > >> though if that's also simple to set up via the action to commit the > > >> > > >> output to the gh-pages branch, I'd say go for it! > > >> > > >> > > >> > > >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory > > >> wrote: > > >> > > >> > > > >> > > >> > Hi All, > > >> > > >> > > > >> > > >> > In order to ease maintenance, I propose that we drop Travis CI in > favor > > >> of > > >> > > >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like > > >> > plenty > > >> > > >> > to me. The exception would be a component with an existing complex > > >> > Travis > > >> > > >> > build that was not or cannot be reproduced in GitHub Actions. > > >> > > >> > > > >> > > >> > Looking ahead, I think we should consider publishing SNAPSHOT sites > to > > >> > > >> > GitHub.io. > > >> > > >> > > > >> > > >> > Gary > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
Personally I wouldn't use GitHub Actions, it seems wrong coupling yourself to what is hosting your code. I'm not saying anything is wrong with GitHub Actions it just feels like vendor lock in. When you say pushing SNAPSHOT to github.io would that be a nightly or weekly or merge triggered releases? John On Sat, 15 Aug 2020 at 22:09, Gilles Sadowski wrote: > > 2020-08-15 22:51 UTC+02:00, Geoffrey Blake : > > Not familiar with Apache CI, but github actions do not support Arm builds. > > Arm should be recognized as a first class build target these days. Travis > > allows Arm builds so not sure about the reasoning for moving off. > > Also, is Travis computing time a donation to the ASF? > If so, we could continue using it for providing "convenience" > builds for various architectures and thus spare some load on > the Jenkins cluster, using the latter only for ensuring an > independent build in a stable environment, and the generation > of snapshots. > > Regards, > Gilles > > > > > -Geoff > > > > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote: > > > >> Agreed on the GitHub Actions. Neutral about how snapshot sites are > >> > >> published since there are multiple methods of doing the same thing, > >> > >> though if that's also simple to set up via the action to commit the > >> > >> output to the gh-pages branch, I'd say go for it! > >> > >> > >> > >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory > >> wrote: > >> > >> > > >> > >> > Hi All, > >> > >> > > >> > >> > In order to ease maintenance, I propose that we drop Travis CI in favor > >> of > >> > >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like > >> > plenty > >> > >> > to me. The exception would be a component with an existing complex > >> > Travis > >> > >> > build that was not or cannot be reproduced in GitHub Actions. > >> > >> > > >> > >> > Looking ahead, I think we should consider publishing SNAPSHOT sites to > >> > >> > GitHub.io. > >> > >> > > >> > >> > Gary > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING][DAEMON] Update Java 6 to 7
What if you're wanting to use it on Java 14, 15 RC, 16 EA or in 6 months time 17 EA, will they support such an old version? Reading the website; Tomcat 7 needs Java 6 and later and (Java 7 for WebSockets), Tomcat 8 is Java 7 and later Tomcat 9 is Java 8 and later Tomcat 10 is Java 8 and later They are supporting multiple versions and back porting, or merging or cherry-picking changes where applicable. If tomcat finds issues then I'm sure we would put out a support release to fix their issue. What if my project mandates Java 1.5 will commons demon downgrade back to Java 1.5? What makes a downstream project a blocker for upgrading? Do a major version bump and they can keep using the current version they have, they don't have to upgrade if that breaks their application... John On Sat, 15 Aug 2020 at 21:14, sebb wrote: > > On Sat, 15 Aug 2020 at 19:01, Gary Gregory wrote: > > > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote: > > > > > On 10/08/2020 17:26, Gary Gregory wrote: > > > > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON] > > > > from Java 6 to 7 to streamline building on CIs. > > > > > > -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated > > > requirement to run on Java 6. > > > > > > > Yikes ;-) how long is rein in antiquity planned to last? ;-) > > > > We might need a branch for Tomcat so the project can move ahead in a more > > modern setting IMO. > > -1 > > Have you looked at DAEMON recently? > It has just 10 Java files under src/main. > > Is it really worth converting these to require a later version of Java? > > > > > Gary > > > > > > > > Are there any features / bugs in Jira that require this increase? > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
2020-08-15 22:51 UTC+02:00, Geoffrey Blake : > Not familiar with Apache CI, but github actions do not support Arm builds. > Arm should be recognized as a first class build target these days. Travis > allows Arm builds so not sure about the reasoning for moving off. Also, is Travis computing time a donation to the ASF? If so, we could continue using it for providing "convenience" builds for various architectures and thus spare some load on the Jenkins cluster, using the latter only for ensuring an independent build in a stable environment, and the generation of snapshots. Regards, Gilles > > -Geoff > > On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote: > >> Agreed on the GitHub Actions. Neutral about how snapshot sites are >> >> published since there are multiple methods of doing the same thing, >> >> though if that's also simple to set up via the action to commit the >> >> output to the gh-pages branch, I'd say go for it! >> >> >> >> On Sat, 15 Aug 2020 at 13:07, Gary Gregory >> wrote: >> >> > >> >> > Hi All, >> >> > >> >> > In order to ease maintenance, I propose that we drop Travis CI in favor >> of >> >> > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like >> > plenty >> >> > to me. The exception would be a component with an existing complex >> > Travis >> >> > build that was not or cannot be reproduced in GitHub Actions. >> >> > >> >> > Looking ahead, I think we should consider publishing SNAPSHOT sites to >> >> > GitHub.io. >> >> > >> >> > Gary >> >> >> >> >> >> >> >> -- >> >> Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
Not familiar with Apache CI, but github actions do not support Arm builds. Arm should be recognized as a first class build target these days. Travis allows Arm builds so not sure about the reasoning for moving off. -Geoff On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote: > Agreed on the GitHub Actions. Neutral about how snapshot sites are > > published since there are multiple methods of doing the same thing, > > though if that's also simple to set up via the action to commit the > > output to the gh-pages branch, I'd say go for it! > > > > On Sat, 15 Aug 2020 at 13:07, Gary Gregory wrote: > > > > > > Hi All, > > > > > > In order to ease maintenance, I propose that we drop Travis CI in favor > of > > > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like plenty > > > to me. The exception would be a component with an existing complex Travis > > > build that was not or cannot be reproduced in GitHub Actions. > > > > > > Looking ahead, I think we should consider publishing SNAPSHOT sites to > > > GitHub.io. > > > > > > Gary > > > > > > > > -- > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > >
Re: [LOGGING][DAEMON] Update Java 6 to 7
On Sat, 15 Aug 2020 at 19:01, Gary Gregory wrote: > > On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote: > > > On 10/08/2020 17:26, Gary Gregory wrote: > > > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON] > > > from Java 6 to 7 to streamline building on CIs. > > > > -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated > > requirement to run on Java 6. > > > > Yikes ;-) how long is rein in antiquity planned to last? ;-) > > We might need a branch for Tomcat so the project can move ahead in a more > modern setting IMO. -1 Have you looked at DAEMON recently? It has just 10 Java files under src/main. Is it really worth converting these to require a later version of Java? > Gary > > > > > Are there any features / bugs in Jira that require this increase? > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hi All, I would really prefer we do not do this. Note that there is no blocking issue to fix here. When you build in a CI, you know what OS you get and Maven is pre-configured, no mystery. My view here is that it would be the CI's job to toggle the Maven version just like a CI does for Java, the OS, and everything else a CI build uses. What I can see us doing is going to GitHub and asking for a actions/setup-maven just like there is a actions/setup-java. If we do anything we should create our own actions/setup-maven. I personally do not want to see or maintain copies of these files in 20+ repositories; it seems like a giant maintenance headache to me. I don't want to consider why this component does it this way and this other one that way. I've been aiming for GitHub CI builds to be as consistent as possible FWIW. Gary On Sat, Aug 15, 2020 at 1:22 PM Rob Tompkins wrote: > Hello all, > > I first want to thank John for bringing these points to light as I think > we can have quite a healthy discussion about the CI/CD philosophy employed > by the project (Apache Commons) generally. Furthermore, I hope to set > precedent with intent and direction with the following comments. Note, > these are merely ideas yet to be set in stone. I would propose that we > draft the ideas using this thread and potentially have a PMC > level/committer/user level [POLL] (to be handled on the dev@ list) on > direction following debate and drafting. I quite enjoy suggestions and > ideas from all areas and take quite seriously the suggestions of any user > of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, > I’m quite hesitant to use it in CI. Note, we intentionally have NO > continuous deployment as we GPG sign all of our artifacts locally, and we > intentionally do not publish snapshots as we don’t want people actively > consuming our inflight development work. We use beta releases instead for > this purpose. Furthermore, all of our CI processes have explicit > declarations for a various array of different java versions (open to > varying across maven versions here). But do note that they are indeed all > quite hard coded in our github actions files, towards which we are > migrating. > > All that said, I do indeed see quite a good argument for including ./mvnw > in the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here > that we only want to install the latest version of Apache Maven as we very > much do not want to be prescriptive with our java versioning. We, in fact, > work quite hard to maintain backwards compatibility to the oldest freely > available supported (long-term-support) version of java. > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to > it’s latest version in said .properties files. > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick > wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hello. Le sam. 15 août 2020 à 19:22, Rob Tompkins a écrit : > > Hello all, > > I first want to thank John for bringing these points to light as I think we > can have quite a healthy discussion about the CI/CD philosophy employed by > the project (Apache Commons) generally. Furthermore, I hope to set precedent > with intent and direction with the following comments. Note, these are merely > ideas yet to be set in stone. I would propose that we draft the ideas using > this thread and potentially have a PMC level/committer/user level [POLL] (to > be handled on the dev@ list) on direction following debate and drafting. I > quite enjoy suggestions and ideas from all areas and take quite seriously the > suggestions of any user of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, I’m > quite hesitant to use it in CI. I didn't know about "mvnw" until today, and it still doesn't strike me as necessary (but I could be convinced by more concrete examples). Just trusting your experience, I'd be reluctant to change yet another aspect of our handling of projects (unless it is part of a rationalization effort). > Note, we intentionally have NO continuous deployment as we GPG sign all of > our artifacts locally, and we intentionally do not publish snapshots as we > don’t want people actively consuming our inflight development work. Not entirely correct: Some projects do publish snapshots. And they were sometimes proposed as a way to check that some bug had been fixed. > We use beta releases instead for this purpose. Unless I'm mistaken, the purpose is different: a release (beta or otherwise) comes with certain checks which snapshots do not have (possibly making the latter unacceptable in some environments). > Furthermore, all of our CI processes have explicit declarations for a various > array of different java versions (open to varying across maven versions > here). But do note that they are indeed all quite hard coded in our github > actions files, towards which we are migrating. When was this decided? > All that said, I do indeed see quite a good argument for including ./mvnw in > the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here that > we only want to install the latest version of Apache Maven as we very much do > not want to be prescriptive with our java versioning. We, in fact, work quite > hard to maintain backwards compatibility to the oldest freely available > supported (long-term-support) version of java. I'm a bit lost (wrt what you wrote above): Is "mvnw" good or not? IIUC (?), it allows specifying (bundle?) a specific version of maven. How is it better than just note somewhere the known issues (and fix them ASAP)? > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to it’s > latest version in said .properties files. Completely lost now. Either people who want (for all the good reasons) to move to an all-GitHub solution should lay out their plan, or we should vote, component-wise, on the new sets of requirements, a.o. having a GitHub account in order to be able to manage said component. Regards, Gilles > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] cicd philosophy (was: Re: Introducing Maven Wrapper)
I'll note that at least from a Jenkins point of view (probably similar with GitHub Actions), it's easier to set up your CI config to use the Maven wrapper script instead of configuring a Maven tool (Jenkins) or using a specific Docker image or similar extra config. We've had a wrapper script in Log4j for a while which is used in our GitHub Actions workflow: https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml Compare to the more complicated configuration for Maven without the wrapper (I hard-coded known paths here instead of using the "tool" DSL, but it's the same idea): https://github.com/apache/logging-pipelines/blob/master/vars/mvn.groovy On Sat, 15 Aug 2020 at 12:22, Rob Tompkins wrote: > > Hello all, > > I first want to thank John for bringing these points to light as I think we > can have quite a healthy discussion about the CI/CD philosophy employed by > the project (Apache Commons) generally. Furthermore, I hope to set precedent > with intent and direction with the following comments. Note, these are merely > ideas yet to be set in stone. I would propose that we draft the ideas using > this thread and potentially have a PMC level/committer/user level [POLL] (to > be handled on the dev@ list) on direction following debate and drafting. I > quite enjoy suggestions and ideas from all areas and take quite seriously the > suggestions of any user of the project. :-) > > Having worked with ./mvnw extensively during $work over the last 5 years, I’m > quite hesitant to use it in CI. Note, we intentionally have NO continuous > deployment as we GPG sign all of our artifacts locally, and we intentionally > do not publish snapshots as we don’t want people actively consuming our > inflight development work. We use beta releases instead for this purpose. > Furthermore, all of our CI processes have explicit declarations for a various > array of different java versions (open to varying across maven versions > here). But do note that they are indeed all quite hard coded in our github > actions files, towards which we are migrating. > > All that said, I do indeed see quite a good argument for including ./mvnw in > the project and that is to expedite developer productivity by helping to > install the latest version of Apache Maven, and I want to be clear here that > we only want to install the latest version of Apache Maven as we very much do > not want to be prescriptive with our java versioning. We, in fact, work quite > hard to maintain backwards compatibility to the oldest freely available > supported (long-term-support) version of java. > > I also wonder, but am unsure of the potential here with either GitHub’s > actions or GitHubs dependabot, if we can automate upversioning maven to it’s > latest version in said .properties files. > > Thoughts? > > Cheers, > -Rob > > > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > > > I've raised some pull requests to add the Takari maven wrapper. > > > > The Takari maven wrapper is EOL and will be replaced with the Maven > > Wrapper when Maven v3.7.0 is released. > > > > I've added the Takari version as maven v3.7.0 is not yet out. I've > > been using the Takari maven wrapper for about 4 years now and it has > > reduced a lot of maintenance and setup tasks. > > > > - Maven Wrapper is Maven-As-Code > > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > > installed, so less maintenance tasks > > - Developers don't need to pre install maven > > - Projects control what version of maven to use, maybe a legacy > > project needs v3.3.1 and a newer project needs v3.6.3. A developer > > doesn't need to keep changing their PATH, they just use ./mvnw. > > - Want to check a new version of maven, just change the properties, > > then it can undergo the standard pull request build checks to make > > sure the project works with that version. > > > > The first PR I raised was for commons-code and can be found here > > https://github.com/apache/commons-codec/pull/58 > > > > I've also done similar or; > > commons-collections > > commons-configuration > > commons-io > > commons-lang > > commons-parent > > httpcomponent-client > > httpcomponent-core > > httpcomponent-parent > > > > John > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Drop Travis in favor of Apache CI and GitHub Actions
Agreed on the GitHub Actions. Neutral about how snapshot sites are published since there are multiple methods of doing the same thing, though if that's also simple to set up via the action to commit the output to the gh-pages branch, I'd say go for it! On Sat, 15 Aug 2020 at 13:07, Gary Gregory wrote: > > Hi All, > > In order to ease maintenance, I propose that we drop Travis CI in favor of > Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like plenty > to me. The exception would be a component with an existing complex Travis > build that was not or cannot be reproduced in GitHub Actions. > > Looking ahead, I think we should consider publishing SNAPSHOT sites to > GitHub.io. > > Gary -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ALL] Drop Travis in favor of Apache CI and GitHub Actions
Hi All, In order to ease maintenance, I propose that we drop Travis CI in favor of Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like plenty to me. The exception would be a component with an existing complex Travis build that was not or cannot be reproduced in GitHub Actions. Looking ahead, I think we should consider publishing SNAPSHOT sites to GitHub.io. Gary
Re: [LOGGING][DAEMON] Update Java 6 to 7
On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote: > On 10/08/2020 17:26, Gary Gregory wrote: > > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON] > > from Java 6 to 7 to streamline building on CIs. > > -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated > requirement to run on Java 6. > Yikes ;-) how long is rein in antiquity planned to last? ;-) We might need a branch for Tomcat so the project can move ahead in a more modern setting IMO. Gary > > Are there any features / bugs in Jira that require this increase? > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[all] cicd philosophy (was: Re: Introducing Maven Wrapper)
Hello all, I first want to thank John for bringing these points to light as I think we can have quite a healthy discussion about the CI/CD philosophy employed by the project (Apache Commons) generally. Furthermore, I hope to set precedent with intent and direction with the following comments. Note, these are merely ideas yet to be set in stone. I would propose that we draft the ideas using this thread and potentially have a PMC level/committer/user level [POLL] (to be handled on the dev@ list) on direction following debate and drafting. I quite enjoy suggestions and ideas from all areas and take quite seriously the suggestions of any user of the project. :-) Having worked with ./mvnw extensively during $work over the last 5 years, I’m quite hesitant to use it in CI. Note, we intentionally have NO continuous deployment as we GPG sign all of our artifacts locally, and we intentionally do not publish snapshots as we don’t want people actively consuming our inflight development work. We use beta releases instead for this purpose. Furthermore, all of our CI processes have explicit declarations for a various array of different java versions (open to varying across maven versions here). But do note that they are indeed all quite hard coded in our github actions files, towards which we are migrating. All that said, I do indeed see quite a good argument for including ./mvnw in the project and that is to expedite developer productivity by helping to install the latest version of Apache Maven, and I want to be clear here that we only want to install the latest version of Apache Maven as we very much do not want to be prescriptive with our java versioning. We, in fact, work quite hard to maintain backwards compatibility to the oldest freely available supported (long-term-support) version of java. I also wonder, but am unsure of the potential here with either GitHub’s actions or GitHubs dependabot, if we can automate upversioning maven to it’s latest version in said .properties files. Thoughts? Cheers, -Rob > On Aug 15, 2020, at 9:45 AM, John Patrick wrote: > > I've raised some pull requests to add the Takari maven wrapper. > > The Takari maven wrapper is EOL and will be replaced with the Maven > Wrapper when Maven v3.7.0 is released. > > I've added the Takari version as maven v3.7.0 is not yet out. I've > been using the Takari maven wrapper for about 4 years now and it has > reduced a lot of maintenance and setup tasks. > > - Maven Wrapper is Maven-As-Code > - CI/CD, your docker images or Jenkins slaves no longer need maven pre > installed, so less maintenance tasks > - Developers don't need to pre install maven > - Projects control what version of maven to use, maybe a legacy > project needs v3.3.1 and a newer project needs v3.6.3. A developer > doesn't need to keep changing their PATH, they just use ./mvnw. > - Want to check a new version of maven, just change the properties, > then it can undergo the standard pull request build checks to make > sure the project works with that version. > > The first PR I raised was for commons-code and can be found here > https://github.com/apache/commons-codec/pull/58 > > I've also done similar or; > commons-collections > commons-configuration > commons-io > commons-lang > commons-parent > httpcomponent-client > httpcomponent-core > httpcomponent-parent > > John > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING][DAEMON] Update Java 6 to 7
On 10/08/2020 17:26, Gary Gregory wrote: > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON] > from Java 6 to 7 to streamline building on CIs. -1 for DAEMON. Tomcat 7 depends on it and has a specification mandated requirement to run on Java 6. Are there any features / bugs in Jira that require this increase? Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Introducing Maven Wrapper
I've raised some pull requests to add the Takari maven wrapper. The Takari maven wrapper is EOL and will be replaced with the Maven Wrapper when Maven v3.7.0 is released. I've added the Takari version as maven v3.7.0 is not yet out. I've been using the Takari maven wrapper for about 4 years now and it has reduced a lot of maintenance and setup tasks. - Maven Wrapper is Maven-As-Code - CI/CD, your docker images or Jenkins slaves no longer need maven pre installed, so less maintenance tasks - Developers don't need to pre install maven - Projects control what version of maven to use, maybe a legacy project needs v3.3.1 and a newer project needs v3.6.3. A developer doesn't need to keep changing their PATH, they just use ./mvnw. - Want to check a new version of maven, just change the properties, then it can undergo the standard pull request build checks to make sure the project works with that version. The first PR I raised was for commons-code and can be found here https://github.com/apache/commons-codec/pull/58 I've also done similar or; commons-collections commons-configuration commons-io commons-lang commons-parent httpcomponent-client httpcomponent-core httpcomponent-parent John - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Jenkins: Who has not migrated yet?
> > >> >> Note that commons-beanutils last successful build was 2 years ago. It has > been failing when trying to clean the staging area: > > [ERROR] Failed to execute goal > org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) > on project commons-beanutils2: Failed to commit files: null [null] -> [Help 1] > > > I have tried a build on the new Jenkins CI. If it fails then I'll disable > it. > It failed. If anyone cares to investigate then you can look at: https://ci-builds.apache.org/job/Commons/job/commons-beanutils/1/console For now I have disabled the job. Alex
Re: [All] Jenkins: Who has not migrated yet?
On Fri, 14 Aug 2020 at 16:04, Alex Herbert wrote: > > I did not move all the old jenkins jobs over for all the projects [2]. > However some of the old jenkins jobs deployed snapshots when successful > using the deploy goal of maven. A quick investigation lists these that do > snapshot deployment (via the deploy goal): > > commons-rng > commons-math * > commons-dbutils * > commons-numbers > commons-geometry > commons-beanutils * > commons-statistics > commons-codec * > I have also migrated the jobs setup to perform a snapshot deployment: commons-codec commons-beanutils I did not migrate commons-dbutils as that project was disabled. The last build was over 3 years ago so snapshot deployment was not current functionality. Note that commons-beanutils last successful build was 2 years ago. It has been failing when trying to clean the staging area: [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-beanutils2: Failed to commit files: null [null] -> [Help 1] I have tried a build on the new Jenkins CI. If it fails then I'll disable it. Alex
