Hi,
I’m sorry for the late reply on the subject.
Generally, Apache-releases are source releases [3] and so adding a
precompiled jar without sources would prevent us from being able to
release AsterixDB. So we will have to find another solution.
A few options that I can think of right now would be to
1) make it an optional dependency and require the user to
require/obtain the jar external and to provide it to the platform that
they build on or to
2) include the source files in the AsterixDB source repository or to
3) download and build the source as part of the build process.
Of these 3 options, I think that 1) is the cleanest option from a
licensing perspective, 2) can be managed if we understand the
provenance of the source files and 3) seems problematic as we would put
a load on a system that provide the source for every build and as we
could retrieve use unvetted source code.
Thoughts/concerns about these options?
Does anybody see other options?
Cheers,
Till
[3] http://www.apache.org/legal/release-policy.html#artifacts
On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
Dear all,
Is there a way to ship a jar file as a dependency for AsterixDB apart
from
the method I have used here[1]. This is because the build of
asterix-app
seems to fail[2] when I use the external jar file like this.
Though I am unable to find a connection between the failure and the
dependency it seems I need to assume that it is the cause, because
otherwise if I use the Maven-released version the build passes without
issue.
Any help would be highly appreciated.
[1]
https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/asterix-om/pom.xml
[2] https://asterix-gerrit.ics.uci.edu/#/c/1895
On 22 July 2017 at 01:59, Ahmed Eldawy <[email protected]> wrote:
Although Esri resolved the issue, their Maven-released version still
relies
on the incompatible library. We can wait until they release a new
version
on Maven but this might take a while. To be able to merge the current
code,
we might need to compile our own JAR file and ship it with the source
code.
Do you know if this is possible/allowed/recommended in AsterixDB? Is
there
another preferred way to handle this issue? Keep in mind that, most
likely,
the summer project will conclude before Esri releases the new
version.
Thanks
Ahmed
On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <[email protected]>
wrote:
NICE!!!
On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
There's a good news. Riyafa has opened an issue on ESRI Geometry
API
project on Github about the license problem and they made the
necessary
changes to remove the bad dependency.
https://github.com/Esri/geometry-api-java/issues/135
The changes are on their github repository but they are not
released
yet.
I
think we can just continue what we're doing and wait for the new
release
to
hit Maven repository.
Thanks
Ahmed
On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <[email protected]>
wrote:
It sounds like the best option is 4 minus parsing, then, if we can
do
that. (Which would also address Wail's comments, which could be a
killer
for big data eventually.) If not, we could go with 2 for the
summer
as a
first step, I guess? (But figuring out the feasibility of 4 would
be
great...)
Cheers,
Mike
On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
It seems that (3) would require modifying the open source Esri API
library
which I don't like. Not only for the overhead of understanding
and
modifying the code, but also for deviating from the standard
library
which
means we will miss future updates. One of the reasons we chose to
use
Esri
API is the hope that it will be well-maintained in the future.
This leaves us with (4). I don't know if it is technically
possible to
depend on the standard Esri API without using the non-compliant
library
or
not. If this is possible, then we can just use the computational
geometry
(CG) functionality from the library, and provide our own GeoJSON
parser.
If
this is not possible, then I would rather consider the use of
another
library, e.g., JTS.
Thanks
Ahmed
On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
[email protected]>
wrote:
I can see from the code that there is a serder steps as such:
Asterix
Object (binary) --> JSON (String) --> Esri geometry (Java
object) -->
Esri
geometry (binary).
I think it would be nice if there is a binary-to-binary
conversion
without
any deserialization (4th option).
On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <[email protected]>
wrote:
Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
On 6/25/17 5:57 AM, Till Westmann wrote:
Hi Riyafa,
I think that the problem is bigger than the failing test. The
JSON
license itself is not acceptable for inclusion in an Apache
artifact
[4]. So we cannot use the ESRI API as-is, if we want the
GeoJSON
functionality be a non-optional part of AsterixDB.
Here are a few options I see:
1) Make GeoJSON an optional part of AsterixDB (separate
download
from a
non-Apache location).
2) Make JSON.org a dependency that is not shipped (i.e. each
user
would
have to download and install those jars separately - and
get
error
messages if the jars are not available).
3) Create a clone/copy of the ESRI API that uses another JSON
library.
4) Do all of the parsing independently from the ESRI API.
I’m not sure if 1) is a good option as the extensibility in
this
part
of the code might not be sufficient to support this option
easily.
2) is technically easier, but it involves an unpleasant user
experience.
Also, I think that both 1) and 2) are not desirable, as
GeoJSON
should
be supported by vanilla AsterixDB.
For 3) and 4) we would need to look into the details to see
how
much
work is required for each of those options and if there are
other
legal
hurdles.
Are there other options?
Other thoughts/concerns?
Cheers,
Till
[4] https://www.apache.org/legal/resolved.html#category-x
On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
Dear all,
I implemented parse_geojon() function[1] using esri-geometry
api[2]
which
is apache-2.0 licensed. But this api uses org.json as a
dependency.
org.json is licensed under JSON which causes a license issue
in the
code
I
have written[3]. What can I do about this issue?
[1] https://asterix-gerrit.ics.uci.edu/1838
[2]https://github.com/Esri/geometry-api-java
[3]
https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
ration-tests/3290/
Thank you.
Yours sincerely,
Riyafa
--
*Regards,*
Wail Alkowaileet
--
Ahmed Eldawy
Assistant Professor
http://www.cs.ucr.edu/~eldawy
Tel: +1 (951) 827-5654
--
Riyafa Abdul Hameed
Undergraduate, University of Moratuwa
Email: [email protected]
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>
