[JBoss Tools Development] - Developing for JBoss Tools
by Rob Stryker
Rob Stryker [https://community.jboss.org/people/rob.stryker] created the document:
"Developing for JBoss Tools"
To view the document, visit: https://community.jboss.org/docs/DOC-21381
--------------------------------------------------------------
JBoss Tools is a large conglomerate of plugins and components from many different locations. This page will help committers and hackers navigate the process of setting up a development environment, contribute patches, and navigate any approval processes required.
*Development Environment*
The first thing any developers will want to know is <a href=" https://community.jboss.org/docs/DOC-18124 https://community.jboss.org/wiki/JBossToolsDevelopmentEnvironment">How to set up your development environment</a>. This involves choosing which eclipse you'll want to install, your choices of java, subversion, eclipse target platform, which parts of the svn tree to checkout, and how to run tests from inside your IDE.
*Building JBoss Tools
*
Not all contributors will want to go through the trouble, but, if you really want to make sure your changes work the same in PDE's runtime environment (inside eclipse) as they do from a tycho build, which is the build system we use, you'll also want to try to build your project via the command line. You'll be able to set up your first builds by reading <a href=" https://community.jboss.org/docs/DOC-16604 https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3">How to Build JBoss Tools with Maven 3</a>. All committers are expected to build their component locally and verify the tests still pass before committing any major patches.
Sometimes, running your test suite in PDE vs in Tycho (command line build) have different results in the test suite. This is unfortunate, but it *does* happen. If you're getting inconsistant results, and really need to figure out what's going wrong, you'll want to read about <a href=" https://community.jboss.org/docs/DOC-15209 https://community.jboss.org/wiki/RemoteDebuggingForEclipseTestPlug-inRunn...">Using Eclipse for Remote Debugging Tycho Builds</a>.
*Submitting / Committing patches*
All commits should reference a jira. All committers are required to have a jira target in every svn commit message. This helps keep our history easy to trace back through when searching for regressions. This helps keep us aware of what use cases caused the regression, and what to look out for and re-test when reverting or re-fixing an issue. Without a jira reference, if "fixing" one regression might create a new one, we'll have no way to find out why the change was committed in the first place, or what the change thought it was fixing.
In general, the process for submitting / committing a patch is:
1) Open a jira describing the bug
2) Attach the patch to the jira.
3) If you are a core developer,
a) simply commit the patch. Otherwise,
b) assign the issue to the component lead asking for approval and assistence in committing.
4) Resolve the issue as "done". Make sure to target the fix version accurately.
Try to make sure your description, or at least a closing comment, reference exactly how to replicate the issue, so that QE can verify that the issue is fixed. This also helps maintain the integrity of our code.
*What happens after a commit?*
For those very curious contributors, core developers, or testers, <a href=" https://community.jboss.org/servlet/JiveServlet/showImage/102-18462-4-187... https://community.jboss.org/servlet/JiveServlet/showImage/102-18462-4-187...">this image</a> shows what happens in our infrastructure upon a commit. In short, a hudson jobs get kicked off to build the component, and rebuild any components that depend on it, and push all changes to update sites. You can get a good look at what update sites are used and where over at <a href=" https://community.jboss.org/docs/DOC-18462 https://community.jboss.org/wiki/HowWeCreateOurUpdate-sitesWhatAreTheyWhi...">this</a> article. Knowing what update site to use is very useful for anyone using bleeding-edge nightly builds.
*Other development tasks*
Working with branches is also a bit complicated, since our build system may (depending on the flags used) install items into your maven repository. The <a href=" https://community.jboss.org/docs/DOC-17497 https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3-WorkingWi...">Working with Branches</a> article will be very helpful here.
*
*
There are other more complicated development tasks that require much more approvals than a simple commit. Creating or removing top-level components from our svn tree have processes associated with them (or will soon ;) ). Moving plugins, tests, or features between components also require such approvals.
*
*
1) Adding a new top-level component: Approval Process and Technical Process (TODO)
2) Adding a plugin, feature, or test, to a component: Approval Process and <a href=" https://community.jboss.org/docs/DOC-18373 https://community.jboss.org/wiki/AddingAPluginandorFeatureToAnExistingCom...">Technical Process</a> (TODO)
3) Deleting a plugin, feature, or test, from a component: Approval Process and Technical Process (TODO)
4) Deleting a top-level component: Approval Proces and Technical Process (TODO)
5) Moving a plugin, feature, or test, from one component to another: Approval Process and Technical Process (TODO)
6) Adding a different component as a dependency to your component. Approval Process and Technical Process (TODO)
7) Addition of external dependencies requiring an adjustment to target platform: Approval Process and Technical Process (TODO)
Some of these tasks may not seem complicated, but, they still require wide distribution and notification on the proper mailing lists, and in some cases, followup jiras to the build team. While adding a component as a dependency to your plugin might seem simple, it has the potential to cause circular dependencies, or simply cause extra builds and waste resources. Often, the build team needs to be alerted to these changes to adjust their cascading builds scripts and properly position your jobs where they belong.
*Maintenance and Rampdown procedures*
*
*
Maintenance releases typically contain only bug-fixes, with no additional features. While there is no official process declared yet, in general, maintenance patches require approval from PM or at the very least another committer on the same component. During rampdown for a major release, such as during candidate releases, similar restrictions are in place. Look here for more information in the future.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-21381]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 5 months
[EJB3 Development] - Help with Java+Netbeans+JBoss+JMS+EJBs
by Steve Paris
Steve Paris [https://community.jboss.org/people/thebobs] created the discussion
"Help with Java+Netbeans+JBoss+JMS+EJBs"
To view the discussion, visit: https://community.jboss.org/message/755268#755268
--------------------------------------------------------------
Hello,
I am working on converting a two-tier Java desktop application to a three-tier application. This is a desktop application and uses the Swing Application Framork (SAF) as its UI. This is NOT a web application. It does not and is not intended to run inside a browser.
Because of the SAF dependency, I am limited to NetBeans 7.0.1.Because of a dependency on DCM4CHE (a back-end medical picture archiving service), I am dependent on JBoss 4.2.3 and MySQL 5.1 (although we have recently successfully moved to MySQL 5.5 and we're in teh process of moving to JBoss 5 and, I hope, JBoss 6).
I am looking for a COMPLETE example of how to create a Java application that is built in NetBeans and communicates with queues on a JBoss server using JMS. The otherwise excellent HornetQ examples all have Ant scripts but run independently and I did not understand how to integrate any of that code into my NetBeans application. NetBeans gives some examples on using JMS, but they target the GlassFish server. I haven't yet located a complete, end-to-end, enterprise application that is pure Java - i.e., no web pages. Can anyone help with links, suggestions, etc. And, I know SAF is a dead-end; moving to the NetBeans 7.1 platform or JavaFX is another project. Right now, I just have to concentrate on moving all the database code to the server and figure out how to create a messaging system between the Java/Swing client and the JBoss-hosted JMS queues, MDB and EJBs. Thanks in advance!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/755268#755268]
Start a new discussion in EJB3 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
[JBoss AS 7 Development] - __redirected.__DocumentBuilderFactory ClassCastException
by Rodrigo Oliveira
Rodrigo Oliveira [https://community.jboss.org/people/rodrigorjo] created the discussion
"__redirected.__DocumentBuilderFactory ClassCastException"
To view the discussion, visit: https://community.jboss.org/message/755252#755252
--------------------------------------------------------------
Hello everyone,
I am migrating some web systems that use third party libraries. One of them use its own DocumentBuilderFactory class.
I created a module for the libraries, and the classes in that module are being accessed fine by the applications.
When I try to use DocumentBuilderFactory it gives a classCastException.
I tryed to exclude DocumentBuilderFactory from javaee.api with both ways indicated at this post https://community.jboss.org/message/637818#637818#637818 https://community.jboss.org/message/637818#637818.
Neither worked and I still keep recieving the error:
java.lang.ClassCastException: __redirected.__DocumentBuilderFactory cannot be cast to javax.xml.parsers.DocumentBuilderFactory
Is it because __redirected.__DocumentBuilderFactory is not on javax.xml.parsers? so I guess the configuration to exclude <exclude path="javax/xml/parsers" /> would not work, right?
If so, how can I resolve this issue? Where is __redirect.__DocumentBuilderFactory? Why is Jboss trying to use it instead of my own class.
Thanks in advance and follows the 2 configurations I had tryed according to the answer in that post: (I also tryed many variations trying to exclude javax/xml/parsers from javaee.api)
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="deployment.javaee.api" />
</dependencies>
<exclusions>
<module name="javaee.api" />
</exclusions>
</deployment>
<module name="deployment.javaee.api">
<dependencies>
<module name="javaee.api" export="true">
<imports>
<exclude path="javax/xml/parsers" />
</imports>
</module>
</dependencies>
</module>
</jboss-deployment-structure>
*or*
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<exclusions>
<module name="javaee.api" />
</exclusions>
<dependencies>
<module name="org.apache.commons.logging" />
</dependencies>
</deployment>
<sub-deployment name="viabilidade.war">
<exclusions>
<module name="javaee.api" />
</exclusions>
<dependencies>
<module name="javaee.api" >
<imports>
<exclude-set>
<path name="javax/xml/parsers"/>
</exclude-set>
</imports>
</module>
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/755252#755252]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
