January 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-18995) Early Access features can be installed from JBoss Tools p2 repository even if 'Enable Early Access' is disabled in Central

by Denis Golovin (JIRA)

Denis Golovin created JBIDE-18995: ------------------------------------- Summary: Early Access features can be installed from JBoss Tools p2 repository even if 'Enable Early Access' is disabled in Central Key: JBIDE-18995 URL: https://issues.jboss.org/browse/JBIDE-18995 Project: Tools (JBoss Tools) Issue Type: Bug Components: updatesite Affects Versions: 4.2.1.Final Reporter: Denis Golovin Priority: Minor I noticed central has "(Early Access Installed)" sign in after I installed everything from JBos Tools stable p2 repository. !ea-installed.png! "Enable Early Access" checkbox is not set by default in Central Editor !ea-disabled.png! This means I bypassed warning dialog in this scenario. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18953) Unexpected JAX-RS validation error for client filters

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18953?page=com.atlassian.jira.plugi... ] Xavier Coulon resolved JBIDE-18953. ----------------------------------- Resolution: Done Change was pushed to 'jbosstools-4.2.x' branch without a PR :/ (but with proper post-push review by [~fbricon]) > Unexpected JAX-RS validation error for client filters > ----------------------------------------------------- > > Key: JBIDE-18953 > URL: https://issues.jboss.org/browse/JBIDE-18953 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.2.0.Final > Reporter: Valentin Baciu > Assignee: Xavier Coulon > Fix For: 4.2.2.Final > > > We are using JAX-RS client filters in our project. One of the classes looks like this: > ... > import java.io.IOException; > import javax.ws.rs.client.ClientRequestContext; > import javax.ws.rs.client.ClientRequestFilter; > import javax.ws.rs.client.ClientResponseContext; > import javax.ws.rs.client.ClientResponseFilter; > import javax.ws.rs.ext.Provider; > ... > @Provider > public class ClientFilter implements ClientRequestFilter, ClientRequestFilter > { > ... > } > The class is part of a Dynamic Web Project with JAX-RS support turned on. > The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error: > The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver. > I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18953) Unexpected JAX-RS validation error for client filters

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18953?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-18953: ------------------------------------- +1 for 4.2.2 > Unexpected JAX-RS validation error for client filters > ----------------------------------------------------- > > Key: JBIDE-18953 > URL: https://issues.jboss.org/browse/JBIDE-18953 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.2.0.Final > Reporter: Valentin Baciu > Assignee: Xavier Coulon > Fix For: 4.2.2.Final > > > We are using JAX-RS client filters in our project. One of the classes looks like this: > ... > import java.io.IOException; > import javax.ws.rs.client.ClientRequestContext; > import javax.ws.rs.client.ClientRequestFilter; > import javax.ws.rs.client.ClientResponseContext; > import javax.ws.rs.client.ClientResponseFilter; > import javax.ws.rs.ext.Provider; > ... > @Provider > public class ClientFilter implements ClientRequestFilter, ClientRequestFilter > { > ... > } > The class is part of a Dynamic Web Project with JAX-RS support turned on. > The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error: > The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver. > I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15135: ------------------------------------ {quote}This is meant to go in the upstream block when upstream data is available{quote} When is it available? How is it made available? How do you test this offline? How does the mojo know about upstream projects, since none of the jobs are linked in Jenkins? {quote}Same reason, it's reporting the value of the property from Jenkins (or CLI).{quote} Why not also dump variables we know are important which are resolved from parent pom? Why only worry about CLI variables, not defaults too? (Consider what you see in the Help > About > Eclipse Config view -- it contains BOTH things set CLI / eclipse.ini and also defaults pulled from the OS/system. I think we should do that too.) Re: OS/JDK details... we should include those. It's way better to just collect it at publish time than to have to go dig up the information later if something fails which is slave config specific, or is an OS-related problem. Is it a lot of work to collect that information? Surely you can just grab the output of `uname -a;java -version` ? > Attach metadata during assembly instead of publish time > ------------------------------------------------------- > > Key: JBIDE-15135 > URL: https://issues.jboss.org/browse/JBIDE-15135 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.x > > > In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site. > Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-374) Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-374?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBTIS-374: ---------------------------------- Problem is that your directory.xml does not know where to find the JBDS Central plugin. It should contain THREE entries: * JBDS Central [missing] * JBDS Early Access [present] * JBDS IS (Early Access) [present] For example: https://devstudio.jboss.com/updates/8.0-staging/devstudio-directory.xml > Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central > --------------------------------------------------------------------------------------- > > Key: JBTIS-374 > URL: https://issues.jboss.org/browse/JBTIS-374 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 8.0.0.Beta2 > Environment: JBDS 8.0.1.GA + JBDS-IS 8.0.0.Beta2 > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Minor > > The following errors occur when we want to install JBDS-IS from JBoss Central > !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.010 > !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'angularjs-eclipse-feature' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar > !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.023 > !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'org.jboss.tools.arquillian' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar > This occurs only in error log and has no impact on the installation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-3304?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-3304: ----------------------------- CDW docs_ack: ? CDW devel_ack: ? CDW pm_ack: + CDW qa_ack: ? CDW release: ? > [unit test] versionwatch should run against latest builds, not hardcoded older Betas > ------------------------------------------------------------------------------------ > > Key: JBDS-3304 > URL: https://issues.jboss.org/browse/JBDS-3304 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 8.0.1.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > > versionwatch should run against latest builds, not hardcoded older Betas. > Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest. > This might have broken as a result of a bug in install.jbds.sh - I thought this used to work: > {code} > ++ TMPDIR=/tmp > /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"' > /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file > {code} > Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas

