There’s absolutely no harm in asking the Eclipse Foundation. I do suspect they’ll say what Ivar pretty much already has - that this is ultimately up to the project and the specification committee when it comes time to approve a release as part of normal process, not the Foundation.
I don’t think we should be taking hardline stances over what’s probably in the end just a matter of taste. There is no absolute right or wrong answer here. For example, if the specification committee feels differently from the project, it’s not exactly the end of the world.
I am unsure it’ll make matters any better, but I’ll try to share a perspective anyway just one last time. I suspect most are seeing it this way too.
* One simple group ID is probably easier for end users in the end. These are all very closely interconnected things made by the same set of people and there isn’t that many different APIs to consider anyway, probably even in the far future. * We are the forerunner specification in this space and probably will be the driver for the rest too, possibly for some time. It’s appropriate from that perspective we just use jakarta.ai. * There is already some precedent, so it’s obviously fine and not really that big a deal in the end. You could, for example, take a look at jakarta.enterprise. You’ll see artifacts directly published there, possibly for some of the same reasons. * We don’t even know yet if and when there will be any future AI specifications or who will be involved in it - though I do suspect it’ll be many of the same people already involved here. They are free to make their own choices when time comes. One sensible, valid option is to keep it KISS and also just use jakarta.ai instead of possibly completely unnecessary long convoluted paths.
Of course we don’t all have to agree in the end. Such is life and it’s all good! On Mar 11, 2026, at 6:59 AM, Piotr Żygieło via agentic-ai-dev <agentic-ai-dev@xxxxxxxxxxx> wrote:
Can you clarify what you mean by Sonatype namespace?
I'm not against using ' jakarta.ai' as the root name.
But I'm -1 on placing every agentic-ai-* artifact _directly_ in jakarta.ai
I'd never speak about that if not for: > all future AI work into one neat place such as jakarta-llm or jakarta-mcp
I understood from that LLM, MCP mentioned above and whatever else to be SEPARATE Specifications that do not exist NOW. Not under Agentic AI one that's preparing the field for itself and others.
Pretend there is LLM AI Specification right now. Noone from Agentic AI is participating there. It's a completely separate group of people. And this LLM AI Spec wants to publish its 'jakarta.ai:jakarta.llm-ai-api'. Depending on namespace partitioning - which I numbered 1a 1b previously - it's either - 1a jakarta.ai - already claimed by Agentic AI, so it needs to be shared - and all sharing parties might publish to every subpath groupId/artifactId.For that reason I think this is unwanted to share namespace access between specs. - 1b every single subpath is a new namespace (with plenty to come) - but it's not possible to publish to several namespaces in one go. For that reason I think this is unwanted as well.
Thus I propose to unflatten this a bit and have `jakarta.ai.agentic (or whatever)` as namespace and starting point for groupId.
Seeing that it bothers just me - I should blame myself for being unable to explain myself.
And as everybody is so happy with all the binding votes to be +1 - I'll need to accept that.
If you're referring to the repository name, I don't believe that's what we're talking about here and that has a separate process (which I don't know in detail ottomh).
Not about repository names.
My (very rough!) understanding of it is that each project gets their own staging repo,
Projects need not to use staging repo but can choose, and few do so already - to publish directly to Central.
But even there the project will be able to publish only to specific namespace/groupIds.
Past that, we're just into uploading to Maven Central, which is a separate process again but I believe is handled by the parent pom:
But the parent pom says nothing about privileges to namespaces.
-- Piotrek
|
