July 2012 - jbosstools-dev - Jboss List Archives

jira 3.3.1 not marked as released in jira

by Max Rydahl Andersen

Hi Denis, https://issues.jboss.org/browse/JBIDE/fixforversion/12319468 is not marked as released in jira and it still has outstanding jira's. Could you check/move those off based on what happened for 3.3.1 so we can get it marked as released ? Thanks, Max

12 years, 5 months

2
1
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5321 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5321 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5321/ to view the results.

12 years, 5 months

1
0
0 / 0

Fwd: Unable to install nightly builds

by Xavier Coulon

Moving to jbosstools-dev > Mickaël, Nick, > > I get the following error when I try to install the JBT nightly builds in my Eclipse workbench (I tend to install some binaries to avoid having to import *all* projects in my workspace): > > An error occurred while collecting items to be installed > session context was:(profile=epp.package.rcp, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). > Artifact not found: http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo... > Artifact not found: http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo... > Artifact not found: http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo... > ... > {tons of similar errors...} > ... > Artifact not found: http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo... > > My guess is that some index file is wrong. For example, > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > is not available, it has been replaced with: > http://download.jboss.org/jbosstools/builds/nightly/trunk/latest/all/repo.... > > > Thanks for your help > > Best regards, > /Xavier > > >

12 years, 5 months

3
4
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5317 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5317 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5317/ to view the results.

12 years, 6 months

1
1
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5307 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5307 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5307/ to view the results.

12 years, 6 months

1
5
0 / 0

Help needed on Eclipse Search performance

by Xavier Coulon

Hello, Pete Muir opened an issue a few weeks ago (https://issues.jboss.org/browse/JBIDE-12224) because he found that the JAX-RS tooling was sometimes taking too much time to build. He also attached a video to show what's happening on his machine: http://screencast.com/t/pHBqxVas4 Now, at the tooling level, here's what's happening: a set of jars are added to the classpath, and as part of the project build, the JAX-RS builder searches for some JAX-RS annotated types or methods in those new jars, using the Search API. Hélas, Eclipse needs to index those jars, which sometimes takes a few seconds. Now, as opposed to the CDI specification where the jars should have a marker file (META-INF/beans.xml), JAX-RS does not mandate anything similar, which means that the search includes all the jars.. Here's an example of the code that deals with annotated types search (in ws/plugins/org.jboss.tools.ws.jaxrs.core/src/org/jboss/tools/ws/jaxrs/core/jdt/JaxrsAnnotationsScanner.java) : private static List<IType> searchForAnnotatedTypes(final Class<?> annotation, final IJavaSearchScope searchScope, final IProgressMonitor progressMonitor) throws CoreException { JavaMemberSearchResultCollector collector = new JavaMemberSearchResultCollector(IJavaElement.TYPE, searchScope); SearchPattern pattern = SearchPattern.createPattern(annotation.getName(), IJavaSearchConstants.ANNOTATION_TYPE, IJavaSearchConstants.ANNOTATION_TYPE_REFERENCE | IJavaSearchConstants.TYPE, SearchPattern.R_EXACT_MATCH | SearchPattern.R_CASE_SENSITIVE); // perform search, results are added/filtered by the custom // searchRequestor defined above new SearchEngine().search(pattern, new SearchParticipant[] { SearchEngine.getDefaultSearchParticipant() }, searchScope, collector, progressMonitor); return collector.getResult(IType.class); } Do you know any way to reduce the latency at this level ? Is there any trick to improve the speed ? Thanks in advance Best regards, /Xavier

12 years, 6 months

3
4
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5305 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5305 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5305/ to view the results.

12 years, 6 months

1
0
0 / 0

Re: [jbosstools-dev] Status for VPE/Hibernate 16 July - 22 July 2012

by Max Rydahl Andersen

moving this to jbosstools-dev >> > ∙ Reproducing JBIDE-11592 - SIGSEGV when tried JBT 3.3.0.Beta2 on Juno; >> > ∙ Created prototype for eclipse<->browser communication on XULRunner v>2/WebKit/IE - JBIDE-12276; >> >> Interesting - what kind of communication ? communication to external process ? >> It is Eclipse<->IE/WebKit/XulRunner>=4 communication via SWT Browser widget. >> As you know, now VPE is implemented using JavaXPCOM interfaces to communicate with XULRunner. >> But theoretically almost everything what we do now, could be implemented using browser.execute() method to invoke JavaScript from Java, and BrowserFunction class to invoke Java from JavaScript. This would make VPE browser independent and allow to support the most recent browsers. >> So I just created a simple Eclipse editor using these two methods as a proof of concept. This editor allows to change style of selected text from Eclipse toolbar. > > It is considerably slower than JavaXPCOM bridge. Using Browser would simplify implementation on Java side, but then we have to do JavaScript part and test it with all browsers that could be Behind Browser.java class. Doesn't sound fun (neither Speed nor QE tasks). How big a speed difference are we talking about here? And when ? Is it just when doing style changes or also when editing ? with webkit there is a more or less native edit mode is there not ? > I'd rather spend time and ported JavaXPCOM bridge to latest XulRunner build, because it was implemented as build extension and use code generation to get all XPCOM Interfaces mapped in Java, so it looks doable. XULRunner is going away/dying afaik I know - especially JavaXPCOM and its missing on 64-bit platforms especially. Considering this - is it worth spending time on that ? > Another option is look though what kind of functions VPE uses out of JavaXPCOM and implement it for WebKit. How feasible is this ? /max

12 years, 6 months

2
1
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5299 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5299 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5299/ to view the results.

12 years, 6 months

1
0
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 5291 - Failure!

by ci-builds＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 5291 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/5291/ to view the results.

12 years, 6 months

1
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev July 2012