Problem with JUnit test execution with maven
by Xavier Coulon
Hello,
I just got a NPE with tests running from Maven (they run fine from PDE, though): 'org.eclipse.jst.j2ee.model.ModelProviderManager.ModelProviderManager.getModelProvider(project)' returns 'null' in the WizardPages that I'm trying to test.
For the moment, I'll skip those tests on maven to avoid build failures on Jenkins, but if anyone has a clue what I should do to get them pass on maven/Jenkins (i.e., initialise the ModelProviderManager ?), please let me know ;-)
Thanks !
Best regards,
/Xavier
12 years, 1 month
Kudos for fixing GTK3 issues!
by André Dietisheim
Hey Snjezana
big kudos for fixing the major parts of the SWT/GTK3 issues (I'm on
FC20/GTK 3.10). Started using Luna M7/GTK3 today and stuff is pretty now
usable, hurray!
Big thanks for tackling this scary one.
Cheers
André
ps. I noticed the type dialog (Ctrl+Shift+T) has no labels. Items are
selectable but no labels. Something you want me to file?
12 years, 1 month
Eclipse WTP/XML Search, are you interested?
by Angelo zerr
Hi JBoss guys,
I would like to introduce to you Eclipse WTP/XML Search
https://github.com/angelozerr/eclipse-wtp-xml-search and perhaps you could
be interested with this project.
Eclipse WTP/XML Search provides :
* an XML Search engine dialog (see
https://github.com/angelozerr/eclipse-wtp-xml-search/wiki/Installation-Gu...)
. You can use Search/XML and type a XPath to retrieve XML files by XPath.
* extension point to manage custom completion, hover, hyperlink, validator
and Ctrl+Shift+G for XML descriptor.
The basic idea about extension point is to declare your references from
your XML nodes and to other thing (other XML node, Java class, resource,
other....) and after you benefit from completion, hover, hyperlink,
validator and Ctrl+Shift+G directly.
I had developped several uses of WTP/XML Search for :
* Web XML.
* Jetty XML descriptors:
https://github.com/angelozerr/eclipse-wtp-xml-search/wiki/XML-Jetty-Plugins
* Struts2 XML descriptors :
https://github.com/angelozerr/eclipse-wtp-xml-search/wiki/Struts2-IDE
In my case, I use WTP/XML Search since 2010 in my professional project
where there are complex cases. I tell you that because I think WTP/XML
Search is mature.
Liferay IDE is integrating WTP/XML Search, so perhaps you could be
interested too. I had create a long time a bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=330576 to contribute to WTP.
Hope you will like it.
Regards Angelo
12 years, 1 month
How to make hibernatetool eclipse plugin to work with 3.6.9.Final?
by Jack Cai
Hi,
The plugin is reporting:
java.lang.NoSuchMethodError:
org.hibernate.type.CustomType.<init>(Lorg/hibernate/usertype/UserType;[Ljava/lang/String;)V
during sessionFactory initialization. We check
hibernate-core.3.6.9.Final. It does have this method for CustomType class.
What jar files do we have to replace/package to get this to work? Simply
replacing hibernate3.jar with hibernate-core.3.6.9.Fnal does not work. What
are we missing?
Can someone point out a workaround for this? The configuration is "Core"
and "3.6". Thanks.
-Jack
12 years, 1 month
Short, medium, and long term changes to JMX component
by Rob Stryker
Hi All:
For those who may not be aware, the JMX component is set to undergo
significant changes in the future. The cause for these changes are a
large amount of duplication between FuseIDE and the current JMX
component, which need to be unified together.
Based on the current release schedule, it is unlikely we get a complete
refactor / merge accomplished in any way for this year's release, though
we are proceeding at this time with the expectation that we get as much
low-hanging fruit dealt with as quickly as possible.
With this in mind, Paul Leacu has been working on investigating the
history of the various branches and the origins and lifecycles of them
over the past 7 years, with some assistance from myself and Lars Heinemann.
The low-hanging fruit we've decided to make a baseline goal for this
year's major release is to move the JVM monitor code from FuseIDE into
the jbosstools-server/jmx repository, and to get it enabled in our JMX
view. FuseIDE, which has a release schedule that is staggered from
ours, will have plenty of time to adapt to these changes, remove the
outdated duplicates from their repository, and begin using our JMX
component as a dependency for FuseIDE.
At this point, we've accomplished two main goals:
1) We've verified that there are no critical incompatibilities or
blockages that would prevent the larger merge in principle
2) We have successfully made a topic branch which moves the jvm
monitor's core and ui plugins into the jbosstools-server repository.
This is not enough for a commit to jbosstools-server's master branch
yet. While the core and the ui have been added cleanly, it is not
enabled in our JMX / MBean Explorer view. A critical wiring plugin still
needs to be refactored in order to enable this.
Once the remaining plugin, in charge of adding the JVM Monitor nodes to
our MBean Explorer view, has been cleaned up, we will be looking to add
this code to the upcoming release, and will be requesting feedback via a
Pull Request.
This approach would achieve the following goals:
1) Safely add new *and functional* code AND workflow, with no new
dependencies, to the jbosstools-server repository
2) Remove duplication from the FuseIDE for a significant chunk of
what needs to be merged
3) Serves as a baseline for further integration and a starting point
for the larger refactor that is needed
The work can be followed at the following links:
Planning document:
https://community.jboss.org/docs/DOC-52590?uniqueTitle=false
JIRA issue: https://issues.jboss.org/browse/ECLIPSE-946
JIRA issue: https://issues.jboss.org/browse/JBIDE-14119
The new additions as they stand at the moment can be viewed here:
https://github.com/jbosstools/jbosstools-server/pull/220
We are hopefully expecting this critical wiring component to be
converted over the next week or so, with a few days after for testing.
An alternative plan would be to accept PR 220 without "wiring"
immediately. This would give us a lot of new code, but no new
functionality for users, and so is of questionable utility, but I list
it here as an option. This alternative plan would be safe, and would
serve as a base for future integration, but would not in fact be very
"useful" to the current JMX component.
Feel free to discuss any questions or concerns on strategy here or on
the JIRAs.
- Rob Stryker
12 years, 1 month