by Nick Boldt (JIRA)

Nick Boldt created JBDS-3304: -------------------------------- Summary: [unit test] versionwatch should run against latest builds, not hardcoded older Betas Key: JBDS-3304 URL: https://issues.jboss.org/browse/JBDS-3304 Project: Developer Studio (JBoss Developer Studio) Issue Type: Bug Components: build Affects Versions: 8.0.1.GA Reporter: Nick Boldt Assignee: Nick Boldt versionwatch should run against latest builds, not hardcoded older Betas. Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest. This might have broken as a result of a bug in install.jbds.sh - I thought this used to work: {code} ++ TMPDIR=/tmp /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"' /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file {code} Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-3303?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-3303: ----------------------------- CDW docs_ack: ? CDW devel_ack: ? CDW pm_ack: + CDW qa_ack: ? CDW release: ? > [unit test] versionwatch should not fail silently when the report is empty > -------------------------------------------------------------------------- > > Key: JBDS-3303 > URL: https://issues.jboss.org/browse/JBDS-3303 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 8.0.1.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > > versionwatch should not fail silently when the report is empty, such as: > {code} > JBDS Version Watch > Feature list for filter = .*(hibernate\|jboss\|xulrunner).* > Plugin list for filter = .*(hibernate\|jboss\|xulrunner).* > Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853. > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty

by Nick Boldt (JIRA)

Nick Boldt created JBDS-3303: -------------------------------- Summary: [unit test] versionwatch should not fail silently when the report is empty Key: JBDS-3303 URL: https://issues.jboss.org/browse/JBDS-3303 Project: Developer Studio (JBoss Developer Studio) Issue Type: Bug Components: build Affects Versions: 8.0.1.GA Reporter: Nick Boldt Assignee: Nick Boldt versionwatch should not fail silently when the report is empty, such as: {code} JBDS Version Watch Feature list for filter = .*(hibernate\|jboss\|xulrunner).* Plugin list for filter = .*(hibernate\|jboss\|xulrunner).* Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853. {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18764) Weird behavior of the packaging exclusions support

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18764?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-18764: ------------------------------------- haven't retried in a while > Weird behavior of the packaging exclusions support > -------------------------------------------------- > > Key: JBIDE-18764 > URL: https://issues.jboss.org/browse/JBIDE-18764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Attachments: excludejars.zip > > > I have a multi-module maven project with ear, war, ejb ... > The excludejars-web/pom.xml defines <packagingExcludes>WEB-INF/lib/*</packagingExcludes> > When deploying excludejars-ear to WF, the excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib directory is empty, as expected. > Now if you remove <packagingExcludes>WEB-INF/lib/*</packagingExcludes> from the excludejars-web/pom.xml , Update the Maven project configuration (Alt-F5) on the excludejars-web project, org.eclipse.wst.common.component is updated to contain <property name="component.exclusion.patterns"/> > When you do a full publish on the ear project, excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib is still empty. Same thing if you invoke "clean" on the WF server adapter. > The only way to get the jars deployed is to remove the ear from WF, clean, then add the ear back. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues January 2015