We are working to provide a community of, and for, interested product developers. Community feedback is encouraged. We'll do our best to find answers to your questions, give you tips, and get you going. To join our community, you must do the following:
1. If you are not a member of dev.java.net, click on the Register link in the upper right hand corner of this page to register your user name and create a Java.net user ID.
2. Click on the link below to join the Open MQ project.
Specify the role you are interested in and submit your request though at this time we are only accepting Observer members.
Be patient! You will receive an email when your request is approved.
3. To post comments about the product, how it is used, problems, etc. please write to firstname.lastname@example.org. We'll do our best to get you a response.
4. Joining the Open MQ project does not automatically subscribe you to the MQ mail list alias. If you want to receive announcements, or join in the conversation (or just monitor how others are getting along) you are welcome to join any mailing list on this page. We'd love to hear from you! You will find more community contribution options at this page.
If you are using the source code -- having problems with the build instructions, or just wondering why the code is written the way it is, send us a note on email@example.com.
Anyone, Open MQ project member or not, can contribute to the user community. You can do this by posting to the e-mail lists (firstname.lastname@example.org or email@example.com). We strongly encourage all members to join these alias lists, as well as the Open MQ Forum. These lists are moderated to reduce SPAM. If you are not a member of the alias, your message will be reviewed prior to posting. This is only to prevent unwanted SPAM e-mail.
These contributions are extremely valuable and help the development community make better decisions about what features are working well, and where we can focus our attention better.
Anyone can post any issues (bugs, product requests, Etc.) using issue tracker. To do this, click the Issue Tracker link on the navigation bar to the left.
In addition, you might be able to find answers to your questions by searching or browsing through the community feedback at the Java Message Queue forum. To Join this forum, you will need a separate Software Developer Network user ID. Once you have that ID, you can subscribe to the Open MQ forum, or any of several hundred technical and community forums that are hosted by Sun.
If you are interested in contributing some source-code, or anything that you would like to become part of the community release of Open MQ, please read further...
We welcome contributions, but, at this time we are not able to take direct contributions to the source code, via our on-line repository. We are happy to accept your contributions and request that all contributors complete the Oracle Contributor Agreement. This protects your rights as well as ours, and other users of this community project.
Before submitting anything, please contact us via the developer alias first so that we can give you further details about how to go about submitting your addition. If you are interested in this, we suggest you review the contributor details (see the section about code and samples) in the GlassFish Server Open Source Edition project for more details.
Since MQ is a rather complex product and, we have many customers who rely on continued reliability and compatibility, we have a rather prescriptive process for developing new features. I won't describe that completely here, but I will offer a couple of documents which can help you see what types of considerations we make, before implementing anything more elaborate than a bug-fix.
We generally try to describe what we are going to do, with the following documents. Have a look:
Onepager -- HTML
Functional Specification -- HTML -- In this document are links to existing submissions that are on-file with the Open Solaris ARC.
We use the "You are responsible for considering everything that's asked about, in these documents. You can exersize your good judgement and decide which sections are required and which can be ignored. " We assume anyone who'd want to make a contribution would do so in a professional and complete manner. Just because you don't fill in the section, doesn't mean you aren't responsible for knowing the answer.
In general, the Onepager is written first and then, we decide if the feature request / proposal should be implemented. If we decide to proceed, code development then gets underway (ok, it's not always this clean, but this is what we strive for). Once the feature is far enough along, and certainly before it's determined to be "feature complete," we create the Functional Specification. Between these two documents, it should be possible to schedule, monitor, and predict when the feature will be completed; it should be possible for a documentation writer to describe the feature (or, at least, interview the developer more effectively about what to write); and it should be possible to write Quality Engineering test development plans to ensure that the feature has been fully implemented and can be verified for some level of correctness.
We are interested in your contributions. We do think that many of our community users will find that using IssueTracker is just fine to meet their needs. For those who do want to make contributions, please join us on the firstname.lastname@example.org alias.