Also +1 to removal.

One motivation was to compare the Galleon releases were the same as the legacy releases - we are now at the point that Galleon needs to be able to progress independently.  If we still want to double check changes checking against the prior WildFly release would be more suitable.

On Wed, Jun 9, 2021 at 8:38 AM Jean-Frederic Mesnil <jmesnil@redhat.com> wrote:


> On 8 Jun 2021, at 22:43, Brian Stansberry <brian.stansberry@redhat.com> wrote:
>
> Since the WildFly 13 release when we began producing the official WildFly distributions using Galleon, we've continued as well to produce the old 'legacy feature packs' that use pre-Galleon technology. We did this because there were some projects that still used them for provisioning servers based on the WildFly technology stack. But I believe those cases are gone now, and in any case after three years IMHO it's time for those kinds of things to move on.
>
> Producing the legacy feature packs is a fair amount of work and is starting to interfere with how we'd best organize the code for production of the Galleon feature packs. So I'd like for WildFly 24 to be the last release where we produce them.
>
> Inputs on this are welcome.
>
> The maven GAs of the artifacts I'm talking about are:
>
> org.wildfly.core:wildfly-core-feature-pack
> org.wildfly:wildfly-servlet-feature-pack
> org.wildfly:wildfly-feature-pack

I'm +1 to remove it.

We have been capitalising on Galleon to build WildFly for a few releases now.
Producing (and maintaining) another way to deliver WildFly is preventing us to move forward.

Regards,
jeff

--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s