[WFLY-20810] WildFly Maven Plugin, bootable JAR packaging for the cloud#748
[WFLY-20810] WildFly Maven Plugin, bootable JAR packaging for the cloud#748jfdenise wants to merge 1 commit intowildfly:mainfrom
Conversation
github-actions
bot
added
the
stability-level/community
bstansberry
left a comment
bstansberry
left a comment
There was a problem hiding this comment.
A general comment is I think the Overview can be much simpler and the Hard Requirements should be more expansive. Don't use the Overview to detail the feature. Most of what's in 'WildFly and the cloud galleon feature-pack' and below in the Overview can be reduced to a few sentences that say that a feature pack to adapt a bootable jar to the cloud environment is needed, but the existing org.wildfly.cloud:wildfly-cloud-galleon-pack is tightly coupled to the s2i use case and isn't appropriate. So a new feature pack will be added.
Formally list hard requirements so those reviewing the feature can clearly see what will and won't be done. Don't make them parse the Overview etc to get that.
github-actions
bot
added
stability-level/community
|
@bstansberry @jmesnil @fabiobrz , I have reworked the proposal to have the cloud feature-pack usable with Bootable JAR. I also covered in details the impact. |
|
Thanks @jfdenise - I am off this week, but will review as soon as I will be back. |
github-actions
bot
added
stability-level/community
github-actions
bot
added
stability-level/community
|
|
||
| ==== Excluding logic executed at boot time | ||
|
|
||
| * When provisioning a server installation, the package `org.wildfly.cloud.bootable.runtime` can be excluded. |
There was a problem hiding this comment.
What does can be excluded mean ? Why user may or may not explicitly remove it?
When server is provisioned, I would expect org.wildfly.cloud.bootable.runtime would be excluded automatically, because it can do some problems.
There was a problem hiding this comment.
The package doesn't cause problem. We have modules that are installed although not used. Excluding it is for trimming even more your installation.
There was a problem hiding this comment.
So the question is if we want wildfly-maven-plugin to be smart and when we know we have module which is not used for bootable-jar, why dont we exclude it right away? Or we are afraid this kind of logic will be hard to maintain, buggy etc. ?
There was a problem hiding this comment.
Personally I'm uncomfortable with spreading logic about what gets provisioned across code bases. That quickly leads to things happening via a kind of black magic that only one or two people understand, and probably one of them forgets about it after a couple years or moves on from involvement.
That's my overly verbose way of saying "hard to maintain / buggy'. ;-)
| ==== Excluding logic executed at boot time | ||
|
|
||
| * When provisioning a server installation, the package `org.wildfly.cloud.bootable.runtime` can be excluded. | ||
| * When provisioning a bootable JAR, the package `org.wildfly.cloud.launch.scripts` can be excluded. |
There was a problem hiding this comment.
Same, the package can stay no side effect. It is a mater of trimming.
4 participants
Issue: #747