+1 -- the binary works for me :-)
On 2/16/16 3:19 PM, Ate Douma wrote:
On 2016-02-11 03:28, Ian Maxon wrote:
Please vote
[ ] +1 release these packages as Apache AsterixDB 0.8.8-incubating and
Apache AsterixDB Hyracks 0.2.17-incubating
[ ] 0 No strong feeling either way
[ ] -1 do not release one or both packages because ...
+1
Besides what already was reported earlier by Till I have a few additional
comments but also none that need to hold off this release:
* The Copyright year in the sources root NOTICE files (and both
*-source-release.zip files) need updating from 2015 to 2016.
* apache-asterixdb-0.8.8-incubating-source-release.zip, LICENSE file:
- bottle.py in asterix-examples/src/main/resources/admaql101-demo
folder is
also contained in the sibling tweetbook-demo, so should likewise be
'linked'
in the LICENSE file.
* asterix-installer-0.8.8-incubating-binary-assembly.zip, NOTICE file,
and
asterix-server-0.8.8-incubating-binary-assembly.zip, NOTICE file:
- First things first, this looks very good, and definitely good enough
for now.
- While many/most bundled artifacts are listed and attributed, a few
stand out
to be missing, like all repo/hadoop* artifacts (23x).
I also noticed however that none of these hadoop artifacts have a
NOTICE nor a
LICENSE file bundled themselves, while of course they should as have
them
as ASF released artifacts. Not a good example :-(
That said, many/common 3rd party non-ASF libraries don't bundle a
L/N file,
but still we need to make sure they are properly attributed in
either or
both of our LICENSE or NOTICE.
This means we'll have to do manual digging/hunting what their possible
license and notice conditions are etc. No license means *off limits*
to use.
This is also where attempts to automate/generate ASF LICENSE and
NOTICE files
always end up failing...
Anyway, this is not a blocker for sure, just something which can be
fixed with a future release.
Furthermore, with respect to (only) merging other ASF project(s)
"Name + Copyright Year" from their NOTICE, this is current under
debate if
it actually is needed or not, see [1].
For the record: I'm not convinced yet this isn't needed and inclined to
reopen [1], once I've some spare time to discuss this further.
Concerning my earlier feedback about empty artifacts, to which you
replied:
>> * Not needed (empty) artifacts (also their -sources variants).
>> Consider skipping these through maven-deploy-plugin configuration:
>> - hyracks-documentation-0.2.17-incubating.jar
>> - hyracks-integration-tests-0.2.17-incubating.jar
>> - hyracks-storage-am-bloomfilter-test-0.2.17-incubating.jar
>> - hyracks-storage-am-btree-test-0.2.17-incubating.jar
>> - hyracks-storage-am-lsm-btree-test-0.2.17-incubating.jar
>> - hyracks-storage-am-lsm-common-test-0.2.17-incubating.jar
>> - hyracks-storage-am-lsm-invertedindex-test-0.2.17-incubating.jar
>> - hyracks-storage-am-lsm-rtree-test-0.2.17-incubating.jar
>> - hyracks-storage-am-rtree-test-0.2.17-incubating.jar
>> - hyracks-storage-common-test-0.2.17-incubating.jar
>> - asterix-doc-0.8.8-incubating.jar
>> - asterix-server-0.8.8-incubating.jar
>>
>
> All of these except asterix-server are not deployed now. (along with
> some others that were less than necessary). The only one in that list
> that is still deployed is asterix-server, as I wasn't quite sure how to
> not deploy the jar but still deploy the assembled binary.
For asterix-server I think this can be fixed by using
<packaging>pom</packaging>
instead of default <packaging>jar</packaging>?
Overall hats off for the impressive quality delivered!
Kind regard, Ate
[1] https://issues.apache.org/jira/browse/LEGAL-234
