You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Francis Chuang <fr...@apache.org> on 2019/12/19 02:59:19 UTC
[DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Upon finalizing the release for Avatica 1.16.0, I noticed that the
dockerfiles would not build on docker hub. Upon investigation, it
appears that the file names of the jars on nexus has changed slightly.
The current dockerfiles [1] references
https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/${AVATICA_VERSION}/avatica-standalone-server-${AVATICA_VERSION}-shaded.jar
Where as on nexus, they are now called
avatica-standalone-server-${AVATICA_VERSION}.jar.
- Can anyone confirm if the
avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
avatica-standalone-server-${AVATICA_VERSION}.jar.
jars are suppose to be equivalent?
- Since the docker images for 1.16.0 cannot be built, I think we ought
to fix the dockerfiles and release a 1.17.0.
Francis
[1]
https://github.com/apache/calcite-avatica/tree/master/docker/src/main/dockerhub
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
In terms of the changes for this release, the dockerfiles has been fixed
and I believe you've reordered the steps for finalizing a release using
gradle.
I think the problem is somewhat annoying, but has not been an issue
before. If there is some consensus regarding this, I am happy to make
rc0 available for voting in the next couple of days.
On 8/01/2020 7:58 am, Vladimir Sitnikov wrote:
> AFAIK it is up to the release manager.
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
AFAIK it is up to the release manager.
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
Has there been any progress/solution regarding the LF and CRLF issue?
Francis
On 30/12/2019 2:43 am, Vladimir Sitnikov wrote:
> Stamitis>I was thinking that if the check says that there is no problem
> then apply
> would be a noop.
>
> The current logic of 'apply' is it computes the appropriate style and
> overwrites the file.
>
> Do you suggest it to skip overwriting in case the only diff is line endings?
> What if there are other changes?
> What if the lines have different style?
>
> I would refrain from making such changes to check/apply unless there's a
> justification.
>
> So far I do not care if the source build is broken for Windows, however, I
> do not like how LF vs CRLF issue is ignored.
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Stamitis>I was thinking that if the check says that there is no problem
then apply
would be a noop.
The current logic of 'apply' is it computes the appropriate style and
overwrites the file.
Do you suggest it to skip overwriting in case the only diff is line endings?
What if there are other changes?
What if the lines have different style?
I would refrain from making such changes to check/apply unless there's a
justification.
So far I do not care if the source build is broken for Windows, however, I
do not like how LF vs CRLF issue is ignored.
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Stamatis Zampetakis <za...@gmail.com>.
I was thinking that if the check says that there is no problem then apply
would be a noop.
I have the impression that source releases are necessary and obligatory so
that the ASF is covered from a legal perspective. If I am not mistaken even
companies with closed source code are obliged to release the sources (to
some 3rd party) so that if for some reason the company closes the clients
which bought the software have a way to recover the code and make changes
if necessary. I don't know much about legal stuff but I guess something
similar holds for the ASF. So even if nobody uses the source releases it is
necessary to provide one.
As you said it might be helpful for a few people to have the sources with
different line endings but given that nobody asked for it till now we could
skip it and keep our release process simpler.
On Thu, Dec 26, 2019 at 10:44 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Stamatis>I guess there are people who use Windows and they still have their
> editors
> Stamatis>configured to use LF endings.
>
> LF / CRLF uses Git configuration to figure out the needed line endings.
> In other words, if someone configures Git to use LF rather than "platform"
> line endings,
> the build would pick that up and accept LF files even in case the platform
> is Windows.
>
> Remember there's not just `check`, but there's `apply` as well.
> If we make `check` tolerable to wrong line endings, what do we do with
> `apply`?
> Does that mean `check` would say "it is all ok", and `apply` would change
> all the endings to their expected values?
>
> Note: if we are going to make that kind of changes, we'll need
> "[CALCITE-3623] Replace Spotless with Autostyle"
> https://github.com/apache/calcite/pull/1682
>
> Stamatis>opensource projects it is kind of rare to release
> Stamatis>source code in multiple formats with different line endings
>
> Frankly speaking, I would say it is rare to treat the source code as the
> primary release artifact.
>
> AFAIK the ASF way is to treat the source as the key release item.
> I recon in 99.42% of the times people who consume the source release would
> commit that to their VCS (Git? Mercurial? SVN? Fossil?)
>
> Our source release does include .gitattributes and .gitignore, so it would
> help people to import Calcite in their Git repositories.
> However, for other VCS it is important to have the source files in their
> "platform-expected" format.
>
> It is where having both CRLF-oriented and LF-oriented source releases help.
>
> At this point, you might say: "Vladimir, no-one imports Calcite source
> releases to their VCS repositories".
> It might be true, but what is the point of making a source release then?
> Is the policy of making source releases outdated?
>
> Stamatis>other weird behavior but these should not happen very often.
>
> Well, having .gitattributes does help a lot, but I remember that if one
> messes up with line endings, then it might be very hard to diff and
> re-commit the file appropriately.
> It is like the case when `git reset --hard` does not help.
> That is why it really helps when you can identify those issues early.
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Stamatis>I guess there are people who use Windows and they still have their
editors
Stamatis>configured to use LF endings.
LF / CRLF uses Git configuration to figure out the needed line endings.
In other words, if someone configures Git to use LF rather than "platform"
line endings,
the build would pick that up and accept LF files even in case the platform
is Windows.
Remember there's not just `check`, but there's `apply` as well.
If we make `check` tolerable to wrong line endings, what do we do with
`apply`?
Does that mean `check` would say "it is all ok", and `apply` would change
all the endings to their expected values?
Note: if we are going to make that kind of changes, we'll need
"[CALCITE-3623] Replace Spotless with Autostyle"
https://github.com/apache/calcite/pull/1682
Stamatis>opensource projects it is kind of rare to release
Stamatis>source code in multiple formats with different line endings
Frankly speaking, I would say it is rare to treat the source code as the
primary release artifact.
AFAIK the ASF way is to treat the source as the key release item.
I recon in 99.42% of the times people who consume the source release would
commit that to their VCS (Git? Mercurial? SVN? Fossil?)
Our source release does include .gitattributes and .gitignore, so it would
help people to import Calcite in their Git repositories.
However, for other VCS it is important to have the source files in their
"platform-expected" format.
It is where having both CRLF-oriented and LF-oriented source releases help.
At this point, you might say: "Vladimir, no-one imports Calcite source
releases to their VCS repositories".
It might be true, but what is the point of making a source release then?
Is the policy of making source releases outdated?
Stamatis>other weird behavior but these should not happen very often.
Well, having .gitattributes does help a lot, but I remember that if one
messes up with line endings, then it might be very hard to diff and
re-commit the file appropriately.
It is like the case when `git reset --hard` does not help.
That is why it really helps when you can identify those issues early.
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Stamatis Zampetakis <za...@gmail.com>.
Personally, I would opt for a more permissive build.
Unexpected line endings is kind of subjective.
I guess there are people who use Windows and they still have their editors
configured to use LF endings.
Moreover, checking other opensource projects it is kind of rare to release
source code in multiple formats with different line endings.
I didn't attempt to build these projects but I would be surprised if the
build fails depending on the OS.
Indeed in some cases these might lead to test failures or other weird
behavior but these should not happen very often.
On Tue, Dec 24, 2019 at 3:44 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Stamatis> do we have another option so that the build does not fail on
> Windows?
>
> It boils down to a question: should the build fail if the source files
> contain unexpected line endings?
>
> Suppose someone uses Windows, and they create test_sql_plan.txt file with
> wrong line endings (==LF).
> Should the build fail?
>
> Suppose someone uses Linux and they create a file with CRLF line endings.
> Should the build fail?
>
> Of course, Git will normalize the line endings at commit time, and
> everybody who pulls that commit would get the normalized file.
>
> However, if the local file is different from what Git expects, it might
> result in hard to understand conditions like
> unexpected test failures or inability to reproduce CI test failure.
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Stamatis> do we have another option so that the build does not fail on
Windows?
It boils down to a question: should the build fail if the source files
contain unexpected line endings?
Suppose someone uses Windows, and they create test_sql_plan.txt file with
wrong line endings (==LF).
Should the build fail?
Suppose someone uses Linux and they create a file with CRLF line endings.
Should the build fail?
Of course, Git will normalize the line endings at commit time, and
everybody who pulls that commit would get the normalized file.
However, if the local file is different from what Git expects, it might
result in hard to understand conditions like
unexpected test failures or inability to reproduce CI test failure.
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Stamatis Zampetakis <za...@gmail.com>.
Apart from releasing the zip archives do we have another option so that the
build on the tar.gz does not fail on Windows?
I don't remember anybody complaining about this when we were using the
maven build, so I am wondering if we had some special configuration.
On Sat, Dec 21, 2019 at 2:44 AM Francis Chuang <fr...@apache.org>
wrote:
> The broken dockerfiles are really trivial to fix and one of the reasons
> I'd like to fix them and release 1.17.0 is so that I can add 1.17.0 as a
> test target for Avatica-Go before releasing Avatica-Go 5.0.0.
>
> In addition to fixing the dockerfiles, we should:
> - Agree on whether we need to release a zip archive with source files
> encoded using Windows line endings. If we do go down this path, I think
> maybe we should add "windows" to the file name of the released
> artifacts, so as to not confuse people.
>
> - Reorder the tasks in publishDist so that the nexus artifacts are
> released first before the release is tagged.
>
> Francis
>
> On 21/12/2019 6:58 am, Rui Wang wrote:
> > I am less familiar with the broken docker stuff. Depending on how people
> > think about it: If it is not a big problem, one thing could be done is to
> > include it into the release notes with a section that mentions it (I have
> > seen such practice before).
> >
> >
> > -Rui
> >
> > On Fri, Dec 20, 2019 at 8:53 AM Stamatis Zampetakis <za...@gmail.com>
> > wrote:
> >
> >> First of all many thanks Francis for the release of 1.16.0. Being at the
> >> same time RM, contributor, and beta tester of the Gradle release build
> was
> >> definitely not easy :)
> >> Also special thanks to Vladimir who spend a lot of time polishing the
> new
> >> build system and helping in the resolution of the various problems.
> >> Last but not least, many thanks to all contributors of the 1.16.0, great
> >> work!
> >>
> >> Regarding the docker hub links, personally I don't find it a huge
> problem
> >> since people can still obtain and use the new release by other means.
> >> Having said that, I wouldn't mind having a 1.17.0 with the fix for
> docker.
> >> We could also take advantage of this, to decide if we want to do
> something
> >> for the build problem of the artifacts in Windows systems.
> >>
> >> Best,
> >> Stamatis
> >>
> >>
> >> On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang <
> francischuang@apache.org>
> >> wrote:
> >>
> >>> From past experience, I think it the files should become available as
> >>> long as the repository is marked as released within nexus, so this
> >>> shouldn't be too much of a problem.
> >>>
> >>> On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
> >>>> AFAIK it does wait for the Nexus to release, however, I have no idea
> if
> >>>> that means the files are immediately available.
> >>>>
> >>>> Vladimir
> >>>>
> >>>
> >>
> >
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
The broken dockerfiles are really trivial to fix and one of the reasons
I'd like to fix them and release 1.17.0 is so that I can add 1.17.0 as a
test target for Avatica-Go before releasing Avatica-Go 5.0.0.
In addition to fixing the dockerfiles, we should:
- Agree on whether we need to release a zip archive with source files
encoded using Windows line endings. If we do go down this path, I think
maybe we should add "windows" to the file name of the released
artifacts, so as to not confuse people.
- Reorder the tasks in publishDist so that the nexus artifacts are
released first before the release is tagged.
Francis
On 21/12/2019 6:58 am, Rui Wang wrote:
> I am less familiar with the broken docker stuff. Depending on how people
> think about it: If it is not a big problem, one thing could be done is to
> include it into the release notes with a section that mentions it (I have
> seen such practice before).
>
>
> -Rui
>
> On Fri, Dec 20, 2019 at 8:53 AM Stamatis Zampetakis <za...@gmail.com>
> wrote:
>
>> First of all many thanks Francis for the release of 1.16.0. Being at the
>> same time RM, contributor, and beta tester of the Gradle release build was
>> definitely not easy :)
>> Also special thanks to Vladimir who spend a lot of time polishing the new
>> build system and helping in the resolution of the various problems.
>> Last but not least, many thanks to all contributors of the 1.16.0, great
>> work!
>>
>> Regarding the docker hub links, personally I don't find it a huge problem
>> since people can still obtain and use the new release by other means.
>> Having said that, I wouldn't mind having a 1.17.0 with the fix for docker.
>> We could also take advantage of this, to decide if we want to do something
>> for the build problem of the artifacts in Windows systems.
>>
>> Best,
>> Stamatis
>>
>>
>> On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang <fr...@apache.org>
>> wrote:
>>
>>> From past experience, I think it the files should become available as
>>> long as the repository is marked as released within nexus, so this
>>> shouldn't be too much of a problem.
>>>
>>> On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
>>>> AFAIK it does wait for the Nexus to release, however, I have no idea if
>>>> that means the files are immediately available.
>>>>
>>>> Vladimir
>>>>
>>>
>>
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Rui Wang <am...@apache.org>.
I am less familiar with the broken docker stuff. Depending on how people
think about it: If it is not a big problem, one thing could be done is to
include it into the release notes with a section that mentions it (I have
seen such practice before).
-Rui
On Fri, Dec 20, 2019 at 8:53 AM Stamatis Zampetakis <za...@gmail.com>
wrote:
> First of all many thanks Francis for the release of 1.16.0. Being at the
> same time RM, contributor, and beta tester of the Gradle release build was
> definitely not easy :)
> Also special thanks to Vladimir who spend a lot of time polishing the new
> build system and helping in the resolution of the various problems.
> Last but not least, many thanks to all contributors of the 1.16.0, great
> work!
>
> Regarding the docker hub links, personally I don't find it a huge problem
> since people can still obtain and use the new release by other means.
> Having said that, I wouldn't mind having a 1.17.0 with the fix for docker.
> We could also take advantage of this, to decide if we want to do something
> for the build problem of the artifacts in Windows systems.
>
> Best,
> Stamatis
>
>
> On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang <fr...@apache.org>
> wrote:
>
> > From past experience, I think it the files should become available as
> > long as the repository is marked as released within nexus, so this
> > shouldn't be too much of a problem.
> >
> > On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
> > > AFAIK it does wait for the Nexus to release, however, I have no idea if
> > > that means the files are immediately available.
> > >
> > > Vladimir
> > >
> >
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Stamatis Zampetakis <za...@gmail.com>.
First of all many thanks Francis for the release of 1.16.0. Being at the
same time RM, contributor, and beta tester of the Gradle release build was
definitely not easy :)
Also special thanks to Vladimir who spend a lot of time polishing the new
build system and helping in the resolution of the various problems.
Last but not least, many thanks to all contributors of the 1.16.0, great
work!
Regarding the docker hub links, personally I don't find it a huge problem
since people can still obtain and use the new release by other means.
Having said that, I wouldn't mind having a 1.17.0 with the fix for docker.
We could also take advantage of this, to decide if we want to do something
for the build problem of the artifacts in Windows systems.
Best,
Stamatis
On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang <fr...@apache.org>
wrote:
> From past experience, I think it the files should become available as
> long as the repository is marked as released within nexus, so this
> shouldn't be too much of a problem.
>
> On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
> > AFAIK it does wait for the Nexus to release, however, I have no idea if
> > that means the files are immediately available.
> >
> > Vladimir
> >
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
From past experience, I think it the files should become available as
long as the repository is marked as released within nexus, so this
shouldn't be too much of a problem.
On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
> AFAIK it does wait for the Nexus to release, however, I have no idea if
> that means the files are immediately available.
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
AFAIK it does wait for the Nexus to release, however, I have no idea if
that means the files are immediately available.
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
Thanks for confirming, Vladimir. I'll fix the dockerfiles and make
1.17.0 available for voting.
Does the release repository task wait until the repository has been
fully released before returning? If so, I think it should be quite easy
to rearrange the tasks and we can get it into this release.
Francis
On 20/12/2019 8:51 am, Vladimir Sitnikov wrote:
> Francis>My assumption is that they should be equivalent, but I would love
> to get
> Francis>some confirmation first as releasing a broken 1.17.0 would cause
> more work.
>
> For instance,
> https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/1.15.0/avatica-standalone-server-1.15.0.pom
> declares
> lots of dependencies, however, 1.15-shaded.jar does bundle them. Why
> declare dependencies at pom level?
>
> In that regard, avatica-standalone-server-1.16.0.jar is more consistent.
> 1) The naming says "standalone", and the jar is indeed "standalone"
> 2) Its pom file declares the proper list of dependencies: an empty list
> 3) It is consistent with
> https://calcite.apache.org/avatica/docs/compatibility.html which says
> "called avatica-standalone-server. This artifact is a runnable jar (e.g.
> java -jar"
> Note: compatibility.html was not touched for quite a while.
>
> Of course, we can publish multiple jars under the same artifactid (e.g.
> non-shaded and shaded), but I would recommend refraining from using
> classifiers like `-shaded`
> It is better to use distinct artifact ids for shaded vs non-shaded as it
> enables us to convey proper dependency and other metadata for each jar.
>
> ---
>
> Regarding "push release tag" vs "push Nexus" vs "push SVN" ordering I do
> not have a strong preference.
> "push tag" could probably be moved to the end of the list.
>
> For now, the tasks can be executed individually like
> gw releaseRepository
> gw publishSvnDist -x pushReleaseTag
> gw pushReleaseTag
>
> Vladimir
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Francis>My assumption is that they should be equivalent, but I would love
to get
Francis>some confirmation first as releasing a broken 1.17.0 would cause
more work.
For instance,
https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/1.15.0/avatica-standalone-server-1.15.0.pom
declares
lots of dependencies, however, 1.15-shaded.jar does bundle them. Why
declare dependencies at pom level?
In that regard, avatica-standalone-server-1.16.0.jar is more consistent.
1) The naming says "standalone", and the jar is indeed "standalone"
2) Its pom file declares the proper list of dependencies: an empty list
3) It is consistent with
https://calcite.apache.org/avatica/docs/compatibility.html which says
"called avatica-standalone-server. This artifact is a runnable jar (e.g.
java -jar"
Note: compatibility.html was not touched for quite a while.
Of course, we can publish multiple jars under the same artifactid (e.g.
non-shaded and shaded), but I would recommend refraining from using
classifiers like `-shaded`
It is better to use distinct artifact ids for shaded vs non-shaded as it
enables us to convey proper dependency and other metadata for each jar.
---
Regarding "push release tag" vs "push Nexus" vs "push SVN" ordering I do
not have a strong preference.
"push tag" could probably be moved to the end of the list.
For now, the tasks can be executed individually like
gw releaseRepository
gw publishSvnDist -x pushReleaseTag
gw pushReleaseTag
Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Francis Chuang <fr...@apache.org>.
I did check the difference between the -shaded.jar (1.15.0) and .jar
(1.16.0) files on nexus yesterday and they seemed to be roughly the same
size, at least much bigger than the .jar files in (1.15.0).
My assumption is that they should be equivalent, but I would love to get
some confirmation first as releasing a broken 1.17.0 would cause more work.
On 20/12/2019 7:46 am, Kevin Risden wrote:
> I haven't looked into this in detail yet, but can share details on one of
> the questions:
>
>
>> - Can anyone confirm if the
>> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
>> avatica-standalone-server-${AVATICA_VERSION}.jar.
>> jars are suppose to be equivalent?
>>
>
> The Maven built used the maven-shade-plugin to build a jar with all the
> dependencies included. It could shaded dependencies if needed, but from
> what I remember it was only for putting all the dependencies into a single
> jar. Maven would typically leave the .jar alone and then would have a
> -shaded.jar next to it with all the dependencies.
>
> I don't know what the gradle build is doing in this case. The easiest way
> to look is to see if the new .jar is close to the same size as the old
> -shaded.jar. The new and old versions should be comparable on Nexus.
>
> Kevin Risden
>
>
> On Wed, Dec 18, 2019 at 9:59 PM Francis Chuang <fr...@apache.org>
> wrote:
>
>> Upon finalizing the release for Avatica 1.16.0, I noticed that the
>> dockerfiles would not build on docker hub. Upon investigation, it
>> appears that the file names of the jars on nexus has changed slightly.
>>
>> The current dockerfiles [1] references
>>
>> https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/${AVATICA_VERSION}/avatica-standalone-server-${AVATICA_VERSION}-shaded.jar
>>
>> Where as on nexus, they are now called
>> avatica-standalone-server-${AVATICA_VERSION}.jar.
>>
>> - Can anyone confirm if the
>> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
>> avatica-standalone-server-${AVATICA_VERSION}.jar.
>> jars are suppose to be equivalent?
>>
>>
>> - Since the docker images for 1.16.0 cannot be built, I think we ought
>> to fix the dockerfiles and release a 1.17.0.
>>
>> Francis
>>
>> [1]
>>
>> https://github.com/apache/calcite-avatica/tree/master/docker/src/main/dockerhub
>>
>
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
Posted by Kevin Risden <kr...@apache.org>.
I haven't looked into this in detail yet, but can share details on one of
the questions:
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
The Maven built used the maven-shade-plugin to build a jar with all the
dependencies included. It could shaded dependencies if needed, but from
what I remember it was only for putting all the dependencies into a single
jar. Maven would typically leave the .jar alone and then would have a
-shaded.jar next to it with all the dependencies.
I don't know what the gradle build is doing in this case. The easiest way
to look is to see if the new .jar is close to the same size as the old
-shaded.jar. The new and old versions should be comparable on Nexus.
Kevin Risden
On Wed, Dec 18, 2019 at 9:59 PM Francis Chuang <fr...@apache.org>
wrote:
> Upon finalizing the release for Avatica 1.16.0, I noticed that the
> dockerfiles would not build on docker hub. Upon investigation, it
> appears that the file names of the jars on nexus has changed slightly.
>
> The current dockerfiles [1] references
>
> https://repository.apache.org/content/groups/public/org/apache/calcite/avatica/avatica-standalone-server/${AVATICA_VERSION}/avatica-standalone-server-${AVATICA_VERSION}-shaded.jar
>
> Where as on nexus, they are now called
> avatica-standalone-server-${AVATICA_VERSION}.jar.
>
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
>
> - Since the docker images for 1.16.0 cannot be built, I think we ought
> to fix the dockerfiles and release a 1.17.0.
>
> Francis
>
> [1]
>
> https://github.com/apache/calcite-avatica/tree/master/docker/src/main/dockerhub
>