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...

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

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... >

Hi Would "org.wildfly.ai" be ok as groupId for ai fp ? or should we go to something more explicit like "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...

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> 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.

Emmanuel > > That said, '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>';. > > 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>" 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>" ? > 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

Le 28/02/2025 à 20:54, Brian Stansberry a écrit : > > > 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? Well I provide also MCP server feature but all is around LLM or Small 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

For the gRPC feature pack we currently have Group ID: "org.wildfly.extras.grpc" Package name: "org.wildfly.extension.grpc" I guess the package name should stay as it is. For the group ID we could use "org.wildfly.grpc".

// Harald _______________________________________________ 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...

I filed https://github.com/wildfly-extras/wildfly-grpc-feature-pack/issues/307 to track this. // Harald _______________________________________________ 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...