Re: [VOTE] Redirect github notifications to issues@
+1 Am Di., 19. Feb. 2019 um 22:35 Uhr schrieb Marcelo Vanzin : > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > > If the vote passes, I'll take care of opening an infra ticket > referencing the result. > > -- > Marcelo > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [LANG] Jenkins Pipeline DSL
I'm happy about the positive feedback. I'm currently a little bit busy at work. I hope to be able to spike something at the end of next week. Benedikt Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker : > The DSL allows you to break out into parallel stages or sequential > ones (or both). The log4net Jenkinsfile has an example of building > across multiple agents: > > > https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile > > On Mon, 18 Feb 2019 at 12:44, sebb wrote: > > > > Seems worth trying. > > > > I suggest start with one project (i.e. Lang) and see how well it works. > > > > I assume there will need to be a once-off change to Jenkins to switch > > to using the DSL. > > > > Note that some components have multiple jobs, e.g. for different OSes > and JVMs. > > Does the DSL support such jobs? Or is that still done through the GUI? > > > > S. > > > > On Mon, 18 Feb 2019 at 18:05, Matt Sicker wrote: > > > > > > +1. You could also make a shared library for reuse in commons projects. > > > > > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher > > > wrote: > > > > > > > > +1 to using a pipeline > > > > > > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter: > > > > > Hi all, > > > > > > > > > > I feel like maintaining separate build descriptions on Jenkins is > a PITA. > > > > > Any objections against adopting Jenkins Pipeline DSL for Lang? > > > > > > > > > > Regards, > > > > > Benedikt > > > > > > > > > > > > > > > > > - > > > > 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 > > > > > > > - > > 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: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita < ki...@apache.org>: > Hi all, > Just finished merging a pull request to TEXT-104, where the JaroWinkler > distance was updated. The class was actually computing a text similarity > score, not an edit distance. The user that contributed did a great job > moving the logic into a separate class, then updating the method to return > a distance instead. > Later I realized this would break both behaviour and binary compatibility. > So just wondering what others think. Is it time to gather a few more > issues in text, maybe even consider updating libraries/java/etc, drop > @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert > moving the code to a branch, and update TEXT-104 with a note about the > branch? > This would be a bad signal to the contributor. Do you think it's possible to have both solutions side by side? So we keep the old class with the name an interface, deprecate it and put the new solution in the same package with a different class name? Benedikt > CheersBruno >
Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
> On Feb 20, 2019, at 5:42 AM, Benedikt Ritter wrote: > > Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita < > ki...@apache.org>: > >> Hi all, >> Just finished merging a pull request to TEXT-104, where the JaroWinkler >> distance was updated. The class was actually computing a text similarity >> score, not an edit distance. The user that contributed did a great job >> moving the logic into a separate class, then updating the method to return >> a distance instead. >> Later I realized this would break both behaviour and binary compatibility. >> So just wondering what others think. Is it time to gather a few more >> issues in text, maybe even consider updating libraries/java/etc, drop >> @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert >> moving the code to a branch, and update TEXT-104 with a note about the >> branch? >> > > This would be a bad signal to the contributor. Do you think it's possible > to have both solutions side by side? So we keep the old class with the name > an interface, deprecate it and put the new solution in the same package > with a different class name? I like this idea. What if you added an up-versioned package, running v2 and v1 side by side? Maybe too confusing. You could add v2 to the class name. Also maybe a bad idea. Just some thoughts that ran through my head here. -Rob > > Benedikt > > >> CheersBruno >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Redirect github notifications to issues@
+1 (Note. We still need to have the github messages either land on an email list or generate jira’s for traceability. I almost think that we should have Pull Requests generate jiras.) > On Feb 19, 2019, at 4:35 PM, Marcelo Vanzin > wrote: > > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > > If the vote passes, I'll take care of opening an infra ticket > referencing the result. > > -- > Marcelo > > - > 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: [VOTE] Redirect github notifications to issues@
Is this a LAZY VOTE? Gary On Wed, Feb 20, 2019 at 7:36 AM Rob Tompkins wrote: > +1 > > (Note. We still need to have the github messages either land on an email > list or generate jira’s for traceability. I almost think that we should > have Pull Requests generate jiras.) > > > On Feb 19, 2019, at 4:35 PM, Marcelo Vanzin > wrote: > > > > I'm opening a vote based on recent discussions about the extra noise > > generated by github updates going to dev@. So please vote: > > > > - +1 to redirect github updates of all commons repos to the issues@ list > > - -1 to keep things as is > > > > If the vote passes, I'll take care of opening an infra ticket > > referencing the result. > > > > -- > > Marcelo > > > > - > > 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: [VOTE] Redirect github notifications to issues@
+1 On February 20, 2019 at 08:41:15, Gary Gregory (garydgreg...@gmail.com) wrote: Is this a LAZY VOTE? Gary On Wed, Feb 20, 2019 at 7:36 AM Rob Tompkins wrote: > +1 > > (Note. We still need to have the github messages either land on an email > list or generate jira’s for traceability. I almost think that we should > have Pull Requests generate jiras.) > > > On Feb 19, 2019, at 4:35 PM, Marcelo Vanzin > wrote: > > > > I'm opening a vote based on recent discussions about the extra noise > > generated by github updates going to dev@. So please vote: > > > > - +1 to redirect github updates of all commons repos to the issues@ list > > - -1 to keep things as is > > > > If the vote passes, I'll take care of opening an infra ticket > > referencing the result. > > > > -- > > Marcelo > > > > - > > 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: [VOTE] Redirect github notifications to issues@
+1 On Wed, 20 Feb 2019, 3:05 am Marcelo Vanzin, wrote: > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > > If the vote passes, I'll take care of opening an infra ticket > referencing the result. > > -- > Marcelo > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
I'm fine with either solution, but my preference would be to remove all deprecated stuff and release version 2.0. Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita: Hi all, Just finished merging a pull request to TEXT-104, where the JaroWinkler distance was updated. The class was actually computing a text similarity score, not an edit distance. The user that contributed did a great job moving the logic into a separate class, then updating the method to return a distance instead. Later I realized this would break both behaviour and binary compatibility. So just wondering what others think. Is it time to gather a few more issues in text, maybe even consider updating libraries/java/etc, drop @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert moving the code to a branch, and update TEXT-104 with a note about the branch? CheersBruno - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Redirect github notifications to issues@
On Wed, Feb 20, 2019 at 5:41 AM Gary Gregory wrote: > Is this a LAZY VOTE? Sorry, but not familiar with the semantics of when to call a lazy vs. non-lazy vote. Given the current number of votes, does it matter? Rob: > I almost think that we should have Pull Requests generate jiras. I've seen this set up in a couple of projects and jira becomes unreadable... the updates generated by github are horrible to read. I really don't like them. -- Marcelo - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Github notification and Jira Issues (was: Re: [VOTE] Redirect github notifications to issues@)
Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin: Rob: I almost think that we should have Pull Requests generate jiras. I've seen this set up in a couple of projects and jira becomes unreadable... the updates generated by github are horrible to read. I really don't like them. Imho the way to make it really easy to contribute and raise issues is to use github issues instead of jira. A lot of people already have a github account nowadays. Github issues are indexed by search engines (Apache Jira is not). Contributors do not have to create a jira issue and a pull request for code contributions. Other Apache Projects are already using gitub issues (e.g. https://github.com/apache/bookkeeper). Spring Framework recently migrated from Jira to github issues and wrote about it in detail: https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues Just my two cents, Pascal - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Github notification and Jira Issues (was: Re: [VOTE] Redirect github notifications to issues@)
On Wed, Feb 20, 2019 at 11:13 AM Pascal Schumacher wrote: > Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin: > > Rob: > >> I almost think that we should have Pull Requests generate jiras. > > I've seen this set up in a couple of projects and jira becomes > > unreadable... the updates generated by github are horrible to read. I > > really don't like them. > > Imho the way to make it really easy to contribute and raise issues is to > use github issues instead of jira. Ah, ok, you seem to be talking about something different. In the projects where I saw this, jira was still the main tracker being used by the community. You seem to be talking about jira mostly as an "archiving" tool, so the data is stored in ASF infra. I don't really have an opinion on that. > A lot of people already have a github > account nowadays. Github issues are indexed by search engines (Apache > Jira is not). Contributors do not have to create a jira issue and a pull > request for code contributions. > > Other Apache Projects are already using gitub issues (e.g. > https://github.com/apache/bookkeeper). > > Spring Framework recently migrated from Jira to github issues and wrote > about it in detail: > https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues > > Just my two cents, -- Marcelo - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Redirect github notifications to issues@
+1 Oliver Am 19.02.19 um 22:35 schrieb Marcelo Vanzin: > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > > If the vote passes, I'll take care of opening an infra ticket > referencing the result. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
Are we really ready for a 2.0? How much deprecated stuff do we carry? I plan on taking a closer look at the jarod distance issue tonight or tomorrow. Gary On Wed, Feb 20, 2019, 13:33 Pascal Schumacher I'm fine with either solution, but my preference would be to remove all > deprecated stuff and release version 2.0. > > Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita: > > Hi all, > > Just finished merging a pull request to TEXT-104, where the JaroWinkler > distance was updated. The class was actually computing a text similarity > score, not an edit distance. The user that contributed did a great job > moving the logic into a separate class, then updating the method to return > a distance instead. > > Later I realized this would break both behaviour and binary > compatibility. > > So just wondering what others think. Is it time to gather a few more > issues in text, maybe even consider updating libraries/java/etc, drop > @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert > moving the code to a branch, and update TEXT-104 with a note about the > branch? > > CheersBruno > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[GitHub] kinow opened a new pull request #102: TEXT-104: deprecate JaroWinkler methods for 2.0, and fix clirr report
kinow opened a new pull request #102: TEXT-104: deprecate JaroWinkler methods for 2.0, and fix clirr report URL: https://github.com/apache/commons-text/pull/102 This PR makes the Clirr report pass for 1.7. It keeps the new `JaroWinklerSimilarity` class, but reverts the change in `JaroWinklerDistance`. This way we keep backward feature and binary compatibility. Also added `TODO`'s in the code for 2.0, and if others are OK with this pull request, I will create a Task ticket in JIRA for 2.0, so that when a release manager performs the release, s/he won't forget to look at the TODO and update the code. @saschaszott I feel bad reverting part of your change, but it will be fully available in an upcoming 2.0 release :) Cheers Bruno This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
We have a few things ported from Lang that are deprecated and could be removed. But I have reverted my change in this pull request: https://github.com/apache/commons-text/pull/102 It introduces back the constant and the method removed, and also uses the old code for the edit distance. But the contributed new code is still there (i.e. I did not remove JaroWinklerSimilarity). This was suggested by another user in the pull request for TEXT-104, and I believe Benedikt and Rob also suggested something similar. So if there are no objections I will merge it later this tonight or tomorrow, and create a ticket in JIRA for 2.0 to replace the code, and fix the TODO tags. This way we can leave 2.0 for later, and possibly discuss other major changes like Java modules, changes for Java 11, etc. How does that sound? Bruno On Thursday, 21 February 2019, 10:50:36 am NZDT, Gary Gregory wrote: Are we really ready for a 2.0? How much deprecated stuff do we carry? I plan on taking a closer look at the jarod distance issue tonight or tomorrow. Gary On Wed, Feb 20, 2019, 13:33 Pascal Schumacher I'm fine with either solution, but my preference would be to remove all > deprecated stuff and release version 2.0. > > Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita: > > Hi all, > > Just finished merging a pull request to TEXT-104, where the JaroWinkler > distance was updated. The class was actually computing a text similarity > score, not an edit distance. The user that contributed did a great job > moving the logic into a separate class, then updating the method to return > a distance instead. > > Later I realized this would break both behaviour and binary > compatibility. > > So just wondering what others think. Is it time to gather a few more > issues in text, maybe even consider updating libraries/java/etc, drop > @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert > moving the code to a branch, and update TEXT-104 with a note about the > branch? > > CheersBruno > > > > > - > 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: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
Sounds reasonable. But I suppose the question we should ask ourselves is: do we want a 1.7 or a 2.0? I’d be happy with either. -Rob > On Feb 20, 2019, at 4:56 PM, Bruno P. Kinoshita wrote: > > > We have a few things ported from Lang that are deprecated and could be > removed. > > > But I have reverted my change in this pull request: > > > https://github.com/apache/commons-text/pull/102 > > > It introduces back the constant and the method removed, and also uses the old > code for the edit distance. But the contributed new code is still there (i.e. > I did not remove JaroWinklerSimilarity). > > > This was suggested by another user in the pull request for TEXT-104, and I > believe Benedikt and Rob also suggested something similar. > > > So if there are no objections I will merge it later this tonight or tomorrow, > and create a ticket in JIRA for 2.0 to replace the code, and fix the TODO > tags. > > > This way we can leave 2.0 for later, and possibly discuss other major changes > like Java modules, changes for Java 11, etc. > > > How does that sound? > > > Bruno > > > > > > > On Thursday, 21 February 2019, 10:50:36 am NZDT, Gary Gregory > wrote: > > > > > > Are we really ready for a 2.0? How much deprecated stuff do we carry? > > I plan on taking a closer look at the jarod distance issue tonight or > tomorrow. > > Gary > > On Wed, Feb 20, 2019, 13:33 Pascal Schumacher wrote: > >> I'm fine with either solution, but my preference would be to remove all >> deprecated stuff and release version 2.0. >> >>> Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita: >>> Hi all, >>> Just finished merging a pull request to TEXT-104, where the JaroWinkler >> distance was updated. The class was actually computing a text similarity >> score, not an edit distance. The user that contributed did a great job >> moving the logic into a separate class, then updating the method to return >> a distance instead. >>> Later I realized this would break both behaviour and binary >> compatibility. >>> So just wondering what others think. Is it time to gather a few more >> issues in text, maybe even consider updating libraries/java/etc, drop >> @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert >> moving the code to a branch, and update TEXT-104 with a note about the >> branch? >>> CheersBruno >>> >> >> >> - >> 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
[GitHub] kinow commented on issue #102: TEXT-104: deprecate JaroWinkler methods for 2.0, and fix clirr report
kinow commented on issue #102: TEXT-104: deprecate JaroWinkler methods for 2.0, and fix clirr report URL: https://github.com/apache/commons-text/pull/102#issuecomment-465772523 Clirr report:  This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
Same for me. Just provided a solution to unblock 1.7, but happy to go with a 2.0 if we others agree too. I haven't followed much around the Java modules. But this is a good opportunity to fix anything required for the new Java versions. CheersBruno On Thursday, 21 February 2019, 10:59:11 am NZDT, Rob Tompkins wrote: Sounds reasonable. But I suppose the question we should ask ourselves is: do we want a 1.7 or a 2.0? I’d be happy with either. -Rob > On Feb 20, 2019, at 4:56 PM, Bruno P. Kinoshita wrote: > > > We have a few things ported from Lang that are deprecated and could be > removed. > > > But I have reverted my change in this pull request: > > > https://github.com/apache/commons-text/pull/102 > > > It introduces back the constant and the method removed, and also uses the old > code for the edit distance. But the contributed new code is still there (i.e. > I did not remove JaroWinklerSimilarity). > > > This was suggested by another user in the pull request for TEXT-104, and I > believe Benedikt and Rob also suggested something similar. > > > So if there are no objections I will merge it later this tonight or tomorrow, > and create a ticket in JIRA for 2.0 to replace the code, and fix the TODO > tags. > > > This way we can leave 2.0 for later, and possibly discuss other major changes > like Java modules, changes for Java 11, etc. > > > How does that sound? > > > Bruno > > > > > > > On Thursday, 21 February 2019, 10:50:36 am NZDT, Gary Gregory > wrote: > > > > > > Are we really ready for a 2.0? How much deprecated stuff do we carry? > > I plan on taking a closer look at the jarod distance issue tonight or > tomorrow. > > Gary > > On Wed, Feb 20, 2019, 13:33 Pascal Schumacher wrote: > >> I'm fine with either solution, but my preference would be to remove all >> deprecated stuff and release version 2.0. >> >>> Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita: >>> Hi all, >>> Just finished merging a pull request to TEXT-104, where the JaroWinkler >> distance was updated. The class was actually computing a text similarity >> score, not an edit distance. The user that contributed did a great job >> moving the logic into a separate class, then updating the method to return >> a distance instead. >>> Later I realized this would break both behaviour and binary >> compatibility. >>> So just wondering what others think. Is it time to gather a few more >> issues in text, maybe even consider updating libraries/java/etc, drop >> @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert >> moving the code to a branch, and update TEXT-104 with a note about the >> branch? >>> CheersBruno >>> >> >> >> - >> 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: [text] TEXT-104 clirr errors, prepare 2.0 or revert change
Good idea. Another user commented something similar in the pull request, and I believe Rob's suggestion was in the same direction. Here's a PR that fixes clirr and deprecates a few things for 2.0: https://github.com/apache/commons-text/pull/102 Thanks! Bruno On Wednesday, 20 February 2019, 11:42:35 pm NZDT, Benedikt Ritter wrote: Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita < ki...@apache.org>: > Hi all, > Just finished merging a pull request to TEXT-104, where the JaroWinkler > distance was updated. The class was actually computing a text similarity > score, not an edit distance. The user that contributed did a great job > moving the logic into a separate class, then updating the method to return > a distance instead. > Later I realized this would break both behaviour and binary compatibility. > So just wondering what others think. Is it time to gather a few more > issues in text, maybe even consider updating libraries/java/etc, drop > @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert > moving the code to a branch, and update TEXT-104 with a note about the > branch? > This would be a bad signal to the contributor. Do you think it's possible to have both solutions side by side? So we keep the old class with the name an interface, deprecate it and put the new solution in the same package with a different class name? Benedikt > CheersBruno > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] visruth opened a new pull request #7: get generated keys from queryRunner.insertBatch
visruth opened a new pull request #7: get generated keys from
queryRunner.insertBatch
URL: https://github.com/apache/commons-dbutils/pull/7
This class will be useful to get generated keys from the
queryRunner.insertBatch operation.
Eg:-
```
ResultSetHandler> rsh = new ScalarListHandler();
Object[][] params = {{"col1row1", "col2row1"}, {"col1row2", "col2row2"}};
List ids = queryRunner.insertBatch("INSERT INTO testtable (col1,
col2) VALUES (?,?)", rsh,
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
