wildfly-proposals
wildfly-proposals copied to clipboard
wildfly
[WFLY-14411, Bootable JAR] Server components upgrade and Galleon feature-pack dependency update
Can you add something to this related to the transformation process used with the wildfly-preview FP?
My hope is what's described here is handled prior to the transformation; i.e. this changes how the set of relevant artifacts is determined, and then provisioning deals with the transformation, with no need to care that this happened.
My last sentence is not meant as suggested requirement text for this analysis; it's just my thinking out loud about what this does. :)
EDIT: Jeff addressed this input.
I recommend something in the non-requirements section re there being no requirement related to support for this in other Galleon contexts, e.g. s2i, non-bootable-jar maven-driven provisioning, or Galleon CLI. Or, if those are impacted, the requirements need to be spelled out.
The Galleon CLI one I mention to be complete (which is good in an analysis) but that one is pretty obvious as there is no maven involvement there. But s2i and other non-bootable-jar maven-driven provisioning are not so obvious as it's not clear why this would not be implemented via changes in the general Galleon maven plugin, as opposed to the bootable jar one.
EDIT: Jeff addressed this input.
@bstansberry , thank-you I clarified impact on Preview and Generic galleon provisioning for which server component upgrade is made possible but not in the scope of this RFE.
@bstansberry , I have added the ability (thanks to a system property) to dump to an xml file the set of artifacts (FP dependencies and server artifacts). This makes what can be actually upgraded less hidden. In addition I mentioned that downgrade is possible, a warning is displayed in this case.
@bstansberry , my changes are not yet correct, I pushed the button too early. Will ping you when you can review.
@bstansberry , the analysis changes are done. Sorry for the noise. I realized that we should reduce the scope to "provisioned artifacts" instead of "all artifacts" that doesn't help to identify the artifacts that can be upgraded for a given Bootable JAR.
it's not clear why this would not be implemented via changes in the general Galleon maven plugin, as opposed to the bootable jar one.
Is this answered somewhere? I see as reaction this was added [1], but I do not see answer to this question. Could reasoning be added somewhere.
I believe this also relates to my question about "unified patching mechanism" [2]
[1] https://github.com/wildfly/wildfly-proposals/compare/a812a3ac5e847da1315e0d88a68593d6dc94cbb8..e8636df7679af00ef33f5fbd04ef01d81bf65954 [2] https://github.com/wildfly/wildfly-proposals/pull/372#discussion_r590309170
@mchoma , I am adding some context. We attempt to hide Galleon specifics to expose a "Maven like" way to upgrade dependencies. Galleon approach would require the creation of Galleon patches (one per feature-pack that contains artifacts that we want to upgrade) that would capture the artifact upgrades. Galleon patches can be applied on top of an existing installation provisioned with Galleon or during provisioning of a new server (bootable JAR or new filesystem installation). With this proposal we don't require the creation of Galleon patch for the smallest update. We dynamically inject version upgrade during provisioning. We are not injecting this information at the Galleon level, Galleon generic provisioning has no notion of Maven artifact (only package). The injection is done at the "WildFly Galleon plugins" level. We have defined an option recognized by the plugin to convey artifacts to WildFly feature-packs. One could use Galleon directly with this option to upgrade artifacts, but this would be far away from the Maven way.
@honza-kasik @bstansberry , as agreed with QE we will not integrate the support for "per feature-pack" upgrade in this release, this limitation will be documented. The complexity it brings is too much for this release.