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(a)redhat.com>
wrote:
> On 8 Jun 2021, at 22:43, Brian Stansberry <brian.stansberry(a)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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s