Hi Mark,
Thanks a ton for the detailed reply, which makes a lot of sense to me.
Given that, I see no strong argument or reason to further hold up the
(re)quest to keep using org.netbeans for Maven GroupId.
Assuming of course all the technical and administrative hurdles with
Nexus and Sonatype can and will be dealt with appropriately.
So +1 on this from me.
A few comments and remarks inline below.
On 25/03/2019 19.36, Mark Struberg wrote:
Uff, quite a few questions. And really good ones! I try to play devils
advocate.
1) If the ASF owns the NetBeans mark and the netbeans.org domain it doesn't
make any legal difference if we call the groupId org.apache.netbeans or just
org.netbeans. Or even foo.netbeans.
2.) The referenced page with the artifact publishing guide lists it as SHOULD
and not as MUST.
Right, I should have noticed that.
3.) While org.apache.* is definitely preferred nowadays there are plenty ASF
projects which use a different groupId for historical reasons. Please check out
https://repository.apache.org/#view-repositories;releases~browsestorage
I wouldn't say 'plenty ASF projects'.
I just checked it out and besides freemarker and only a few recent
commons "maintenance" releases, all other releases not under the
org.apache groupId are at least from 2 or several more years ago.
In contrast to the like 100+ ASF projects which now are released under
the org.apache groupId, including many/most new commons releases.
So, while it may be OK and desired for NetBeans to keep using the
org.netbeans GroupId, IMO it is and remains 'uncommon' :-)
4.) The Branding is imo rarely related to the Maven groupId. The groupId is for
technicials to have a technical reference coordinate. The Branding is done on
the user facing level.
Sure, that makes sense to me as well.
However this isn't really made clear or explicit, at least not to my
understanding.
That said: I assume this 'problem' doesn't come up so often in practice
that it needed explicit attention in the policy.
5.)
But given the ongoing discussions with respect to externally hosted> 'binary'
releases (like on dockerhub) and especially how these should be
controlled and marked (branded) by the ASFNobody should be allowed to push
anything to any package name the ASF controls. This is simply something we have
to make clear with Sonatype, dockerhub and our infra. Sonatype eg has some
pretty strict control in place to forbid 'injection' of artifacts into foreign
groupIds.
6.) NetBeans is not only just an IDE but really a much bigger ecosystem!If we
change the groupId - or even worse the package names - then we break all the
projects depending on NetBeans for their own stuff. Be it plugins which
probably won't compile with new NB versions anymore. Or be it Editor projects
based on the NetBeans core.
NetBeans is actually not just an IDE and an ecosystem but also a modular
environment. A little bit like OSGi, but much more straight. There are many
dynamic processes involved which are based on names and reflection. Honestly I
do not really see a benefit in moving to org.apache.* for the groupId or
package names. Of course it would be more sane NOW, but it would most probably
be really disruptive for the whole surrounding projects building on top of
NetBeans core technologies.
Does this make sense?
Yes.
As you said, *if* doing a groupId change, NOW would be the more sane
time to do so.
And when not done now or soonish, more likely it won't be done at all,
ever.
Ultimately that is a decision for the (P)PMC and community to make, as
long as it is allowed and aligned with the ASF rules and policy.
Regards, Ate
LieGrue,strub
On Monday, 25 March 2019, 15:09:09 CET, Ate Douma <a...@douma.nu> wrote:
On 25/03/2019 12.59, Mark Struberg wrote:
We did have this discussion over a year ago with Greg Stein.
Back then the blocker was indeed the missing trademarks for 'NetBeans'.
With this resolved there is no legal problem anymore afaict.
Yes, the ASF by default prefers to use the org.apache.* groupIds. Mostly
because there is no exceptional management necessary in our Nexus
staging setup. But we have quite a few projects using other package
names. E.g. commons still publishes maintenance versions for commons-*
as groupId.
+1 for the Infra ticket as it might be some manual work for them to
allow NB to use org.netbeans.* as groupId. Please make sure to mention
that we need this package name for backward compatibility reasons.
I'm not sure about trademarks@a.o involvement. What do trademarks have
to do with our package name? It's _not_ about the domain, it's about
technical coordinates. Since we (ASF) now own the trademark on
'NetBeans' there is not much to clarify with them imo. It's really more
an infra thingy as this doesn't nicely fit into our
org.apache.${project} schema which is a proven path for them.
Hi Mark,
You may be completely right about this. The uncertainty I have (or had)
was not related to trademarks but the *branding*, which happens to be
handled by the same committee.
I cannot find any public policy document at the ASF clarifying the
desire or possibly requirement how a Maven GroupId may or should be
used from branding POV.
The only practical documentation available with respect to Maven
artifacts is [1] and that assumes and requires using org.apache.
as prefix for the GroupId:
"Maven Group Ids: a list of the groupIds for this project. They should
all be subgroups of org.apache"
All this may indeed only be a technical hurdle, agreed.
But given the ongoing discussions with respect to externally hosted
'binary' releases (like on dockerhub) and especially how these should be
controlled and marked (branded) by the ASF, it seemed advisable to me
to check with the Branding (aka Trademarks) Committee what the rules and
policy requirements are, if any, with respect to Maven GroupId.
Regards,
Ate
[1] http://www.apache.org/dev/publishing-maven-artifacts
LieGrue,
strub
Am 25.03.19 um 09:26 schrieb Bertrand Delacretaz:
Hi,
On Mon, Mar 25, 2019 at 8:48 AM Ate Douma <a...@douma.nu> wrote:
...Unless one of the other mentors has a different view or is aware
of more
explicit guidelines in this, I suggest raising these questions at
tradema...@apache.org instead....
+1 and I suggest backing that discussion with a
https://issues.apache.org/jira/browse/NETBEANS ticket so as to
document what'sm being done and the conclusions.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
