[WFLY-19221] Incorporate channel metadata in the download zips #17936
Conversation
|
I manually verified that the new distributions content is identical to the existing ones with additional metadata in |
github-actions
bot
added
the
deps-ok
|
I also updated the @bstansberry I did not update the |
There was a problem hiding this comment.
@jmesnil Thanks! Please have a look at a3b0ccd -- there's some stuff in there that should be in here:
-
Consideration for the external.channels.profile. That profile isn't meant to impact the 'dist' modules, as it's just for provisioning used by the testsuite. TS doesn't test the 'dists'.
-
It uses wildfly-maven-plugin's overwrite-provisioned-server setting, and gets rid of some maven-clean-plugin cruft that's not needed when that's used.
Also, please do deal with ee-dist as well. We do distribute those, just not via the wildfly.org/downloads or the Github release page:
https://repository.jboss.org/org/wildfly/wildfly-ee-dist/32.0.1.Final/
This code will also become downstream code so we should do things consistently so we can consistently adapt to downstream use.
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
from
c3b3a07
to
16b9af0
Compare
|
@bstansberry Thanks for the review, I incorporated your changes in a3b0ccd (including |
|
@spyrkob Something I'm not sure about... The current distribution is provisioned with the universe's feature pack locations for our feature packs: (this file is identical to When I try to update it with Prospero, it fails with the error: Prospero is looking for a steam inside the channel to get the version of I tried to generate the distributions by using Maven GAVs for the feature packs (eg @spyrkob Should Prospero be able to work with universe FPL? In my case, I only produced snapshots of WildFly in my local repo cache so I'm not sure if that's a correct setup. |
|
@jmesnil we should probably find a way to support the FPL in Prospero. The easiest approach would be to add the community-universe and wildfly-producers to the WildFly channel, but like you said they're not part of the server and don't really belong there. Maybe we can create a universe channel that the WildFly channel would depend on? |
|
I see 3 possible solutions:
@jfdenise As you filed GAL-341, what do you think we should use to store the provisioning metadata in WildFly. |
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
from
16b9af0
to
5a50e06
Compare
|
@jmesnil , you should not have the transitive feature-pack wildfly-ee, the package 'docs.examples.configs' should be directly resolved from wildfly feature-pack. In addition you should remove the feature-pack versions from the plugin configuration. This versionshould not be set in a channel context. galleon.sh update expects the usage of its own channels: current, 32.0, ... in the form of wildfly@maven(org.jboss.universe:community-universe):current and doesn't work well with GAV If we want an installation to be updated from the 2 different tools, we should have the community universe in the channel. As you said that is not a big deal. The channel contains feature-pack, galleon-plugins that are not part of the server either, just used at provisioning time. |
The |
|
@jmesnil yes. |
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
2 times, most recently
from
49c04a0
to
f0d9c3b
Compare
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
2 times, most recently
from
9bb4026
to
bc966a6
Compare
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
from
7ec4680
to
4c20f1f
Compare
* WildFly full distribution is built using the wildfly-maven-plugin based on the org.wildfly.channels:wildfly channel. * WildFly ee distribution is built using the wildfly-maven-plugin based on the org.wildfly.channels:wildfly channel-ee. * WildFly Preview distribution is built based on the org.wildfly.channels:wildfly-preview channel * Generate docs from a server provisioned with wildfly-maven-plugin preview/dist, ee-dist and dist poms depends on the channels artifacts to ensure that they are build first so that the distributions can use them during provisioning. JIRA: https://issues.redhat.com/browse/WFLY-19221 Signed-off-by: Jeff Mesnil <[email protected]>
so that they are in the generated manifest for wildfly, wildfly-ee & wildfly-preview channels. Signed-off-by: Jeff Mesnil <[email protected]>
Add a <name> parameter to the wildfly-maven-plugin configuration so that the channels that are stored in the metadata installation are named. Signed-off-by: Jeff Mesnil <[email protected]>
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
from
4c20f1f
to
df0aa83
Compare
| <exists>true</exists> | ||
| </file> | ||
| <file> | ||
| <location>target/${server.output.dir.prefix}-${server.output.dir.version}/.installation/manifest_version.yaml</location> |
There was a problem hiding this comment.
Just a note, manifest_version.yaml and provisioning_record.xml are both optional files, not sure if they need to be verified.
| @@ -545,6 +545,8 @@ | |||
| <version.org.jboss.spec.jakarta.el.jboss-el-api_5.0_spec>4.0.1.Final</version.org.jboss.spec.jakarta.el.jboss-el-api_5.0_spec> | |||
| <version.org.jboss.spec.jakarta.xml.soap.saaj-api_3.0_spec>1.0.0.Final</version.org.jboss.spec.jakarta.xml.soap.saaj-api_3.0_spec> | |||
| <version.org.jboss.spec.jakarta.xml.ws.api_4.0_spec>1.0.0.Final</version.org.jboss.spec.jakarta.xml.ws.api_4.0_spec> | |||
| <version.org.jboss.universe.community>1.2.0.Final</version.org.jboss.universe.community> | |||
| <version.org.jboss.universe.producer.wildfly>1.3.11.Final</version.org.jboss.universe.producer.wildfly> | |||
There was a problem hiding this comment.
I'm not sure if that matters, but are the producer artifacts updated before or after WildFly release?
For example before WildFly 33.0.0.Final is released, do we need to release the producer artifact including the Galleon channel 33.0 so that we can include it in the wildfly channel?
preview/dist and dist poms depends on the channels artifacts to ensure that they are build first so that the distributions can use them during provisioning.
This is required for wildfly/wildfly-proposals#577
JIRA: https://issues.redhat.com/browse/WFLY-19221