trunk not compiling
by Max Rydahl Andersen
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.15.0:compile (default-compile) on project org.jboss.tools.ui.bot.ext: Compilation failure: Compilation failure:
[ERROR] /Users/max/code/jbosstools/trunk/tests/plugins/org.jboss.tools.ui.bot.ext/src/org/jboss/tools/ui/bot/ext/helper/QuickFixHelper.java:[55,0]
[ERROR] QuickFixBot quickFix = editor.quickFix();
[ERROR] ^^^^^^^^
Anyone with an idea on what is causing this ?
/max
12 years, 3 months
Problem with CDI Builder creating new 'A' type
by Xavier Coulon
Hello Daniel,
As I'm trying to fix https://issues.jboss.org/browse/JBIDE-12095, I found something a bit strange in the CDIBuilderDelegate when editing a 'package-info.java' file (just adding a space char):
At line 90, the CDIBuilderDelegate#build() method calls the PackageDelegate#setPackage() method below which creates a 'class A {}' as shown below.
public void setPackage(IPackageDeclaration pkg, IRootDefinitionContext context) {
qualifiedName = pkg.getElementName();
IType contextType = null;
ICompilationUnit u = null;
if(pkg.getParent() instanceof ICompilationUnit) {
try {
u = ((ICompilationUnit)pkg.getParent()).getWorkingCopy(new NullProgressMonitor());
contextType = u.createType("class A {}", null, false, new NullProgressMonitor());
} catch (JavaModelException e) {
}
}
super.setAnnotatable(pkg, contextType, context, 0);
if (u != null) {
try {
u.discardWorkingCopy();
} catch (JavaModelException e) {
}
}
}
The JAX-RS plugin catches an event for this type creation but fails later. I can add some tests to verify that the type really exist, but still, is this necessary (just asking, don't take is bad) ?
Thanks.
Best regards,
/Xavier
12 years, 3 months
Freemarker functionality in Eclipse?
by Rob Cernich
Hey all,
Does anybody know if Eclipse has any functionality like freemarker (for processing file templates)? I'll even take a plugin/osgi bundle that provides access to freemarker apis. If so, is that available through JBT?
Thanks in advance,
Rob
12 years, 3 months
Packaging JBoss Tools for Fedora (issue & potential patches)
by Gerard Ryan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
For the past while I've been working on packaging JBoss Tools for
Fedora as part of my GSOC project (Fedora JBoss Spin)[0]. I've just
run into a slight problem, and I'm trying to look for the
cleanest/easiest way to work around it. I'm hoping that there might be
someone on this list who can provide some further insight or advice! :)
First, a little background on the problem. As you can imagine, for
Fedora, we've got a lot of rules and regulations on how stuff can be
packaged. One of these is that any bundled libraries or precompiled
code must be removed before building, and where necessary/possible, a
package is created for each library that is removed so that the
process for the original software that was being built can continue.
Another rule that we have is that only the latest version of stuff can
be packaged, so that everything can be maintained as cleanly as possible.
The part of JBoss Tools that's causing a spot of trouble with these
rules so far is the org.jboss.ide.eclipse.archives.core bundle. In the
lib/ directory of this, there are some quite old jars, with truezip
and jbossxb (jboss-xml-binding.jar) being the most prominent of these,
and the others seeminly being dependencies for these. I've managed to
package the latest truezip release (7.5.5, as opposed to the bundled
6.6), and I've patched the code of the archives.core plugin to make it
work. I hope that these changes can be checked and integrated by you
guys at some stage! :)
The jbossxb dependency has proved somewhat more troublesome. The
bundled version is a bit old (2.0.0.CR6), and has a different set of
dependencies than the most recent release[1] (2.0.3.GA from 2010). I
had managed to get over that hurdle temporarily, and the more recent
release seemed to work. The problem occured when jbossxb and its
dependencies were being reviewed for inclusion into the Fedora
repositories, and the reviewer noticed that one of the dependencies
for that (jboss-reflect), bundles its own forked version of another
library (objectweb-asm), that isn't fully compatible with the upstream
version. This is also not allowed in Fedora.
Since this problem child (jboss-reflect) seems to be obselete and
forgotten about (I can only find it as a subproject of AS6[2]), I
don't necessarily want to package it for Fedora unless it's absolutely
necessary.
You're probably wondering why I'm talking to you on jbosstools-dev ML
about this? My query is, how essential is this jbossxb dependency for
org.jboss.ide.eclipse.archives.core? Is there any way that it could be
avoided, or are there any drop-in replacements that we could try
instead? Have you got any other suggestions that I could try?
Also, if you are interested in trying the most recent development
version of the Fedora JBoss Spin, you can find more info on it here[3]
and run it as a live usb image or in a vm.
thanks for reading,
Gerard.
[0] https://fedoraproject.org/wiki/Fedora-JBoss-Spin
[1] https://source.jboss.org/changelog/JBossCommon/jbossxb/trunk
[2] http://anonsvn.jboss.org/repos/jbossas/projects/jboss-reflect/
[3] https://blog.grdryn.me/2012/07/09/fedora-jboss-spin-gsoc-update-7
- --
Gerard Ryan :: gerard(a)ryan.lt :: http://blog.grdryn.me :: @grdryn
PGP Fingerprint: AA11 A666 C98E B6D8 231C 11ED 6EDC 7E4A 62BC 4A15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJQA0G6AAoJEG7cfkpivEoVdJYP/j0sZ3qJWkCb4FwBGKC8+mHS
hObWFRpZVL5IqJU/f/bmD3bewUc2eWe6ukQ3SN1m0i/GGBAxs7zv22U8S66nkSby
dP0eaRQK7Cs6GL1zh942i+/Z06FGaYljPK+hYTmyMQnI+GarIJVhP1VMXwzQ2nUa
dK145e2zYEUogZ3ZebeYluBBCh9UCOrk4YJytTLUwJafwuHXXDO1f86p2CRHleuc
QUX2eJUwmuxZJBMSzJC4i8gxJMsgaW3txg5YnznEAh8KYfzCq8tz8laENSvCWvmQ
VAUI1VFBisQlCAbjznVvQrpN6J6l+UQHEtwzT7Wq9ckIwgA95zQ3K5WrOVDwvwlN
LNpb3uYZk/LiAkqkqDNqfZcFO3jZh9eGGUzcBnJhyFnfIkMtS0QA6x1T9+DTknxF
fcrlFppKBUzFJfteJ17oic5XMjZA+NnSwUEC8X6IuM1/Mdl455icTyqYr5iAVAMg
P8N9/4+kg6AGueX2k9vvuS8nHiVP0joN8wgdGcrhI5esnYuqr8rLlQw/M3suNPIJ
4u1G8Gpkf42JzEFHlmS3VJpn+LLhu24oPvsccP/cyGKGsEYoEwblEOPl1uxwVohH
V0l++m2ggiXQ9EXNzGgHTgKUr+ANrkVTvSmHPgZd/Yu5BpZ/u8IbJeik8lZJNXj0
8pmxDrQzb9tuKhBSCbp/
=W+BK
-----END PGP SIGNATURE-----
12 years, 3 months
Running bot tests against JBDS
by Andrej Podhradsky
Hi all,
I'm trying to run swt bot tests using maven against JBDS, but without any success :(
I tried to set as target platform the following link (donwload and unzip)
http://www.qa.jboss.com/binaries/RHDS/builds/stable/5.0.1.GA.installer/jb...
I also added appropriate repositories (core + soa) but I'm still getting
[ERROR] Cannot resolve project dependencies:
[ERROR] You requested to install 'org.eclipse.platform.ide 0.0.0' but it could not be found
Could someone help me, please?
Thank you!
--
Andrej Podhradsky
Quality Assurance Associate
JBoss SOA Platform
IRC: apodhrad at #jbossqa #jbosssoa #jbosssoaqa #devstudio-qa #brno
12 years, 3 months
Ideas to make m2eclipse-wtp -> m2e-wtp migration painless?
by Fred Bricon
Hi all,
I'm currently banging my head on the m2eclipse-wtp -> m2e-wtp migration, so
if anyone as any good ideas, I'm open to suggestions.
Here's what we have :
- m2e-wtp (@eclipse) uses a new namespace for eclipse plugins/features :
org.eclipse.m2e.wtp instead of org.maven.ide.wtp
- m2e-wtp keeps the m2eclipse-wtp configurator identifiers to maintain
backward compatibility with 3rd party plugins (JBoss Tools ecosystem,
Google Eclipse Plugin ...)
- m2e-wtp installation doesn't disable m2eclipse-wtp plugins since the
namespace changed.
- installing m2e-wtp over m2eclipse-wtp is bad (as "crossing the streams"
bad) since m2e-core now finds duplicate configurators which produces errors.
- I created (locally) an m2eclipse-wtp 0.15.999 empty feature that
requires m2e-wtp 0.16.0. m2e-wtp is correctly installed but I'm still
seeing the duplicate configurators as previous m2eclipse-wtp 0.15.2 plugins
are still active.
Ideally m2e-wtp would disable m2eclipse-wtp when installed, but I'm afraid
it seems impossible (yeah I suck at eclipse/OSGi stuff).
So that means the only way to install m2e-wtp for existing m2eclipse-wtp
users will be to either start from a pristine eclipse installation or
uninstall m2eclipse-wtp beforehand, breaking the update process for
products already embedding m2eclipse-wtp.
Hopefully I'm missing something. Sooo, any ideas?
Regards,
Fred Bricon
--
"Have you tried turning it off and on again" - The IT Crowd
12 years, 3 months
