To the best of my knowledge, all relevant domains have already been donated, and Brian Proffitt has been directly involved in coordinating this effort.
Some of the package prefixes listed - such as org.uberfire and com.ait.lienzo - are tied to legacy components that are no longer actively developed and are expected to be entirely removed in the relatively near future. Regarding drools.org, there’s an ongoing thread discussing its redirection: https://lists.apache.org/thread/o3b8p7zn0snsrybmogxp8txl5jwqc9sr Regarding domain maintenance, I would like to note that, as a PPMC member of the KIE project, I’m personally committed to covering any costs associated with the domains that require preservation (org.kie, org.drools. org.jbpm, and alike). - Alex On Thu, Jul 3, 2025 at 9:09 AM PJ Fanning <fannin...@apache.org> wrote: > > Would it be possible to consider getting the drools.org domain donated > to the ASF and https://www.drools.org/ to be redirected to Drools > pages on https://kie.apache.org? > > The KIE tools repo has so many different package prefixes. Would it be > possible to cut down on them by moving some of them to org.apache.kie > or org.kie (latter if ASF owns that domain). > https://github.com/search?q=repo%3Aapache%2Fincubator-kie-tools++language%3AJava&type=code > > Some package prefixes from the first few pages of results on above link > org.yard > com.ait.lienzo > org.jboss > org.kie > org.uberfire > org.eclipse.bpmn2 > javax > > On Thu, 3 Jul 2025 at 13:44, Alex Porcelli <a...@porcelli.me> wrote: > > > > The impact on KIE would be significant if we were required to change > > core package names like org.drools. > > > > Drools is one of the most widely adopted rule engines in the > > enterprise space. Core components such as drools-compiler, a > > dependency used in virtually every Drools-based application, have been > > around since at least 2008. While the engine itself has evolved over > > the years, the community has consistently prioritized minimizing > > disruption for users who have relied on Drools for over 20 years. > > > > Such a change would also impact jBPM users, as it shares many of the > > same foundations and is widely used across the industry. This > > disruption would put stress on the large community of users of Apache > > KIE technologies. > > > > For this reason, I would urge the ASF to consider this carefully when > > evaluating expectations around forcing package renaming. > > > > - > > Alex > > > > On Thu, Jul 3, 2025 at 1:40 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > > Hi PJ > > > > > > By default, the package names should start with org.apache. > > > However, I remember we accepted (exceptional) other package name for > > > existing projects joining the incubator as it impacts the existing > > > community. I would consider more as a "transition" period. > > > > > > Regards > > > JB > > > > > > On Wed, Jul 2, 2025 at 10:59 PM PJ Fanning <fannin...@apache.org> wrote: > > > > > > > > Hi everyone, > > > > I couldn't find any discussions online so I thought I'd raise one. If > > > > there is a pre-existing answer somewhere please let me know. > > > > I'm wondering if Apache projects/podlings are required to use > > > > org.apache... package names. > > > > The one exception that I know of is KIE which has a pretty dizzying > > > > array of package names, few if any are org.apache namespaced. > > > > One example is org.drools. Maybe it is an unimportant norm but > > > > ideally, this would mean the drools.org domain is controlled by the > > > > ASF. > > > > The website https://www.drools.org/ does not appear to be Apache > > > > branded. > > > > I'm not looking to block KIE releases but I'm wondering if ultimately > > > > we should be expecting them to change the package names. > > > > In a quick look at the KIE issues, I found none related to package > > > > renaming. I created a couple because of this and will happily close > > > > them if the ASF doesn't worry about such things. > > > > Any guidance would be appreciated. > > > > > > > > Regards, > > > > PJ > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
