January 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-16328) Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod()

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16328?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-16328: --------------------------------------- Thomas, Thanks for reporting this issue and sorry if I missed it before. The Pull Request I attached avoids the validation message on interfaces. It also fixes the missing '{0}' parameter substitution in the message. Don't hesitate to report any other issue/feature request you have (I'll make sure I won't miss them next time) > Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod() > ------------------------------------------------------------------------------------ > > Key: JBIDE-16328 > URL: https://issues.jboss.org/browse/JBIDE-16328 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.Final > Environment: Eclipse 4.3.1 EE bundle + JBoss Tools 4.1.1 > Reporter: Thomas Maslen > Assignee: Fred Bricon > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > JAX-RS resource methods are often declared in classes, but it is also valid to declare them in interfaces. Methods in classes have to be explicitly declared public (and that's what this validator method checks for -- good), but methods in Java interfaces are implicitly public; explicitly writing "public" just adds clutter. > The JAX-RS validator does discover resource methods in interfaces and validates them (good), but if the methods aren't explicitly labelled public then a couple of minor bugs surface in this validator method: > (1) It adds a RESOURCE_METHOD_NO_PUBLIC_MODIFIER problem marker, and > (2) The Description that's displayed for the marker is "The method '{0}' should be public.", i.e. the "{0}" isn't replaced with a method name > (Yes, I can certainly dodge this by changing the "Missing 'public' method modifier" preference from Warning to Ignore, but I'm definitely a fan of having the validators there to save me from myself). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16264) @PathParam with hyphen in value shows as JAX-RS error

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16264?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-16264: --------------------------------------- Jim, Thanks for reporting this issue and sorry if I missed it before. I added rules to allow for hyphen, underscore and dot characters in the PathParam annotation value and fixed the validator message (it was not the appropriate one). Don't hesitate to report any other issue/feature request you have (I'll make sure I won't miss them next time) > @PathParam with hyphen in value shows as JAX-RS error > ----------------------------------------------------- > > Key: JBIDE-16264 > URL: https://issues.jboss.org/browse/JBIDE-16264 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.CR1 > Reporter: Jim Boettcher > Assignee: Fred Bricon > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > if I have a method like: > @GET > @Path("/rule/{rule-file-name}") > public byte[] getRuleSet(@PathParam("rule-file-name") String ruleSetName) > I get the error: > @PathParam value 'rule-file-name' does not match any @Path annotation template parameters of the java method and the enclosing java type. > If I remove the hyphens from "rule-file-name" the error goes away. > However the hyphen should be allowed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16264) @PathParam with hyphen in value shows as JAX-RS error

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16264?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-16264: --------------------------------------- Fred, Please review the PR to see if it applies for JBT 4.1.2 and/or JBT 4.2.0 (only) Thanks > @PathParam with hyphen in value shows as JAX-RS error > ----------------------------------------------------- > > Key: JBIDE-16264 > URL: https://issues.jboss.org/browse/JBIDE-16264 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.CR1 > Reporter: Jim Boettcher > Assignee: Fred Bricon > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > if I have a method like: > @GET > @Path("/rule/{rule-file-name}") > public byte[] getRuleSet(@PathParam("rule-file-name") String ruleSetName) > I get the error: > @PathParam value 'rule-file-name' does not match any @Path annotation template parameters of the java method and the enclosing java type. > If I remove the hyphens from "rule-file-name" the error goes away. > However the hyphen should be allowed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16264) @PathParam with hyphen in value shows as JAX-RS error

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16264?page=com.atlassian.jira.plugi... ] Xavier Coulon reassigned JBIDE-16264: ------------------------------------- Assignee: Fred Bricon (was: Xavier Coulon) https://github.com/jbosstools/jbosstools-webservices/pull/110 > @PathParam with hyphen in value shows as JAX-RS error > ----------------------------------------------------- > > Key: JBIDE-16264 > URL: https://issues.jboss.org/browse/JBIDE-16264 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.CR1 > Reporter: Jim Boettcher > Assignee: Fred Bricon > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > if I have a method like: > @GET > @Path("/rule/{rule-file-name}") > public byte[] getRuleSet(@PathParam("rule-file-name") String ruleSetName) > I get the error: > @PathParam value 'rule-file-name' does not match any @Path annotation template parameters of the java method and the enclosing java type. > If I remove the hyphens from "rule-file-name" the error goes away. > However the hyphen should be allowed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16328) Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod()

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16328?page=com.atlassian.jira.plugi... ] Xavier Coulon reassigned JBIDE-16328: ------------------------------------- Assignee: Fred Bricon (was: Xavier Coulon) Please review the PR to see if it applies for JBT 4.1.2 and/or JBT 4.2.0 (only) Merci ;-) > Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod() > ------------------------------------------------------------------------------------ > > Key: JBIDE-16328 > URL: https://issues.jboss.org/browse/JBIDE-16328 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.1.Final > Environment: Eclipse 4.3.1 EE bundle + JBoss Tools 4.1.1 > Reporter: Thomas Maslen > Assignee: Fred Bricon > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > JAX-RS resource methods are often declared in classes, but it is also valid to declare them in interfaces. Methods in classes have to be explicitly declared public (and that's what this validator method checks for -- good), but methods in Java interfaces are implicitly public; explicitly writing "public" just adds clutter. > The JAX-RS validator does discover resource methods in interfaces and validates them (good), but if the methods aren't explicitly labelled public then a couple of minor bugs surface in this validator method: > (1) It adds a RESOURCE_METHOD_NO_PUBLIC_MODIFIER problem marker, and > (2) The Description that's displayed for the marker is "The method '{0}' should be public.", i.e. the "{0}" isn't replaced with a method name > (Yes, I can certainly dodge this by changing the "Missing 'public' method modifier" preference from Warning to Ignore, but I'm definitely a fan of having the validators there to save me from myself). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16403) Welcome page "Show on startup" option is grey

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16403?page=com.atlassian.jira.plugi... ] Snjezana Peco reassigned JBIDE-16403: ------------------------------------- Assignee: Snjezana Peco > Welcome page "Show on startup" option is grey > --------------------------------------------- > > Key: JBIDE-16403 > URL: https://issues.jboss.org/browse/JBIDE-16403 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.1.1.Final > Environment: Kubuntu 64 bits > Reporter: Emmanuel Hugonnet > Assignee: Snjezana Peco > Priority: Minor > Fix For: 4.2.0.Beta1 > > Attachments: jboss_central.png > > > The option "show on startup" is displayed with a grey background instead of the default one. Changing theme doesn't affect it. > See screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16411) Add m2eclipse-mavenarchiver 0.16.0 to our TP + requirements

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16411?page=com.atlassian.jira.plugi... ] Mickael Istria resolved JBIDE-16411. ------------------------------------ Resolution: Done > Add m2eclipse-mavenarchiver 0.16.0 to our TP + requirements > ----------------------------------------------------------- > > Key: JBIDE-16411 > URL: https://issues.jboss.org/browse/JBIDE-16411 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, target-platform > Affects Versions: 4.1.1.Beta1 > Reporter: Fred Bricon > Assignee: Mickael Istria > Priority: Blocker > Labels: jbds711 > Fix For: 4.1.2.CR1, 4.2.0.Alpha2 > > > An unsigned build of m2eclipse-mavenarchiver 0.16.0 is available from http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-mavenarchiver/0.1... > An eclipse signed version should be available in the upcoming weeks, as part of the Luna release > Please add it to our TP / Requirements / whatever for JBT 4.1.2. > This builds prevents aggressive pom.xml/pom.properties generation on each incremental build. > This is required to help fix JBIDE-16286 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ] Mickael Istria closed JBIDE-13817. ---------------------------------- Fix Version/s: 4.2.0.Alpha2 (was: 4.2.x) Resolution: Done Since we're not using fetching zips any more (cf JBIDE-16376), this issue is rejected. > aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-13817 > URL: https://issues.jboss.org/browse/JBIDE-13817 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site. > [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... > The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which: > * reads the upstream composite site [1], and > ** for each child site listed, > *** downloads a zip matching the last CI build for that project > **** IF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. > **** If the contents differ, return an error report. > Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/, > There is also this file [2] produced by this job [3], which might make things easier: > [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun... > [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ] Mickael Istria closed JBIDE-13817. ---------------------------------- Resolution: Rejected > aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-13817 > URL: https://issues.jboss.org/browse/JBIDE-13817 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.2.0.Alpha2 > > > The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site. > [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... > The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which: > * reads the upstream composite site [1], and > ** for each child site listed, > *** downloads a zip matching the last CI build for that project > **** IF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. > **** If the contents differ, return an error report. > Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/, > There is also this file [2] produced by this job [3], which might make things easier: > [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun... > [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16411) Add m2eclipse-mavenarchiver 0.16.0 to our TP + requirements

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16411?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-16411: ----------------------------------- Fix Version/s: 4.2.0.Alpha2 (was: 4.2.0.CR1) > Add m2eclipse-mavenarchiver 0.16.0 to our TP + requirements > ----------------------------------------------------------- > > Key: JBIDE-16411 > URL: https://issues.jboss.org/browse/JBIDE-16411 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, target-platform > Affects Versions: 4.1.1.Beta1 > Reporter: Fred Bricon > Assignee: Mickael Istria > Priority: Blocker > Labels: jbds711 > Fix For: 4.1.2.CR1, 4.2.0.Alpha2 > > > An unsigned build of m2eclipse-mavenarchiver 0.16.0 is available from http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-mavenarchiver/0.1... > An eclipse signed version should be available in the upcoming weeks, as part of the Luna release > Please add it to our TP / Requirements / whatever for JBT 4.1.2. > This builds prevents aggressive pom.xml/pom.properties generation on each incremental build. > This is required to help fix JBIDE-16286 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues January 2014