Hi Thanks a lot for the discussion. I'm not sure what I need to do. On the technical part as per https://issues.apache.org/jira/browse/INFRA-17127 the Nexus infrastructure allow to stage on the org.netbeans or org.apache.netbeans groupId. Seamless would be org.netbeans of course.
I would like to know how to present or handle the vote for a this staged items The content is on apache nexus like that https://repository.apache.org/content/repositories/orgapachenetbeans-1012 the build is based on source from a git tag equals to the voted Apache NetBeans (incubating) 10 and I sign the artefacts with my key. Is this enough for a vote ? (nothing more on dist.apache.org as source zip already done, not sha512 as nexus not support it) Not presuming graduation but let's say graduation is done but artefacts from incubator Apache NetBeans (incubating) 9 are not yet published. Is a PMC allowed to release by itself or should it be also IPMC as the artefacts they belong were done during incubating period. Best Regards Eric (Not very helpful but as it's a maven tools preparing the populating of the repository (not the signing phase), it is possible to run it twice to populate the both groupid) -----Message d'origine----- De : Ate Douma <a...@douma.nu> Envoyé : lundi 25 mars 2019 22:28 À : dev@netbeans.incubator.apache.org Objet : Re: [MENTORS] Apache NetBeans maven artifacts groupId and process 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~browsestorag > e 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 --------------------------------------------------------------------- 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
