On Fri, Feb 28, 2025 at 11:58 AM Emmanuel Hugonnet <ehugonne(a)redhat.com>
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> 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>
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>
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> 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> 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> 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