Support for GlassFish Docker in the archetype

[OndroMih]

This adds support for GlassFish Docker into the archetype:

 mvn archetype:generate -DarchetypeGroupId=org.eclipse.starter -DarchetypeArtifactId=jakarta-starter -DarchetypeVersion=2.4.0-SNAPSHOT -Druntime=glassfish -Ddocker=yes -Dprofile=full -DjakartaVersion=10 -DjavaVersion=17

Only for the above parameters (EE10, Java 17, Full profile).

• first commit adds the functionality
• second commit adds tests into the Github workflow

If this PR is merged, I plan to add support for GlassFish Docker in the UI and also add tests that cover other runtimes.

[m-reza-rahman]

Could you kindly try to minimize the white space only changes? It is really difficult to see what the actual changes are and it also pollutes the change log. If they are really necessary, please create a separate PR for the desired white space changes?

Once that is done, I would also like to understand why so many new files are needed for a seemingly small set of new features.

[OndroMih]

The big amount of files is for the tests. The tests verify that the generated project contains expected files. Maybe the tests are not needed as the Github workflow covers some of the cases and uses the appropriate Java version. I just used them to run tests locally.

[eclipse-starter-bot]

Can one of the admins verify this patch?

[m-reza-rahman]

OK. Can you please enhance the nightly build if required: https://github.com/eclipse-ee4j/starter/blob/master/.github/workflows/nightly.yml? It should provide reasonable test coverage.

[OndroMih]

I removed the tests in maven build and added some tests to the main and nightly builds.

[m-reza-rahman]

OK. Eventually we can look into moving the tests into the Maven build if there is a reasonable way.

Please do address the extraneous white space changes before I can review for a merge. Do note, there is a reason the white space is the way it is. It avoids users encountering strange formatting as Velocity does not ignore white spaces in the output, even when placed in the same line as conditionals.

[OndroMih]

I removed all the unnecessary extraneous white space changes.

I kept the extra spaces in velocity templates to indent blocks and added maven antrun plugin that removes them during the build. Without indenting velocity templates, it's hard to understand them. If you want, I can submit this change as a separate PR. Or even before this PR, as it would be easier to review my changes once the velocity templates are indented.

[m-reza-rahman]

Yes, please make that a separate PR to keep the change log clean. I’ll also need to ensure there are no unintended side effects. Since that’s not a functional change, it can be done after the functional change.

[OndroMih]

I created a separate PR only with the indentation changes here: #327

Until that one is merged, I changed this PR to draft.

[OndroMih]

I rebased on top of the current master, which already contains the Velocity indentation. So this PR contains only changes related to GlassFish and Docker.

[m-reza-rahman]

OK. I plan to look at this once the EE 11 support is well in hand.

[hantsy]

Great to include this as soon as possible.

[m-reza-rahman]

Hi @OndroMih, my plan is to look at this next weekend. Can you kindly do me a favor and try to sync with the latest code (ideally both UI and Archetype)?

[OndroMih]

@m-reza-rahman, done.

There are only archetype changes in this PR. UI changes will follow in another PR.

When I tried to do it initially in this PR, I couldn't figure how to do it in the UI properly, I always broken something. I'd like to refactor the UI so that it's easier to modify without breaking some rules. I'd like to do these things step by step, rather in a single PR, so that it's easier to review.

[m-reza-rahman]

OK. If it’s more than trying to simplify the validation logic (which is more than welcome), I ask that we kindly discuss the changes before necessary making a PR. The current functionality is based on project consensus, but obviously nothing is set in stone.

You can always leave the UI changes to me for this time. You could review my changes for future reference too. It’s really just a matter of thinking through the validation cases, at least for me.

[OndroMih]

I don’t want to change anything in the UI. I just found it very error-prone to modify the validation logic even when I just tried to add docker option to GlassFish. And I couldn’t grt it right even after a few hours of trying. If you can ipdate the UI to add Docker for GlassFish, I’m fine with that, and would be frateful to you. Then I don’t need to change anything. Ondro

…

On Sun, 23 Feb 2025 at 16:57, Reza Rahman ***@***.***> wrote: OK. If it’s more than trying to simplify the validation logic (which is more than welcome), I ask that we discuss the changes before necessary making a PR. The current functionality is based on project consensus, but obviously nothing is set in stone. You can always leave the UI changes to me. You could review my changes for future reference too. It’s really just a matter of thinking through the validation cases, at least for me. — Reply to this email directly, view it on GitHub <#326 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYEFGALUWR7WMSS3A2JU32RHVWHAVCNFSM6AAAAABMPJW5AKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWHE2TOMJSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: m-reza-rahman]*m-reza-rahman* left a comment (eclipse-ee4j/starter#326) <#326 (comment)> OK. If it’s more than trying to simplify the validation logic (which is more than welcome), I ask that we discuss the changes before necessary making a PR. The current functionality is based on project consensus, but obviously nothing is set in stone. You can always leave the UI changes to me. You could review my changes for future reference too. It’s really just a matter of thinking through the validation cases, at least for me. — Reply to this email directly, view it on GitHub <#326 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYEFGALUWR7WMSS3A2JU32RHVWHAVCNFSM6AAAAABMPJW5AKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWHE2TOMJSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[m-reza-rahman]

OK, no problem. I'll handle the UI part. Maybe I could go over the changes with you once they are done? There is no denying the validation logic is involved. I would love to see what could be done to improve it and also see if other folks could do the work when needed. However, this is definitely a lower priority than simply getting things done.

[OndroMih]

Currently, I have no concrete idea how to improve the validation logic. I only wasn't able to amend it for GlassFish in Docker correctly, and that blocked me from updating the UI.

From my experience, it's better to use declarative rules, and refresh each component to update according to the rules and the state. So that the rules need to be changed only in a single place. The current solution with change listeners, which update the model according to a recent change in the form, is really hard to maintain, and requires changes in all the change listeners.

I would suggest that there's a single method recomputeOptions, that would simply recompute all the available options based on the current selections in the form. This method would be called on each change, and would update all the selector components. The controller (JSF) updates the chosen options, which would trigger recomputation of the available options and render the view. The recomputeOptions method would be easy to test. If it works correctly, it would guarantee that the form would match the rules in all cases, because the form would just reflect the recomputed data.

[m-reza-rahman]

OK. An idea worth pursuing. Let me give it some thought once things slow down a bit.