-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation: Provide guidance on where to ask GlassFish related Questions #24698
Comments
You are right, this should be improved on the website, thank you for your feedback. Meanwhile, the best places to ask questions, are:
If you have trouble getting answers, you can also contact our OmniFish team directly and ask us anything about GlassFish: https://omnifish.ee/contact-us/ |
You might consider enabling discussions on the GitHub repository. It’s a bit nicer than a mailing list I think. Just a thought… |
I would like enabling Discussions, nowadays in my circle a lot of younger developers have not used maillist at all. |
@OndroMih I would like add wizard based template to the
|
I have the same questions but mainly based on building / developing glassfish code. I looked at the slack channel but the #glassfish channel is not visible by default on the left side. You need to search for #glassfish in the top bar, select the channel there and then join the channel. You cannot read the channel without joining. Joining is a bit of a threshold holding me back since I do not know what was discussed in the past. I looked at the glassfish-dev mailing list, but it contains mainly release notes, it did not invite me to ask questions. Stackoverflow was not considered by me, I would not expect dev related questions on stackoverflow. Some basic glassfish development questions I have are: How to checkout code? I would expect it on the github page in detail, but it is located at the website, I found it via The pr_workflow documentation is good, I managed to send in a pull request using the documentation. What are the style guides?
however I could not find coding standards. Which formatting is used for new code?
Which IDEs are commonly used to develop Glassfish and how are they efficiently configured? What are the best ways to build the code. What is the main module structure? |
@escay thanks for the elaborate feedback. Many of those things are good to make clear indeed. Specially the formatting is the EE4J formatting as defined here: https://github.com/eclipse-ee4j/ee4j/tree/master/codestyle Every EE4J project should adhere to it, but of course in practice and with all the history that does not always happen.
This should be good to be documented in the packages as well. As we inherited the code base too, it's a question how useful these two really are today. I think they were brought into existence when Sun wanted to chase all the current hypes of each year. Since we only focus on building and supporting Jakarta EE, I'm not sure we need this distinction really. JBoss EAP has something similar with "WildFly" and "WildFly core": https://github.com/wildfly I'm not sure where they use it for either. |
As a small update, explicit code conventions were added here: https://github.com/eclipse-ee4j/glassfish/blob/master/CODE_CONVENTIONS.md These were taken from the Eclipse EE4J wiki, which got lost when the wiki and files moved to GitHub. |
Some other development questions I have: What is the preferred way of committing multiple fixes / creating pull requests for an issue?
Ideally I commit these as separate items, for easier code review and better commit descriptions. Is draft usage supported? Ask for help while investigating an issue TODO statements Issue closing procedure Unit test guidelines
|
Simply said, we are all people and any help is welcome. You can create an issue if you have something to elaborate in it, or document the whole process. Other people can read, give you some advices, discuss an issue, whatever. Creating an issue is not mandatory, one can create a PR without any issue, but sometimes it is better if you want "signal" that you are already working on something and other people should wait, or the opposite that you have found something broken and someone else should fix it. The issue I have with "best practices for every project" is that nobody reads them. Many people even did not read the README on the welcome page of this repository. So we mostly do the opposite - if somebody does some bad step, we will get him on track. GlassFish project is also a huge piece of software, so there are always questions if I should do this or that - and it has also some evolution, so what was not possible/good three years ago, is now alright. The project sources also are not absolutely consistent, we are slowly working on that, but there is a lot of freedom. The mandatory requirement is that every change should go in the right direction.
YES. Draft is allowed and it is a good thing to
We enabled discussions recently, but you can also ask in the issue. Sometimes it takes some time until somebody answers, you can imagine why, all reasons possible :-)
It depends, when you use * Fixes #1234567890 on the first line, GitHub automatically closes the issue after PR is merged. Otherwise we can do it manually OR we will not do that when you write to the PR that it is just a part of the work.
We use absolutely standard naming of tests. *Test for unit test (doesn't matter if with mocks) and *ITest or *IT (better) for integration tests (tests allocating ports so it could go into a conflict with other test; depends on operating system; slow test; ...).
EasyMock is preferred. But generally is recommended to use what is already used in the module (or project). Here it is EasyMock. There were (or are?) some JMockit tests too, I'm not sure now. |
Environment Details
Problem Description
Many users may be unsure about where to ask questions or seek help regarding GlassFish-related queries. Clear guidance on the website can enhance the user experience and foster a more supportive community.
Steps to reproduce
Impact of Issue
It will benefit the community especially, beginners.
The text was updated successfully, but these errors were encountered: