You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Vova Vysotskyi <vv...@gmail.com> on 2018/09/12 15:33:21 UTC
Publish Drill Calcite project artifacts to Apache maven repository
Hi all,
As you know, Drill uses its fork of Apache Calcite.
In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
proposed to deploy Drill Calcite project artifacts
to Apache Maven repository or at least to the central maven repository.
I have looked for the similar cases of fork versions and didn't find
anything similar in the central repo.
Also, I have looked at the Sonatype OSSRH Jiras for similar cases
of deploying fork versions, but that projects used custom groupIds.
Could someone please give me the advice what is the acceptable way
of publishing the custom Drill Calcite artifacts to the central repo and
is it possible to publish them without changing groupId?
Kind regards,
Volodymyr Vysotskyi
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Don’t worry, I didn’t feel accused. I know you Drill folks are in pain because you’re on a fork. I was empathizing with your pain. And I know that when a block a PR it causes the pain to continue.
> On Sep 13, 2018, at 2:12 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> I didn't aim to accuse anyone of the fact that those Jiras weren't accepted
> in my previous letter, sorry if it was interpreted in that way.
> I just explained why we still use fork.
>
> Regarding 'big messy changes that are of obvious benefit only to the
> contributor', at least CALCITE-2018
> <https://issues.apache.org/jira/browse/CALCITE-2018> is a problem that
> worries not only Drill.
> For example, recently was logged CALCITE-2538
> <https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Thu, Sep 13, 2018 at 3:25 AM Julian Hyde <jh...@apache.org> wrote:
>
>> Yes, this is a feature that could be enabled based on a SqlConformance
>> property.
>>
>> However we would also need to agree semantics (probably based on other
>> databases that have similar functionality), add tests, and make the
>> functions work in Calcite’s default function implementations.
>>
>> Julian
>>
>>> On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID>
>> wrote:
>>>
>>> For CALCITE-1178 and other loosing type check things, if the concern was
>> that it is not compliant with SQL standard, should this be a SQL flavor
>> defined in one of compliance? So Calcite users (e.g. Drill) can choose a
>> customized compliance to enable the implicit type conversion.
>>> ------------------------------------------------------------------
>>> Sender:Julian Hyde <jh...@apache.org>
>>> Sent at:2018 Sep 12 (Wed) 17:04
>>> To:dev <de...@calcite.apache.org>
>>> Cc:dev <de...@drill.apache.org>
>>> Subject:Re: Publish Drill Calcite project artifacts to Apache maven
>> repository
>>>
>>> Probably down to me. Although, in my defense, it is hard to be
>> gatekeeper for big messy changes that are of obvious benefit to the
>> contributor but not such obvious benefit to the rest of the project.
>>>
>>> Is there a PR for CALCITE-1178?
>>>
>>> Julian
>>>
>>>
>>>> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>>>>
>>>> Thanks for your responses and clarifications!
>>>>
>>>> Regarding the reasons for using the fork:
>>>> We would love to move to the Apache Calcite instead of using the fork!
>>>>
>>>> And we tried very hard to do it, especially during the rebase from 1.4
>> to
>>>> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
>>>> But unfortunately, there left three Jiras, which weren't accepted by the
>>>> Calcite community yet:
>>>> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
>>>> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
>>>> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>>>>
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>>>
>>>>
>>>> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>>>>
>>>>> I can confirm what Josh says about OSSRH. You need to fill out a form
>> with
>>>>> Sonatype that convinces them that you own the groupId (basically a
>> domain
>>>>> name). Then they give you authorization to publish artifacts under that
>>>>> groupId. For example, I publish artifacts under the sqlline and
>>>>> net.hydromatic groupIds.
>>>>>
>>>>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>>>>
>>>>>> Maven central is made up of a number of "Trusted" Maven repositories.
>>>>> This includes the ASF and OSSRH Maven repositories. Many other
>>>>> organizations run "mirrors" of central.
>>>>>>
>>>>>> The ASF Maven repo is published to by ASF projects who have gone
>> through
>>>>> the ASF release process. OSSRH allows any release which meets the
>> criteria
>>>>> described here[1]. As an individual, you are within your rights to
>> publish
>>>>> your fork of Calcite to OSSRH as long as there are no legal or
>> trademark
>>>>> concerns. It would be imperative to not cause confusion with official
>>>>> Apache Calcite releases -- clear branding and separate Maven
>>>>> groupId/artifactId "coordinates" should be sufficient.
>>>>>>
>>>>>> However, since you are (presumably) acting as a member of Apache
>> Drill,
>>>>> it would be very odd (and potentially against ASF policy) to make a
>> release
>>>>> of software that *isn't* using the ASF Maven resources. This gives me
>> some
>>>>> pause -- do you have an ASF member on your PMC you can run this by?
>>>>>>
>>>>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>>>>> needs to maintain this fork, and see if there is something that can be
>> done
>>>>> from the Calcite side to get you "back on upstream"? Why the need to
>> make
>>>>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>>>>
>>>>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>>>>
>>>>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>>>>> Hi all,
>>>>>>> As you know, Drill uses its fork of Apache Calcite.
>>>>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>>>>> proposed to deploy Drill Calcite project artifacts
>>>>>>> to Apache Maven repository or at least to the central maven
>> repository.
>>>>>>> I have looked for the similar cases of fork versions and didn't find
>>>>>>> anything similar in the central repo.
>>>>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>>>>> of deploying fork versions, but that projects used custom groupIds.
>>>>>>> Could someone please give me the advice what is the acceptable way
>>>>>>> of publishing the custom Drill Calcite artifacts to the central repo
>> and
>>>>>>> is it possible to publish them without changing groupId?
>>>>>>> Kind regards,
>>>>>>> Volodymyr Vysotskyi
>>>>>
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Don’t worry, I didn’t feel accused. I know you Drill folks are in pain because you’re on a fork. I was empathizing with your pain. And I know that when a block a PR it causes the pain to continue.
> On Sep 13, 2018, at 2:12 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> I didn't aim to accuse anyone of the fact that those Jiras weren't accepted
> in my previous letter, sorry if it was interpreted in that way.
> I just explained why we still use fork.
>
> Regarding 'big messy changes that are of obvious benefit only to the
> contributor', at least CALCITE-2018
> <https://issues.apache.org/jira/browse/CALCITE-2018> is a problem that
> worries not only Drill.
> For example, recently was logged CALCITE-2538
> <https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Thu, Sep 13, 2018 at 3:25 AM Julian Hyde <jh...@apache.org> wrote:
>
>> Yes, this is a feature that could be enabled based on a SqlConformance
>> property.
>>
>> However we would also need to agree semantics (probably based on other
>> databases that have similar functionality), add tests, and make the
>> functions work in Calcite’s default function implementations.
>>
>> Julian
>>
>>> On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID>
>> wrote:
>>>
>>> For CALCITE-1178 and other loosing type check things, if the concern was
>> that it is not compliant with SQL standard, should this be a SQL flavor
>> defined in one of compliance? So Calcite users (e.g. Drill) can choose a
>> customized compliance to enable the implicit type conversion.
>>> ------------------------------------------------------------------
>>> Sender:Julian Hyde <jh...@apache.org>
>>> Sent at:2018 Sep 12 (Wed) 17:04
>>> To:dev <de...@calcite.apache.org>
>>> Cc:dev <de...@drill.apache.org>
>>> Subject:Re: Publish Drill Calcite project artifacts to Apache maven
>> repository
>>>
>>> Probably down to me. Although, in my defense, it is hard to be
>> gatekeeper for big messy changes that are of obvious benefit to the
>> contributor but not such obvious benefit to the rest of the project.
>>>
>>> Is there a PR for CALCITE-1178?
>>>
>>> Julian
>>>
>>>
>>>> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>>>>
>>>> Thanks for your responses and clarifications!
>>>>
>>>> Regarding the reasons for using the fork:
>>>> We would love to move to the Apache Calcite instead of using the fork!
>>>>
>>>> And we tried very hard to do it, especially during the rebase from 1.4
>> to
>>>> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
>>>> But unfortunately, there left three Jiras, which weren't accepted by the
>>>> Calcite community yet:
>>>> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
>>>> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
>>>> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>>>>
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>>>
>>>>
>>>> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>>>>
>>>>> I can confirm what Josh says about OSSRH. You need to fill out a form
>> with
>>>>> Sonatype that convinces them that you own the groupId (basically a
>> domain
>>>>> name). Then they give you authorization to publish artifacts under that
>>>>> groupId. For example, I publish artifacts under the sqlline and
>>>>> net.hydromatic groupIds.
>>>>>
>>>>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>>>>
>>>>>> Maven central is made up of a number of "Trusted" Maven repositories.
>>>>> This includes the ASF and OSSRH Maven repositories. Many other
>>>>> organizations run "mirrors" of central.
>>>>>>
>>>>>> The ASF Maven repo is published to by ASF projects who have gone
>> through
>>>>> the ASF release process. OSSRH allows any release which meets the
>> criteria
>>>>> described here[1]. As an individual, you are within your rights to
>> publish
>>>>> your fork of Calcite to OSSRH as long as there are no legal or
>> trademark
>>>>> concerns. It would be imperative to not cause confusion with official
>>>>> Apache Calcite releases -- clear branding and separate Maven
>>>>> groupId/artifactId "coordinates" should be sufficient.
>>>>>>
>>>>>> However, since you are (presumably) acting as a member of Apache
>> Drill,
>>>>> it would be very odd (and potentially against ASF policy) to make a
>> release
>>>>> of software that *isn't* using the ASF Maven resources. This gives me
>> some
>>>>> pause -- do you have an ASF member on your PMC you can run this by?
>>>>>>
>>>>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>>>>> needs to maintain this fork, and see if there is something that can be
>> done
>>>>> from the Calcite side to get you "back on upstream"? Why the need to
>> make
>>>>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>>>>
>>>>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>>>>
>>>>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>>>>> Hi all,
>>>>>>> As you know, Drill uses its fork of Apache Calcite.
>>>>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>>>>> proposed to deploy Drill Calcite project artifacts
>>>>>>> to Apache Maven repository or at least to the central maven
>> repository.
>>>>>>> I have looked for the similar cases of fork versions and didn't find
>>>>>>> anything similar in the central repo.
>>>>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>>>>> of deploying fork versions, but that projects used custom groupIds.
>>>>>>> Could someone please give me the advice what is the acceptable way
>>>>>>> of publishing the custom Drill Calcite artifacts to the central repo
>> and
>>>>>>> is it possible to publish them without changing groupId?
>>>>>>> Kind regards,
>>>>>>> Volodymyr Vysotskyi
>>>>>
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Vova Vysotskyi <vv...@gmail.com>.
I didn't aim to accuse anyone of the fact that those Jiras weren't accepted
in my previous letter, sorry if it was interpreted in that way.
I just explained why we still use fork.
Regarding 'big messy changes that are of obvious benefit only to the
contributor', at least CALCITE-2018
<https://issues.apache.org/jira/browse/CALCITE-2018> is a problem that
worries not only Drill.
For example, recently was logged CALCITE-2538
<https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug.
Kind regards,
Volodymyr Vysotskyi
On Thu, Sep 13, 2018 at 3:25 AM Julian Hyde <jh...@apache.org> wrote:
> Yes, this is a feature that could be enabled based on a SqlConformance
> property.
>
> However we would also need to agree semantics (probably based on other
> databases that have similar functionality), add tests, and make the
> functions work in Calcite’s default function implementations.
>
> Julian
>
> > On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID>
> wrote:
> >
> > For CALCITE-1178 and other loosing type check things, if the concern was
> that it is not compliant with SQL standard, should this be a SQL flavor
> defined in one of compliance? So Calcite users (e.g. Drill) can choose a
> customized compliance to enable the implicit type conversion.
> > ------------------------------------------------------------------
> > Sender:Julian Hyde <jh...@apache.org>
> > Sent at:2018 Sep 12 (Wed) 17:04
> > To:dev <de...@calcite.apache.org>
> > Cc:dev <de...@drill.apache.org>
> > Subject:Re: Publish Drill Calcite project artifacts to Apache maven
> repository
> >
> > Probably down to me. Although, in my defense, it is hard to be
> gatekeeper for big messy changes that are of obvious benefit to the
> contributor but not such obvious benefit to the rest of the project.
> >
> > Is there a PR for CALCITE-1178?
> >
> > Julian
> >
> >
> >> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
> >>
> >> Thanks for your responses and clarifications!
> >>
> >> Regarding the reasons for using the fork:
> >> We would love to move to the Apache Calcite instead of using the fork!
> >>
> >> And we tried very hard to do it, especially during the rebase from 1.4
> to
> >> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> >> But unfortunately, there left three Jiras, which weren't accepted by the
> >> Calcite community yet:
> >> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> >> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> >> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
> >>
> >> Kind regards,
> >> Volodymyr Vysotskyi
> >>
> >>
> >> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
> >>
> >>> I can confirm what Josh says about OSSRH. You need to fill out a form
> with
> >>> Sonatype that convinces them that you own the groupId (basically a
> domain
> >>> name). Then they give you authorization to publish artifacts under that
> >>> groupId. For example, I publish artifacts under the sqlline and
> >>> net.hydromatic groupIds.
> >>>
> >>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
> >>>>
> >>>> Maven central is made up of a number of "Trusted" Maven repositories.
> >>> This includes the ASF and OSSRH Maven repositories. Many other
> >>> organizations run "mirrors" of central.
> >>>>
> >>>> The ASF Maven repo is published to by ASF projects who have gone
> through
> >>> the ASF release process. OSSRH allows any release which meets the
> criteria
> >>> described here[1]. As an individual, you are within your rights to
> publish
> >>> your fork of Calcite to OSSRH as long as there are no legal or
> trademark
> >>> concerns. It would be imperative to not cause confusion with official
> >>> Apache Calcite releases -- clear branding and separate Maven
> >>> groupId/artifactId "coordinates" should be sufficient.
> >>>>
> >>>> However, since you are (presumably) acting as a member of Apache
> Drill,
> >>> it would be very odd (and potentially against ASF policy) to make a
> release
> >>> of software that *isn't* using the ASF Maven resources. This gives me
> some
> >>> pause -- do you have an ASF member on your PMC you can run this by?
> >>>>
> >>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
> >>> needs to maintain this fork, and see if there is something that can be
> done
> >>> from the Calcite side to get you "back on upstream"? Why the need to
> make
> >>> long-term plans to isolate Apache Drill from Apache Calcite?
> >>>>
> >>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
> >>>>
> >>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> >>>>> Hi all,
> >>>>> As you know, Drill uses its fork of Apache Calcite.
> >>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> >>>>> proposed to deploy Drill Calcite project artifacts
> >>>>> to Apache Maven repository or at least to the central maven
> repository.
> >>>>> I have looked for the similar cases of fork versions and didn't find
> >>>>> anything similar in the central repo.
> >>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> >>>>> of deploying fork versions, but that projects used custom groupIds.
> >>>>> Could someone please give me the advice what is the acceptable way
> >>>>> of publishing the custom Drill Calcite artifacts to the central repo
> and
> >>>>> is it possible to publish them without changing groupId?
> >>>>> Kind regards,
> >>>>> Volodymyr Vysotskyi
> >>>
>
>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Vova Vysotskyi <vv...@gmail.com>.
I didn't aim to accuse anyone of the fact that those Jiras weren't accepted
in my previous letter, sorry if it was interpreted in that way.
I just explained why we still use fork.
Regarding 'big messy changes that are of obvious benefit only to the
contributor', at least CALCITE-2018
<https://issues.apache.org/jira/browse/CALCITE-2018> is a problem that
worries not only Drill.
For example, recently was logged CALCITE-2538
<https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug.
Kind regards,
Volodymyr Vysotskyi
On Thu, Sep 13, 2018 at 3:25 AM Julian Hyde <jh...@apache.org> wrote:
> Yes, this is a feature that could be enabled based on a SqlConformance
> property.
>
> However we would also need to agree semantics (probably based on other
> databases that have similar functionality), add tests, and make the
> functions work in Calcite’s default function implementations.
>
> Julian
>
> > On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID>
> wrote:
> >
> > For CALCITE-1178 and other loosing type check things, if the concern was
> that it is not compliant with SQL standard, should this be a SQL flavor
> defined in one of compliance? So Calcite users (e.g. Drill) can choose a
> customized compliance to enable the implicit type conversion.
> > ------------------------------------------------------------------
> > Sender:Julian Hyde <jh...@apache.org>
> > Sent at:2018 Sep 12 (Wed) 17:04
> > To:dev <de...@calcite.apache.org>
> > Cc:dev <de...@drill.apache.org>
> > Subject:Re: Publish Drill Calcite project artifacts to Apache maven
> repository
> >
> > Probably down to me. Although, in my defense, it is hard to be
> gatekeeper for big messy changes that are of obvious benefit to the
> contributor but not such obvious benefit to the rest of the project.
> >
> > Is there a PR for CALCITE-1178?
> >
> > Julian
> >
> >
> >> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
> >>
> >> Thanks for your responses and clarifications!
> >>
> >> Regarding the reasons for using the fork:
> >> We would love to move to the Apache Calcite instead of using the fork!
> >>
> >> And we tried very hard to do it, especially during the rebase from 1.4
> to
> >> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> >> But unfortunately, there left three Jiras, which weren't accepted by the
> >> Calcite community yet:
> >> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> >> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> >> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
> >>
> >> Kind regards,
> >> Volodymyr Vysotskyi
> >>
> >>
> >> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
> >>
> >>> I can confirm what Josh says about OSSRH. You need to fill out a form
> with
> >>> Sonatype that convinces them that you own the groupId (basically a
> domain
> >>> name). Then they give you authorization to publish artifacts under that
> >>> groupId. For example, I publish artifacts under the sqlline and
> >>> net.hydromatic groupIds.
> >>>
> >>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
> >>>>
> >>>> Maven central is made up of a number of "Trusted" Maven repositories.
> >>> This includes the ASF and OSSRH Maven repositories. Many other
> >>> organizations run "mirrors" of central.
> >>>>
> >>>> The ASF Maven repo is published to by ASF projects who have gone
> through
> >>> the ASF release process. OSSRH allows any release which meets the
> criteria
> >>> described here[1]. As an individual, you are within your rights to
> publish
> >>> your fork of Calcite to OSSRH as long as there are no legal or
> trademark
> >>> concerns. It would be imperative to not cause confusion with official
> >>> Apache Calcite releases -- clear branding and separate Maven
> >>> groupId/artifactId "coordinates" should be sufficient.
> >>>>
> >>>> However, since you are (presumably) acting as a member of Apache
> Drill,
> >>> it would be very odd (and potentially against ASF policy) to make a
> release
> >>> of software that *isn't* using the ASF Maven resources. This gives me
> some
> >>> pause -- do you have an ASF member on your PMC you can run this by?
> >>>>
> >>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
> >>> needs to maintain this fork, and see if there is something that can be
> done
> >>> from the Calcite side to get you "back on upstream"? Why the need to
> make
> >>> long-term plans to isolate Apache Drill from Apache Calcite?
> >>>>
> >>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
> >>>>
> >>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> >>>>> Hi all,
> >>>>> As you know, Drill uses its fork of Apache Calcite.
> >>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> >>>>> proposed to deploy Drill Calcite project artifacts
> >>>>> to Apache Maven repository or at least to the central maven
> repository.
> >>>>> I have looked for the similar cases of fork versions and didn't find
> >>>>> anything similar in the central repo.
> >>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> >>>>> of deploying fork versions, but that projects used custom groupIds.
> >>>>> Could someone please give me the advice what is the acceptable way
> >>>>> of publishing the custom Drill Calcite artifacts to the central repo
> and
> >>>>> is it possible to publish them without changing groupId?
> >>>>> Kind regards,
> >>>>> Volodymyr Vysotskyi
> >>>
>
>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Yes, this is a feature that could be enabled based on a SqlConformance property.
However we would also need to agree semantics (probably based on other databases that have similar functionality), add tests, and make the functions work in Calcite’s default function implementations.
Julian
> On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID> wrote:
>
> For CALCITE-1178 and other loosing type check things, if the concern was that it is not compliant with SQL standard, should this be a SQL flavor defined in one of compliance? So Calcite users (e.g. Drill) can choose a customized compliance to enable the implicit type conversion.
> ------------------------------------------------------------------
> Sender:Julian Hyde <jh...@apache.org>
> Sent at:2018 Sep 12 (Wed) 17:04
> To:dev <de...@calcite.apache.org>
> Cc:dev <de...@drill.apache.org>
> Subject:Re: Publish Drill Calcite project artifacts to Apache maven repository
>
> Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
>
> Is there a PR for CALCITE-1178?
>
> Julian
>
>
>> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>>
>> Thanks for your responses and clarifications!
>>
>> Regarding the reasons for using the fork:
>> We would love to move to the Apache Calcite instead of using the fork!
>>
>> And we tried very hard to do it, especially during the rebase from 1.4 to
>> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
>> But unfortunately, there left three Jiras, which weren't accepted by the
>> Calcite community yet:
>> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
>> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
>> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>>
>> Kind regards,
>> Volodymyr Vysotskyi
>>
>>
>> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>>
>>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>>> Sonatype that convinces them that you own the groupId (basically a domain
>>> name). Then they give you authorization to publish artifacts under that
>>> groupId. For example, I publish artifacts under the sqlline and
>>> net.hydromatic groupIds.
>>>
>>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>>
>>>> Maven central is made up of a number of "Trusted" Maven repositories.
>>> This includes the ASF and OSSRH Maven repositories. Many other
>>> organizations run "mirrors" of central.
>>>>
>>>> The ASF Maven repo is published to by ASF projects who have gone through
>>> the ASF release process. OSSRH allows any release which meets the criteria
>>> described here[1]. As an individual, you are within your rights to publish
>>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>>> concerns. It would be imperative to not cause confusion with official
>>> Apache Calcite releases -- clear branding and separate Maven
>>> groupId/artifactId "coordinates" should be sufficient.
>>>>
>>>> However, since you are (presumably) acting as a member of Apache Drill,
>>> it would be very odd (and potentially against ASF policy) to make a release
>>> of software that *isn't* using the ASF Maven resources. This gives me some
>>> pause -- do you have an ASF member on your PMC you can run this by?
>>>>
>>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>>> needs to maintain this fork, and see if there is something that can be done
>>> from the Calcite side to get you "back on upstream"? Why the need to make
>>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>>
>>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>>
>>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>>> Hi all,
>>>>> As you know, Drill uses its fork of Apache Calcite.
>>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>>> proposed to deploy Drill Calcite project artifacts
>>>>> to Apache Maven repository or at least to the central maven repository.
>>>>> I have looked for the similar cases of fork versions and didn't find
>>>>> anything similar in the central repo.
>>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>>> of deploying fork versions, but that projects used custom groupIds.
>>>>> Could someone please give me the advice what is the acceptable way
>>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>>> is it possible to publish them without changing groupId?
>>>>> Kind regards,
>>>>> Volodymyr Vysotskyi
>>>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Yes, this is a feature that could be enabled based on a SqlConformance property.
However we would also need to agree semantics (probably based on other databases that have similar functionality), add tests, and make the functions work in Calcite’s default function implementations.
Julian
> On Sep 12, 2018, at 5:18 PM, Chunhui Shi <sh...@aliyun.com.INVALID> wrote:
>
> For CALCITE-1178 and other loosing type check things, if the concern was that it is not compliant with SQL standard, should this be a SQL flavor defined in one of compliance? So Calcite users (e.g. Drill) can choose a customized compliance to enable the implicit type conversion.
> ------------------------------------------------------------------
> Sender:Julian Hyde <jh...@apache.org>
> Sent at:2018 Sep 12 (Wed) 17:04
> To:dev <de...@calcite.apache.org>
> Cc:dev <de...@drill.apache.org>
> Subject:Re: Publish Drill Calcite project artifacts to Apache maven repository
>
> Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
>
> Is there a PR for CALCITE-1178?
>
> Julian
>
>
>> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>>
>> Thanks for your responses and clarifications!
>>
>> Regarding the reasons for using the fork:
>> We would love to move to the Apache Calcite instead of using the fork!
>>
>> And we tried very hard to do it, especially during the rebase from 1.4 to
>> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
>> But unfortunately, there left three Jiras, which weren't accepted by the
>> Calcite community yet:
>> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
>> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
>> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>>
>> Kind regards,
>> Volodymyr Vysotskyi
>>
>>
>> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>>
>>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>>> Sonatype that convinces them that you own the groupId (basically a domain
>>> name). Then they give you authorization to publish artifacts under that
>>> groupId. For example, I publish artifacts under the sqlline and
>>> net.hydromatic groupIds.
>>>
>>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>>
>>>> Maven central is made up of a number of "Trusted" Maven repositories.
>>> This includes the ASF and OSSRH Maven repositories. Many other
>>> organizations run "mirrors" of central.
>>>>
>>>> The ASF Maven repo is published to by ASF projects who have gone through
>>> the ASF release process. OSSRH allows any release which meets the criteria
>>> described here[1]. As an individual, you are within your rights to publish
>>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>>> concerns. It would be imperative to not cause confusion with official
>>> Apache Calcite releases -- clear branding and separate Maven
>>> groupId/artifactId "coordinates" should be sufficient.
>>>>
>>>> However, since you are (presumably) acting as a member of Apache Drill,
>>> it would be very odd (and potentially against ASF policy) to make a release
>>> of software that *isn't* using the ASF Maven resources. This gives me some
>>> pause -- do you have an ASF member on your PMC you can run this by?
>>>>
>>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>>> needs to maintain this fork, and see if there is something that can be done
>>> from the Calcite side to get you "back on upstream"? Why the need to make
>>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>>
>>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>>
>>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>>> Hi all,
>>>>> As you know, Drill uses its fork of Apache Calcite.
>>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>>> proposed to deploy Drill Calcite project artifacts
>>>>> to Apache Maven repository or at least to the central maven repository.
>>>>> I have looked for the similar cases of fork versions and didn't find
>>>>> anything similar in the central repo.
>>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>>> of deploying fork versions, but that projects used custom groupIds.
>>>>> Could someone please give me the advice what is the acceptable way
>>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>>> is it possible to publish them without changing groupId?
>>>>> Kind regards,
>>>>> Volodymyr Vysotskyi
>>>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Chunhui Shi <sh...@aliyun.com.INVALID>.
For CALCITE-1178 and other loosing type check things, if the concern was that it is not compliant with SQL standard, should this be a SQL flavor defined in one of compliance? So Calcite users (e.g. Drill) can choose a customized compliance to enable the implicit type conversion.
------------------------------------------------------------------
Sender:Julian Hyde <jh...@apache.org>
Sent at:2018 Sep 12 (Wed) 17:04
To:dev <de...@calcite.apache.org>
Cc:dev <de...@drill.apache.org>
Subject:Re: Publish Drill Calcite project artifacts to Apache maven repository
Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
Is there a PR for CALCITE-1178?
Julian
> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> Thanks for your responses and clarifications!
>
> Regarding the reasons for using the fork:
> We would love to move to the Apache Calcite instead of using the fork!
>
> And we tried very hard to do it, especially during the rebase from 1.4 to
> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> But unfortunately, there left three Jiras, which weren't accepted by the
> Calcite community yet:
> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>
>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>> Sonatype that convinces them that you own the groupId (basically a domain
>> name). Then they give you authorization to publish artifacts under that
>> groupId. For example, I publish artifacts under the sqlline and
>> net.hydromatic groupIds.
>>
>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>
>>> Maven central is made up of a number of "Trusted" Maven repositories.
>> This includes the ASF and OSSRH Maven repositories. Many other
>> organizations run "mirrors" of central.
>>>
>>> The ASF Maven repo is published to by ASF projects who have gone through
>> the ASF release process. OSSRH allows any release which meets the criteria
>> described here[1]. As an individual, you are within your rights to publish
>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>> concerns. It would be imperative to not cause confusion with official
>> Apache Calcite releases -- clear branding and separate Maven
>> groupId/artifactId "coordinates" should be sufficient.
>>>
>>> However, since you are (presumably) acting as a member of Apache Drill,
>> it would be very odd (and potentially against ASF policy) to make a release
>> of software that *isn't* using the ASF Maven resources. This gives me some
>> pause -- do you have an ASF member on your PMC you can run this by?
>>>
>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>> needs to maintain this fork, and see if there is something that can be done
>> from the Calcite side to get you "back on upstream"? Why the need to make
>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>
>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>
>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>> Hi all,
>>>> As you know, Drill uses its fork of Apache Calcite.
>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>> proposed to deploy Drill Calcite project artifacts
>>>> to Apache Maven repository or at least to the central maven repository.
>>>> I have looked for the similar cases of fork versions and didn't find
>>>> anything similar in the central repo.
>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>> of deploying fork versions, but that projects used custom groupIds.
>>>> Could someone please give me the advice what is the acceptable way
>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>> is it possible to publish them without changing groupId?
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Chunhui Shi <sh...@aliyun.com.INVALID>.
For CALCITE-1178 and other loosing type check things, if the concern was that it is not compliant with SQL standard, should this be a SQL flavor defined in one of compliance? So Calcite users (e.g. Drill) can choose a customized compliance to enable the implicit type conversion.
------------------------------------------------------------------
Sender:Julian Hyde <jh...@apache.org>
Sent at:2018 Sep 12 (Wed) 17:04
To:dev <de...@calcite.apache.org>
Cc:dev <de...@drill.apache.org>
Subject:Re: Publish Drill Calcite project artifacts to Apache maven repository
Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
Is there a PR for CALCITE-1178?
Julian
> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> Thanks for your responses and clarifications!
>
> Regarding the reasons for using the fork:
> We would love to move to the Apache Calcite instead of using the fork!
>
> And we tried very hard to do it, especially during the rebase from 1.4 to
> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> But unfortunately, there left three Jiras, which weren't accepted by the
> Calcite community yet:
> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>
>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>> Sonatype that convinces them that you own the groupId (basically a domain
>> name). Then they give you authorization to publish artifacts under that
>> groupId. For example, I publish artifacts under the sqlline and
>> net.hydromatic groupIds.
>>
>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>
>>> Maven central is made up of a number of "Trusted" Maven repositories.
>> This includes the ASF and OSSRH Maven repositories. Many other
>> organizations run "mirrors" of central.
>>>
>>> The ASF Maven repo is published to by ASF projects who have gone through
>> the ASF release process. OSSRH allows any release which meets the criteria
>> described here[1]. As an individual, you are within your rights to publish
>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>> concerns. It would be imperative to not cause confusion with official
>> Apache Calcite releases -- clear branding and separate Maven
>> groupId/artifactId "coordinates" should be sufficient.
>>>
>>> However, since you are (presumably) acting as a member of Apache Drill,
>> it would be very odd (and potentially against ASF policy) to make a release
>> of software that *isn't* using the ASF Maven resources. This gives me some
>> pause -- do you have an ASF member on your PMC you can run this by?
>>>
>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>> needs to maintain this fork, and see if there is something that can be done
>> from the Calcite side to get you "back on upstream"? Why the need to make
>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>
>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>
>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>> Hi all,
>>>> As you know, Drill uses its fork of Apache Calcite.
>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>> proposed to deploy Drill Calcite project artifacts
>>>> to Apache Maven repository or at least to the central maven repository.
>>>> I have looked for the similar cases of fork versions and didn't find
>>>> anything similar in the central repo.
>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>> of deploying fork versions, but that projects used custom groupIds.
>>>> Could someone please give me the advice what is the acceptable way
>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>> is it possible to publish them without changing groupId?
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
Is there a PR for CALCITE-1178?
Julian
> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> Thanks for your responses and clarifications!
>
> Regarding the reasons for using the fork:
> We would love to move to the Apache Calcite instead of using the fork!
>
> And we tried very hard to do it, especially during the rebase from 1.4 to
> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> But unfortunately, there left three Jiras, which weren't accepted by the
> Calcite community yet:
> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>
>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>> Sonatype that convinces them that you own the groupId (basically a domain
>> name). Then they give you authorization to publish artifacts under that
>> groupId. For example, I publish artifacts under the sqlline and
>> net.hydromatic groupIds.
>>
>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>
>>> Maven central is made up of a number of "Trusted" Maven repositories.
>> This includes the ASF and OSSRH Maven repositories. Many other
>> organizations run "mirrors" of central.
>>>
>>> The ASF Maven repo is published to by ASF projects who have gone through
>> the ASF release process. OSSRH allows any release which meets the criteria
>> described here[1]. As an individual, you are within your rights to publish
>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>> concerns. It would be imperative to not cause confusion with official
>> Apache Calcite releases -- clear branding and separate Maven
>> groupId/artifactId "coordinates" should be sufficient.
>>>
>>> However, since you are (presumably) acting as a member of Apache Drill,
>> it would be very odd (and potentially against ASF policy) to make a release
>> of software that *isn't* using the ASF Maven resources. This gives me some
>> pause -- do you have an ASF member on your PMC you can run this by?
>>>
>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>> needs to maintain this fork, and see if there is something that can be done
>> from the Calcite side to get you "back on upstream"? Why the need to make
>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>
>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>
>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>> Hi all,
>>>> As you know, Drill uses its fork of Apache Calcite.
>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>> proposed to deploy Drill Calcite project artifacts
>>>> to Apache Maven repository or at least to the central maven repository.
>>>> I have looked for the similar cases of fork versions and didn't find
>>>> anything similar in the central repo.
>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>> of deploying fork versions, but that projects used custom groupIds.
>>>> Could someone please give me the advice what is the acceptable way
>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>> is it possible to publish them without changing groupId?
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
Probably down to me. Although, in my defense, it is hard to be gatekeeper for big messy changes that are of obvious benefit to the contributor but not such obvious benefit to the rest of the project.
Is there a PR for CALCITE-1178?
Julian
> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <vv...@gmail.com> wrote:
>
> Thanks for your responses and clarifications!
>
> Regarding the reasons for using the fork:
> We would love to move to the Apache Calcite instead of using the fork!
>
> And we tried very hard to do it, especially during the rebase from 1.4 to
> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
> But unfortunately, there left three Jiras, which weren't accepted by the
> Calcite community yet:
> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
>
> Kind regards,
> Volodymyr Vysotskyi
>
>
> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
>
>> I can confirm what Josh says about OSSRH. You need to fill out a form with
>> Sonatype that convinces them that you own the groupId (basically a domain
>> name). Then they give you authorization to publish artifacts under that
>> groupId. For example, I publish artifacts under the sqlline and
>> net.hydromatic groupIds.
>>
>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>>>
>>> Maven central is made up of a number of "Trusted" Maven repositories.
>> This includes the ASF and OSSRH Maven repositories. Many other
>> organizations run "mirrors" of central.
>>>
>>> The ASF Maven repo is published to by ASF projects who have gone through
>> the ASF release process. OSSRH allows any release which meets the criteria
>> described here[1]. As an individual, you are within your rights to publish
>> your fork of Calcite to OSSRH as long as there are no legal or trademark
>> concerns. It would be imperative to not cause confusion with official
>> Apache Calcite releases -- clear branding and separate Maven
>> groupId/artifactId "coordinates" should be sufficient.
>>>
>>> However, since you are (presumably) acting as a member of Apache Drill,
>> it would be very odd (and potentially against ASF policy) to make a release
>> of software that *isn't* using the ASF Maven resources. This gives me some
>> pause -- do you have an ASF member on your PMC you can run this by?
>>>
>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill
>> needs to maintain this fork, and see if there is something that can be done
>> from the Calcite side to get you "back on upstream"? Why the need to make
>> long-term plans to isolate Apache Drill from Apache Calcite?
>>>
>>> [1] https://central.sonatype.org/pages/ossrh-guide.html
>>>
>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>>>> Hi all,
>>>> As you know, Drill uses its fork of Apache Calcite.
>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>>>> proposed to deploy Drill Calcite project artifacts
>>>> to Apache Maven repository or at least to the central maven repository.
>>>> I have looked for the similar cases of fork versions and didn't find
>>>> anything similar in the central repo.
>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>>>> of deploying fork versions, but that projects used custom groupIds.
>>>> Could someone please give me the advice what is the acceptable way
>>>> of publishing the custom Drill Calcite artifacts to the central repo and
>>>> is it possible to publish them without changing groupId?
>>>> Kind regards,
>>>> Volodymyr Vysotskyi
>>
>>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Vova Vysotskyi <vv...@gmail.com>.
Thanks for your responses and clarifications!
Regarding the reasons for using the fork:
We would love to move to the Apache Calcite instead of using the fork!
And we tried very hard to do it, especially during the rebase from 1.4 to
1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
But unfortunately, there left three Jiras, which weren't accepted by the
Calcite community yet:
CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
Kind regards,
Volodymyr Vysotskyi
On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
> I can confirm what Josh says about OSSRH. You need to fill out a form with
> Sonatype that convinces them that you own the groupId (basically a domain
> name). Then they give you authorization to publish artifacts under that
> groupId. For example, I publish artifacts under the sqlline and
> net.hydromatic groupIds.
>
> > On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
> >
> > Maven central is made up of a number of "Trusted" Maven repositories.
> This includes the ASF and OSSRH Maven repositories. Many other
> organizations run "mirrors" of central.
> >
> > The ASF Maven repo is published to by ASF projects who have gone through
> the ASF release process. OSSRH allows any release which meets the criteria
> described here[1]. As an individual, you are within your rights to publish
> your fork of Calcite to OSSRH as long as there are no legal or trademark
> concerns. It would be imperative to not cause confusion with official
> Apache Calcite releases -- clear branding and separate Maven
> groupId/artifactId "coordinates" should be sufficient.
> >
> > However, since you are (presumably) acting as a member of Apache Drill,
> it would be very odd (and potentially against ASF policy) to make a release
> of software that *isn't* using the ASF Maven resources. This gives me some
> pause -- do you have an ASF member on your PMC you can run this by?
> >
> > Finally, as a Calcite PMC member, I feel obligated to ask why Drill
> needs to maintain this fork, and see if there is something that can be done
> from the Calcite side to get you "back on upstream"? Why the need to make
> long-term plans to isolate Apache Drill from Apache Calcite?
> >
> > [1] https://central.sonatype.org/pages/ossrh-guide.html
> >
> > On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> >> Hi all,
> >> As you know, Drill uses its fork of Apache Calcite.
> >> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> >> proposed to deploy Drill Calcite project artifacts
> >> to Apache Maven repository or at least to the central maven repository.
> >> I have looked for the similar cases of fork versions and didn't find
> >> anything similar in the central repo.
> >> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> >> of deploying fork versions, but that projects used custom groupIds.
> >> Could someone please give me the advice what is the acceptable way
> >> of publishing the custom Drill Calcite artifacts to the central repo and
> >> is it possible to publish them without changing groupId?
> >> Kind regards,
> >> Volodymyr Vysotskyi
>
>
Re: Publish Drill Calcite project artifacts to Apache maven repository
Posted by Vova Vysotskyi <vv...@gmail.com>.
Thanks for your responses and clarifications!
Regarding the reasons for using the fork:
We would love to move to the Apache Calcite instead of using the fork!
And we tried very hard to do it, especially during the rebase from 1.4 to
1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>).
But unfortunately, there left three Jiras, which weren't accepted by the
Calcite community yet:
CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>,
CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and
CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>.
Kind regards,
Volodymyr Vysotskyi
On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <jh...@apache.org> wrote:
> I can confirm what Josh says about OSSRH. You need to fill out a form with
> Sonatype that convinces them that you own the groupId (basically a domain
> name). Then they give you authorization to publish artifacts under that
> groupId. For example, I publish artifacts under the sqlline and
> net.hydromatic groupIds.
>
> > On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
> >
> > Maven central is made up of a number of "Trusted" Maven repositories.
> This includes the ASF and OSSRH Maven repositories. Many other
> organizations run "mirrors" of central.
> >
> > The ASF Maven repo is published to by ASF projects who have gone through
> the ASF release process. OSSRH allows any release which meets the criteria
> described here[1]. As an individual, you are within your rights to publish
> your fork of Calcite to OSSRH as long as there are no legal or trademark
> concerns. It would be imperative to not cause confusion with official
> Apache Calcite releases -- clear branding and separate Maven
> groupId/artifactId "coordinates" should be sufficient.
> >
> > However, since you are (presumably) acting as a member of Apache Drill,
> it would be very odd (and potentially against ASF policy) to make a release
> of software that *isn't* using the ASF Maven resources. This gives me some
> pause -- do you have an ASF member on your PMC you can run this by?
> >
> > Finally, as a Calcite PMC member, I feel obligated to ask why Drill
> needs to maintain this fork, and see if there is something that can be done
> from the Calcite side to get you "back on upstream"? Why the need to make
> long-term plans to isolate Apache Drill from Apache Calcite?
> >
> > [1] https://central.sonatype.org/pages/ossrh-guide.html
> >
> > On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> >> Hi all,
> >> As you know, Drill uses its fork of Apache Calcite.
> >> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> >> proposed to deploy Drill Calcite project artifacts
> >> to Apache Maven repository or at least to the central maven repository.
> >> I have looked for the similar cases of fork versions and didn't find
> >> anything similar in the central repo.
> >> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> >> of deploying fork versions, but that projects used custom groupIds.
> >> Could someone please give me the advice what is the acceptable way
> >> of publishing the custom Drill Calcite artifacts to the central repo and
> >> is it possible to publish them without changing groupId?
> >> Kind regards,
> >> Volodymyr Vysotskyi
>
>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
I can confirm what Josh says about OSSRH. You need to fill out a form with Sonatype that convinces them that you own the groupId (basically a domain name). Then they give you authorization to publish artifacts under that groupId. For example, I publish artifacts under the sqlline and net.hydromatic groupIds.
> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>
> Maven central is made up of a number of "Trusted" Maven repositories. This includes the ASF and OSSRH Maven repositories. Many other organizations run "mirrors" of central.
>
> The ASF Maven repo is published to by ASF projects who have gone through the ASF release process. OSSRH allows any release which meets the criteria described here[1]. As an individual, you are within your rights to publish your fork of Calcite to OSSRH as long as there are no legal or trademark concerns. It would be imperative to not cause confusion with official Apache Calcite releases -- clear branding and separate Maven groupId/artifactId "coordinates" should be sufficient.
>
> However, since you are (presumably) acting as a member of Apache Drill, it would be very odd (and potentially against ASF policy) to make a release of software that *isn't* using the ASF Maven resources. This gives me some pause -- do you have an ASF member on your PMC you can run this by?
>
> Finally, as a Calcite PMC member, I feel obligated to ask why Drill needs to maintain this fork, and see if there is something that can be done from the Calcite side to get you "back on upstream"? Why the need to make long-term plans to isolate Apache Drill from Apache Calcite?
>
> [1] https://central.sonatype.org/pages/ossrh-guide.html
>
> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>> Hi all,
>> As you know, Drill uses its fork of Apache Calcite.
>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>> proposed to deploy Drill Calcite project artifacts
>> to Apache Maven repository or at least to the central maven repository.
>> I have looked for the similar cases of fork versions and didn't find
>> anything similar in the central repo.
>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>> of deploying fork versions, but that projects used custom groupIds.
>> Could someone please give me the advice what is the acceptable way
>> of publishing the custom Drill Calcite artifacts to the central repo and
>> is it possible to publish them without changing groupId?
>> Kind regards,
>> Volodymyr Vysotskyi
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Julian Hyde <jh...@apache.org>.
I can confirm what Josh says about OSSRH. You need to fill out a form with Sonatype that convinces them that you own the groupId (basically a domain name). Then they give you authorization to publish artifacts under that groupId. For example, I publish artifacts under the sqlline and net.hydromatic groupIds.
> On Sep 12, 2018, at 9:28 AM, Josh Elser <el...@apache.org> wrote:
>
> Maven central is made up of a number of "Trusted" Maven repositories. This includes the ASF and OSSRH Maven repositories. Many other organizations run "mirrors" of central.
>
> The ASF Maven repo is published to by ASF projects who have gone through the ASF release process. OSSRH allows any release which meets the criteria described here[1]. As an individual, you are within your rights to publish your fork of Calcite to OSSRH as long as there are no legal or trademark concerns. It would be imperative to not cause confusion with official Apache Calcite releases -- clear branding and separate Maven groupId/artifactId "coordinates" should be sufficient.
>
> However, since you are (presumably) acting as a member of Apache Drill, it would be very odd (and potentially against ASF policy) to make a release of software that *isn't* using the ASF Maven resources. This gives me some pause -- do you have an ASF member on your PMC you can run this by?
>
> Finally, as a Calcite PMC member, I feel obligated to ask why Drill needs to maintain this fork, and see if there is something that can be done from the Calcite side to get you "back on upstream"? Why the need to make long-term plans to isolate Apache Drill from Apache Calcite?
>
> [1] https://central.sonatype.org/pages/ossrh-guide.html
>
> On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
>> Hi all,
>> As you know, Drill uses its fork of Apache Calcite.
>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
>> proposed to deploy Drill Calcite project artifacts
>> to Apache Maven repository or at least to the central maven repository.
>> I have looked for the similar cases of fork versions and didn't find
>> anything similar in the central repo.
>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
>> of deploying fork versions, but that projects used custom groupIds.
>> Could someone please give me the advice what is the acceptable way
>> of publishing the custom Drill Calcite artifacts to the central repo and
>> is it possible to publish them without changing groupId?
>> Kind regards,
>> Volodymyr Vysotskyi
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Josh Elser <el...@apache.org>.
Maven central is made up of a number of "Trusted" Maven repositories.
This includes the ASF and OSSRH Maven repositories. Many other
organizations run "mirrors" of central.
The ASF Maven repo is published to by ASF projects who have gone through
the ASF release process. OSSRH allows any release which meets the
criteria described here[1]. As an individual, you are within your rights
to publish your fork of Calcite to OSSRH as long as there are no legal
or trademark concerns. It would be imperative to not cause confusion
with official Apache Calcite releases -- clear branding and separate
Maven groupId/artifactId "coordinates" should be sufficient.
However, since you are (presumably) acting as a member of Apache Drill,
it would be very odd (and potentially against ASF policy) to make a
release of software that *isn't* using the ASF Maven resources. This
gives me some pause -- do you have an ASF member on your PMC you can run
this by?
Finally, as a Calcite PMC member, I feel obligated to ask why Drill
needs to maintain this fork, and see if there is something that can be
done from the Calcite side to get you "back on upstream"? Why the need
to make long-term plans to isolate Apache Drill from Apache Calcite?
[1] https://central.sonatype.org/pages/ossrh-guide.html
On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> Hi all,
>
> As you know, Drill uses its fork of Apache Calcite.
> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> proposed to deploy Drill Calcite project artifacts
> to Apache Maven repository or at least to the central maven repository.
> I have looked for the similar cases of fork versions and didn't find
> anything similar in the central repo.
>
> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> of deploying fork versions, but that projects used custom groupIds.
>
> Could someone please give me the advice what is the acceptable way
> of publishing the custom Drill Calcite artifacts to the central repo and
> is it possible to publish them without changing groupId?
>
> Kind regards,
> Volodymyr Vysotskyi
>
Re: Publish Drill Calcite project artifacts to Apache maven
repository
Posted by Josh Elser <el...@apache.org>.
Maven central is made up of a number of "Trusted" Maven repositories.
This includes the ASF and OSSRH Maven repositories. Many other
organizations run "mirrors" of central.
The ASF Maven repo is published to by ASF projects who have gone through
the ASF release process. OSSRH allows any release which meets the
criteria described here[1]. As an individual, you are within your rights
to publish your fork of Calcite to OSSRH as long as there are no legal
or trademark concerns. It would be imperative to not cause confusion
with official Apache Calcite releases -- clear branding and separate
Maven groupId/artifactId "coordinates" should be sufficient.
However, since you are (presumably) acting as a member of Apache Drill,
it would be very odd (and potentially against ASF policy) to make a
release of software that *isn't* using the ASF Maven resources. This
gives me some pause -- do you have an ASF member on your PMC you can run
this by?
Finally, as a Calcite PMC member, I feel obligated to ask why Drill
needs to maintain this fork, and see if there is something that can be
done from the Calcite side to get you "back on upstream"? Why the need
to make long-term plans to isolate Apache Drill from Apache Calcite?
[1] https://central.sonatype.org/pages/ossrh-guide.html
On 9/12/18 11:33 AM, Vova Vysotskyi wrote:
> Hi all,
>
> As you know, Drill uses its fork of Apache Calcite.
> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was
> proposed to deploy Drill Calcite project artifacts
> to Apache Maven repository or at least to the central maven repository.
> I have looked for the similar cases of fork versions and didn't find
> anything similar in the central repo.
>
> Also, I have looked at the Sonatype OSSRH Jiras for similar cases
> of deploying fork versions, but that projects used custom groupIds.
>
> Could someone please give me the advice what is the acceptable way
> of publishing the custom Drill Calcite artifacts to the central repo and
> is it possible to publish them without changing groupId?
>
> Kind regards,
> Volodymyr Vysotskyi
>