July 2012 - jbosstools-dev - Jboss List Archives

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.

9 years, 1 month

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 > > >

9 years, 1 month

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.

9 years, 1 month

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.

9 years, 1 month

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

9 years, 1 month

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.

9 years, 1 month

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

9 years, 1 month

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.

9 years, 1 month

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.

9 years, 1 month

1
4
0 / 0

Recommandation: Using a target-platform in your IDE

by Mickael Istria

Hi all, After some investigations around JBIDE-11726 <https://issues.jboss.org/browse/JBIDE-11726> (Create target platforms for developer), we have arrived to an interesting result by having 378987 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=378987> and**JBIDE-12003 <https://issues.jboss.org/browse/JBIDE-12003> fixed, so that target platform should be much more stable (CI job only publish them after validating they can successfully be resolved) and having make progress about JBIDE-11689 <https://issues.jboss.org/browse/JBIDE-11689>, by using "includeSource" flag on target-platforms. So if you want to be less surprised by dependencies-related issue, here is a way to make your IDE use an equivalent target as the one used by build, without loosing ability to view source: 1. Checkout the build/target-platform folder in your workspace 2. Open *multiple.target* using the target editor 3. Ckick on "*Set as Target"* on the upper-right corner Then, PDE will rely on this target definition to resolve dependencies (from Eclipse, Atlassian, SpringSource and other 3rd-party deps we have). In order to resolve other JBoss Tools stuff, you may want to complete it with entries from our development update-sites to resolve other modules if you need, but please don't commit anything to this TP before opening a ticket to the target-platform component. Your feedback is welcome on JBIDE-11726. -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

9 years, 1 month

1
0
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev July 2012