-
Bug
-
Resolution: Not a Bug
-
Major
We have this special scenario where we are testing application with <app>/galleon/provisioning.xml:
<installation xmlns="urn:jboss:galleon:provisioning:3.0"> <feature-pack location="eap-s2i@maven(org.jboss.universe:s2i-universe):current"> <default-configs inherit="false"/> <packages inherit="false"/> </feature-pack> <config model="standalone" name="standalone.xml"> <layers> <include name="jaxrs"/> <include name="cdi"/> <include name="jpa"/> </layers> </config> <options> <option name="optional-packages" value="passive+"/> </options> </installation>
With EAP7 images, this app works ok, because galleon provisioning step has access maven repo integrated to S2I builder image which contains necessary artifacts (and thus we didn't have to care about any versions here).
Now with EAP8 builder image, there is no maven repo integrated, so the proposed step from analysis to use legacy S2I mode (GALLEON_USE_LOCAL_FILE=true) isn't working.
I know that file can contain concrete feature-pack GAV. But it was so tempting to use it without version for easy upgrades of images that I suppose there definitely will be someone using it like this. And for that someone the workflow would be broken now.
We even have it listed as an example in documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/getting_started_with_jboss_eap_for_openshift_container_platform/index#custom-provisioning-files-jboss-eap_default
EAP7-1734 and EAP7-1735 cover the use of feature pack (and channel) so those are obvious artifacts that need to be available in used maven repository. But the example above requires additional artifacts, not covered in either RFE, which where previously included in the image.
- is related to
-
EAPDOC-495 Migration: EAP7-1735 S2I Galleon provisioning
- Closed