Julian>It is difficult to build LICENSE and NOTICE files automatically
So what?
I claim that automatic license compilation produces better results than
currently present license files in Apache Calcite source code.
I claim that automatic license compilation produces better results than
currently
It is difficult to build LICENSE and NOTICE files automatically.
For example, if you have copied some code from a project that has a NOTICE file
you only need to copy the lines of the NOTICE that pertain to the code that you
have copied. If we don’t exercise judgment we will end up creating
Michael>Concatenating licenses
Michael>seems to be an easy fix
Frankly speaking, I have not implemented neither concatenation nor "folder
with licenses".
Both seem to be easy to implement.
Michael>We're nowhere near that for Calcite are we?
Could be.
maven-shade is used for Geode, and mvn
> For instance, in JMeter we have ~1MiB of license texts.
We're nowhere near that for Calcite are we? Concatenating licenses
seems to be an easy fix. That said, if the switch to Gradle makes
another approach equally easy, I don't have a real preference.
--
Michael Mior
mm...@apache.org
Le mer.
Stamatis>it seems that a single LICENCE
Stamatis>file with some separator is very common
I'm not that sure.
For instance, in JMeter we have ~1MiB of license texts.
Having that "with some separator" would probably be more like a torture for
the reader.
Stamatis>Lucene
That is an interesting
Thanks for taking care of this Vladimir.
I have not worked with LICENSE files directly but checking other Apache
projects (e.g., Spark, Lucene, Tomcat, etc.) it seems that a single LICENCE
file with some separator is very common so I would assume is an acceptable
choice.
Best,
Stamatis
On Tue,
1) Michael, Julian, Danny, et all. Thanks for the participation.
2) There's a separate thread for Gradle discussion. Please find it by the
subject of "CALCITE-3158, Avatica: migrate build system to Gradle".
3) I would really like to keep this thread dedicated to "LICENSE file
formatting".
Of
I haven't really encountered the same problems with Maven that you
have and I agree with Julian's point about adding maintenance
overhead. However, the build time improvements are impressive. Is
there any reason we need to use Kotlin for the build script? Couldn't
this just be more Java?
--
Proof that the amount of knowledge required to maintain Avatica and Calcite is
straightforward. There are more lines of code, the code is getting older, and
the number of technologies is increasing. I don’t know how you can refute that
claim.
The question is what we can do to resist that
Personally I’m not that familiar with Gradle, the maven build is enough for me
Well, I think it’s the personal preference just like the user who likes Java
more than Scala, although Scala did have some cool features, it is also hard to
understand(sometimes confused and conflicted).
Best,
Danny
Julian>The amount of knowledge required to maintain Avatica (and Calcite)
is increasing even as Avatica does basically the same thing it did two
years ago.
I would argue here. Below are the issues from the top of my head. They
can't be solved with Maven and they would just go away.
1) Current
This change introduces yet another new language - Kotlin script (.kts
extension) - as well as gradle.
Vladimir made a case for adding Kotlin-based tests to Calcite a while ago. They
have not been used or extended, afaict.
The amount of knowledge required to maintain Avatica (and Calcite) is
Hi,
I've started Maven -> Gradle for Avatica:
https://github.com/apache/calcite-avatica/pull/104
Feedback is very welcome.
Note: the same is coming for Calcite, so you'd better try it sooner than
later :)
Gradle project builds, loads into IDEA. It runs checkstyle/forbiddenapis.
The build file
13 matches
Mail list logo
