[wildfly-dev] Re: Use of the 'org.wildfly' groupId

On Fri, Feb 28, 2025 at 11:58 AM Emmanuel Hugonnet <ehugonne(a)redhat.com&gt; wrote: Inline Le 28/02/2025 à 18:40, Brian Stansberry a écrit : > I'll think out loud so people can correct my thinking... > > This is more complicated to me than the grpc one as 'ai' is much more broadly scoped. > > For some context, part of the issue that led to this overall thread is creating an updated permission scheme for deploying artifacts to > JBoss Nexus. That's easier to do if the same set of people can deploy everything in a given groupdId. If you have unrelated people sharing > the same groupId, then you either have a potentially wrong set of people able to deploy or you need to start enumerating artifacts and > giving perms based on artifact lists or artifact name patterns. Harder to maintain. > > So, org.wildfly.ai <http://org.wildfly.ai> <http://org.wildfly.ai> is much more likely to result over the years in different sets of people deploying than, say, > org.wildfly.grpc is. I totally agree thus my idea of reducing the scope by using fp. Maybe something like org.wildfly.ai.llm or org.wildfly.generative-ai that could be a little more specific. Will the artifacts you're producing remain scoped to llm?

Emmanuel > > That said, 'org.wildfly.ai <http://org.wildfly.ai> <http://org.wildfly.ai>' is probably ok. If someone comes with something new *and* it really doesn't fit with > the permission scheme, we can require them to use groupId org.wildfly.ai.foo. > > BUT if you can come up with your own, good, 'foo' right now, that would be nice. If you can't, go with 'org.wildfly.ai <http://org.wildfly.ai> > <http://org.wildfly.ai>';. > > To me 'org.wildfly.feature-pack' doesn't seem like a good category. I can easily see a given repo producing artifacts that are only > semi-related to 'feature-pack'. For example a maven module producing a WildFly Extension impl is only semi-related to 'feature-pack'. > Extensions artifacts are usable in any feature pack, and we've been using extension artifacts for many years before Stuart Douglas > introduced the original feature pack concept. Artifacts like that, or other things like backing libraries, may some day end up in a code > base completely separate from the Galleon-related stuff. > > > On Fri, Feb 28, 2025 at 9:50 AM Emmanuel Hugonnet <ehugonne(a)redhat.com&gt; wrote: > >     Hi >     Would "org.wildfly.ai <http://org.wildfly.ai> <http://org.wildfly.ai>" be ok as groupId for ai fp ? or should we go to something more explicit like >     "org.wildfly.feature-pack.ai <http://org.wildfly.feature-pack.ai> <http://org.wildfly.feature-pack.ai>" ? >     Emmanuel > > >     Le 28/02/2025 à 16:31, Brian Stansberry a écrit : >     > No, I'd prefer not to go off on a renaming exercise. >     > >     > The one exception to that is https://github.com/wildfly-extras/wildfly-grpc-feature-pack, which has never produced a 1.x release; >     latest >     > is 0.1.11. I think a breaking change can be expected in a 0.x release. Harald, if you agree can you make a note to get that changed >     before >     > we do anything that more closely ties that repo to our end users? >     > >     > Beyond that, if people reading this manage wildfly-extras projects and think a change is appropriate, let me know what the new groupId >     > will be. But if you're talking about changing something that may break appserver end users (e.g. the GraphQL feature pack), let's >     not. And >     > if something will need a lot of discussion, let's not. Better things to do. :) >     > >     > On Thu, Feb 27, 2025 at 10:04 PM Jason Lee <jasondlee(a)redhat.com&gt; wrote: >     > >     >     This all sounds good to me. It would be a breaking change, of course, but could/should "we" strongly encourage those other repos to >     >     change their group ID? >     > >     >     Jason Lee >     > >     >     Principal Software Engineer >     > >     >     Red Hat JBoss EAP >     > >     >     Java Champion >     > >     > >     > >     > >     >     On Thu, Feb 27, 2025 at 7:30 PM Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >     > >     >         Also, no org.wildfly.extras.*. >     > >     >         The wildfly-extras github org is largely meant to serve as an incubating space for stuff that may at some time move to the >     wildfly >     >         GH org. So putting 'extras' in the package name is taking something possibly temporary and putting it into something that's >     likely >     >         permanent. >     > >     >         On Thu, Feb 27, 2025 at 6:06 PM James Perkins <jperkins(a)redhat.com&gt; wrote: >     > >     >             +1 I any project outside of the wildfly/wildfly repository should be using a different groupId. >     > >     > >     >             James R.Perkins >     > >     >             Principal Software Engineer >     > >     >             Red Hat<https://www.redhat.com/> >     > >     >             <https://www.redhat.com/> >     > >     > >     >             On Wed, Feb 26, 2025 at 6:53 PM Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >     > >     >                 Currently we have a number of different repos publishing artifacts using the 'org.wildfly' groupId with no further >     >                 namespacing. >     > >     >                 Going forward I don't think we should allow any other new repos to do that. It leads to administrative hassles, e.g. >     with >     >                 setting things up in Nexus. >     > >     >                 Best regards, >     > >     >                 -- >     >                 Brian Stansberry >     >                 Principal Architect, Red Hat JBoss EAP >     >                 WildFly Project Lead >     >                 He/Him/His >     >  _______________________________________________ >     >                 wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >     >                 To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >     >                 Privacy Statement: https://www.redhat.com/en/about/privacy-policy >     >                 List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >     > >     > >     > >     >         -- >     >         Brian Stansberry >     >         Principal Architect, Red Hat JBoss EAP >     >         WildFly Project Lead >     >         He/Him/His >     >  _______________________________________________ >     >         wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >     >         To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >     >         Privacy Statement: https://www.redhat.com/en/about/privacy-policy >     >         List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >     > >     > >     > >     > -- >     > Brian Stansberry >     > Principal Architect, Red Hat JBoss EAP >     > WildFly Project Lead >     > He/Him/His >     > >     > _______________________________________________ >     > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >     > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >     > Privacy Statement: https://www.redhat.com/en/about/privacy-policy >     > List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >     _______________________________________________ >     wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >     To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >     Privacy Statement: https://www.redhat.com/en/about/privacy-policy >     List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His