Am Fri, 23 Jan 2015 02:45:37 +0000 schrieb sebb <seb...@gmail.com>: > On 20 January 2015 at 01:44, sebb <seb...@gmail.com> wrote: > > I get 141 if the Fix Version is limited to 2.1 > > By that I mean an Issue search using the JIRA GUI returns 141 entries. > > Unfortunately still above 100. > > VFS obviously needs to fix fewer bugs between releases!
Sure, but that was before my time. Anyway, since our changes file is more than complete, I tend to think I just disable the JIRA report, because having an incomplete list is worse than having a link to the JIRA. WDYT? Gruss Bernd > > You can add > > > > <onlyCurrentVersion>true</onlyCurrentVersion> > > > > to the VFS pom (I recently did this for NET). > > > > I don't know how to increase the JIRA limit or if it is possible - > > you could raise an INFRA Jira. > > > > > > On 19 January 2015 at 02:27, Bernd Eckenfels > > <e...@zusammenkunft.net> wrote: > >> Hello, > >> > >> I added a commons.changes.maxEntries property to CP trunk. This > >> way one can overwrite the limit if needed. Tested it with VFS and > >> 600: > >> > >> the request is sent with the new limit: > >> > >> Address: https://issues.apache.org/jira/rest/api/2/search > >> Http-Method: POST > >> Content-Type: application/json > >> Headers: {Accept=[application/json], > >> Content-Type=[application/json], Payload: {"jql":"project = VFS > >> AND status in (5, 6) AND resolution in (1) AND type in (1, 2, 3, > >> 4, 5, 6) ORDER BY fixversion DESC, type ASC, key > >> DESC","maxResults":600,"fields":["*all"]} ... > >> > >> but the response seems to be limited by JIRA to 100 (there is a > >> property to configure the limit, it is default 1000? > >> jira.search.views.default.max'): > >> > >> Response-Code: 200 > >> Encoding: UTF-8 > >> Content-Type: application/json;charset=UTF-8 > >> Headers: {Cache-Control=[no-cache, no-store, no-transform], > >> connection=[Keep-Alive], > >> content-type=[application/json;charset=UTF-8], Date=[Mon, 19 Jan > >> 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96], > >> Server=[Apache-Coyote/1.1], > >> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; > >> Path=/jira/; Secure; HttpOnly], transfer-encoding=[chunked], > >> X-AREQUESTID=[110x29767730x2], X-ASEN=[SEN-2062203], > >> X-AUSERNAME=[anonymous], X-Content-Type-Options=[nosniff]} > >> Messages: Message (saved to tmp file): Filename: > >> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp > >> (message truncated to 102400 bytes) > >> > >> Payload: > >> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ... > >> > >> Can I ignore the jira report for the next release or any idea how > >> to fix it? > >> > >> I have filed a bug report, here: > >> http://jira.codehaus.org/browse/MCHANGES-351 > >> > >> Gruss > >> Bernd > >> > >> > >> Am Sat, 20 Dec 2014 12:44:53 +0100 > >> schrieb Bernd Eckenfels <e...@zusammenkunft.net>: > >> > >>> Am Sat, 20 Dec 2014 11:35:30 +0000 > >>> schrieb sebb <seb...@gmail.com>: > >>> > >>> > On 20 December 2014 at 01:57, Bernd Eckenfels > >>> > <e...@zusammenkunft.net> wrote: > >>> > > Am Sat, 20 Dec 2014 02:48:43 +0100 > >>> > > schrieb Bernd Eckenfels <e...@zusammenkunft.net>: > >>> > > > >>> > >> <!-- Don't include sub-task --> > >>> > >> <typeIds>Bug,New > >>> > >> Feature,Task,Improvement,Wish,Test</typeIds> > >>> > >> > >>> > >> So should we add "improvement" here as well? > >>> > > > >>> > > Sorry I missed the fact it is already added. Any other idea > >>> > > what could cause this? > >>> > > >>> > There may be a limit on how many results can be returned. > >>> > >>> Yes, the limit is currently 100, and it seems JIRA is first > >>> limiting the results and then sorting them. So I guess increasing > >>> the limit and maybe also restricting to the current version would > >>> help: > >>> > >>> > >>> <onlyCurrentVersion>true</onlyCurrentVersion> > >>> <maxEntries>300</maxEntries> > >>> > >>> > >>> Is this something for commons-parent or should I include and > >>> overwrite the changes-plugin configuration in VFS? (Currently the > >>> changes-plugin is only configured for the relnotes profile, so I > >>> would need to add it) > >>> > >>> Gruss > >>> Bernd > >> > >> --------------------------------------------------------------------- > >> 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
