[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
2 times, most recently
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.
There was a problem hiding this comment.
They are bundled in the distributions so let's assert that they exist for the time being.
I prefer that this test will catch it whenever we eventually decide to remove it instead of them "disappearing" silently.
|
retest this please |
jmesnil
force-pushed
the
WFLY-19221_channel_metadata_in_distributions
branch
from
df0aa83 to
b3f54c1
Compare
|
@bstansberry Failing tests have been fixed and the PR should be ready to merge |
* 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
b3f54c1 to
312696b
Compare
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