We should keep in mind that the trademarks requirements and the release
requirements are two different sets of requirements.  They're often
conflated.  The main thing to remember with trademarks and naming is that
the first time a project is referenced in documentation, websites, etc, it
must be referred to as "Apache <Foo>" and subsequent calls can just be
"<Foo>".  This would mean that README files in the source repo refer to the
project this way, descriptions on github repos etc are all named this way
as well.  Likewise, our release process indicates the source tarball for a
release is named "apache-<foo>...tar.gz" or similar.  The foundation has
always had a waving stance on binary releases, e.g. the JAR files you might
download from Maven Central.  The convention (not requirement) is that
those JAR files are packaged under "org.apache.<foo>".  Unless there's a
good reason not to, projects should follow this if they publish to maven.
By similar convention, we have applied this to the package names used by a
project.  The existing projects I was able to look at within the ASF all
used scala in a hybrid format with java code, meaning they had a mix of the
two and within a JAR file had both java and scala sourced files.  They're
not the best of examples as a result, but did all align to the
"org.apache.<foo>" naming convention.

there is no requirement to have your package name start with
org.apache.pekko, but by convention this is what is seen.  A source release
with source code starting with "pekko.*" would just as easily get a +1 to
release from me as "org.apache.pekko.*" as long as any documentation in the
source release said Apache Pekko (Incubating).

On Tue, Oct 11, 2022 at 2:37 PM Matthew Benedict de Detrich
<matthew.dedetr...@aiven.io.invalid> wrote:

> I can’t speak for maven but since Akka works with sbt its more likely to
> use sbt-assembly to perform any shading which handles cases like this (i.e.
> see https://github.com/sbt/sbt-assembly#merge-strategy and
> https://github.com/sbt/sbt-assembly#shading).
>
> --
> Matthew de Detrich
> Aiven Deutschland GmbH
> Immanuelkirchstraße 26, 10405 Berlin
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> m: +491603708037
> w: aiven.io e: matthew.dedetr...@aiven.io
> On 11. Oct 2022, 07:37 -0500, tison <wander4...@gmail.com>, wrote:
> > One point from the technical perspective:
> >
> > I remember that akka's config use akka. prefix and it causes several
> issues
> > prevent you shaded it. That is, Maven Shaded Plugin cannot distinguish a
> > string literal starts with akka. a config key or package name.
> >
> > From this perspective, if possible, I tend to use org.apache.pekko in
> > package name and use pekko. in the config name (or even akka? lol).
> >
> > Best,
> > tison.
> >
> >
> > Sheng Wu <wu.sheng.841...@gmail.com> 于2022年10月11日周二 20:22写道:
> >
> > > Hi
> > >
> > > I am not sure about Kafka and Netbeans cases, as I was not working
> > > inside the foundation back there.
> > > For the recent years' new podlings, `org.apache.*` is preferred by the
> > > incubator.
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > PJ Fanning <fannin...@apache.org> 于2022年10月11日周二 20:14写道:
> > > >
> > > > Hi everyone,
> > > >
> > > > I'm creating a new thread to avoid filling the Pekko thread with
> emails
> > > that are only partially related to the proposal.
> > > >
> > > > The current Akka code uses packages that start with 'akka.' and a
> lot of
> > > the people involved with Pekko seem to prefer to keep the use 'pekko.'
> > > instead of 'org.apache.pekko.' when we rename the Akka packages.
> > > >
> > > > Kafka and Netbeans are examples of Apache projects that don't use
> > > 'org.apache' prefix in their package names.
> > > >
> > > > Is 'pekko.' a viable option or is there a strong preference within
> the
> > > ASF and the Incubator PMC for 'org.apache.pekko.'?
> > > >
> > > > 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
> > >
> > >
>

Reply via email to