You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jean-Luc Deprez <Je...@gmail.com> on 2022/11/06 10:46:27 UTC

RE: Re: package names (pekko related)

Hi,

So this discussion is currently revived on Pekko dev. But it's seems the
cards are held by IPMC.

So a very concrete question.

Would someone here vote -1, for a Pekko release or Pekko graduation, for
the sole reason of the package name being 'pekko.*' instead of
org.apache.pekko.* ?

Noting that the Maven group/org ID would just be: org.apache.pekko

If more than 2 IPMC members say yes, I think we can state it's off the
table.


On 2022/10/12 15:58:51 sebb wrote:
> On Wed, 12 Oct 2022 at 16:46, John D. Ament <jo...@apache.org> wrote:
> >
> > 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.
>
> There are good reasons for this.
> The ASF 'owns' the org.apache prefix, and can therefore ensure
> uniqueness of names within that.
>
> Who owns pekko? What's to stop two different projects using
pekko.somename?
>
> Furthermore, if there is any code already using pekko.*, we should not
> release code that uses the same prefix.
>
> >  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
> > <ma...@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.dedetrich@aiven.io
> > > On 11. Oct 2022, 07:37 -0500, tison <wa...@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...@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 <fa...@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-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail:
general-help@incubator.apache.org
> > > > > >
> > > > >
> > > > >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: package names (pekko related)

Posted by Dave Fisher <wa...@comcast.net>.

Sent from my iPhone

> On Nov 6, 2022, at 2:24 PM, Jean-Luc Deprez <Je...@gmail.com> wrote:
> 
> Hi,
> 
> So this discussion is currently revived on Pekko dev. But it's seems the
> cards are held by IPMC.
> 
> So a very concrete question.
> 
> Would someone here vote -1, for a Pekko release or Pekko graduation, for
> the sole reason of the package name being 'pekko.*' instead of
> org.apache.pekko.* ?

While org.apache.pekko is preferred as sebb explained the pekko packaging would be reasonable only if the existing community already expects and has existing code that uses that packaging.

That’s not the case here is it?

Regards,
Dave
> 
> Noting that the Maven group/org ID would just be: org.apache.pekko
> 
> If more than 2 IPMC members say yes, I think we can state it's off the
> table.
> 
> 
>> On 2022/10/12 15:58:51 sebb wrote:
>>> On Wed, 12 Oct 2022 at 16:46, John D. Ament <jo...@apache.org> wrote:
>>> 
>>> 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.
>> 
>> There are good reasons for this.
>> The ASF 'owns' the org.apache prefix, and can therefore ensure
>> uniqueness of names within that.
>> 
>> Who owns pekko? What's to stop two different projects using
> pekko.somename?
>> 
>> Furthermore, if there is any code already using pekko.*, we should not
>> release code that uses the same prefix.
>> 
>>> 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
>>> <ma...@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.dedetrich@aiven.io
>>>> On 11. Oct 2022, 07:37 -0500, tison <wa...@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...@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 <fa...@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-unsubscribe@incubator.apache.org
>>>>>>> For additional commands, e-mail:
> general-help@incubator.apache.org
>>>>>>> 
>>>>>> 
>>>>>> 
> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> 
>>>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org