We cannot use code licensed under the JSON.org license—it’s Category X [1].
There is an alternative [2] from an ASF member that was the basis for
geode-json. Can we use that? The packaging looks like org.json to me.
Anthony
[1] https://www.apache.org/legal/resolved.html#category-x
[2] https:/
sure vaadin and geose-json are VERY similar...
On Fri, Mar 15, 2019, 16:32 Dan Smith wrote:
> Here's the original legal ticket -
> https://issues.apache.org/jira/browse/LEGAL-349. It does seem kinda fuzzy.
>
> What error are you getting if you remove geode-json? I don't see org.json
> anywhere i
+1 for the change and +1 for BOMs.
We currently have an “all” BOM and a client BOM. Defining server and other
usecase derived BOMs should be easy.
-jake
> On Mar 15, 2019, at 4:16 PM, John Blum wrote:
>
> If users will be explicitly declaring such dependencies in their
> applications, then I
Here's the original legal ticket -
https://issues.apache.org/jira/browse/LEGAL-349. It does seem kinda fuzzy.
What error are you getting if you remove geode-json? I don't see org.json
anywhere in the dependenies of geode-web-api:
./gradlew geode-web-api:dependencies
I also found this thing - whic
There is a lengthy discussion about the org.json license & Apache here:
https://lwn.net/Articles/707510/
There is a precursor to open-json that I've successfully used to test
the geode-web-api module described here:
http://stackoverflow.com/a/34418410/2171120
On 3/15/19 2:06 PM, Bruce Schuch
IMO, I think it would better serve the project if were to remove it
completely and replace it with jackson.
On 3/15/19 14:06, Bruce Schuchardt wrote:
I've removed use of geode-json in non-test code and I'd like to remove
it completely and just add a dependency on a org.json package in a
Maven
If users will be explicitly declaring such dependencies in their
applications, then I might also suggest declaring/generating a Maven
section in the POM to ensure that the user is
getting and using the right version of these dependencies, especially when
they don't care about the version (i.e. the
That seems like a great idea
On 3/15/19 11:53 AM, Dan Smith wrote:
Hi,
We would like to start using gradle's new implementation dependency
notation in our build files.
This will affect downstream consumers of geode-core, hopefully in a good
way, in that many of our dependencies will now be mar
I've removed use of geode-json in non-test code and I'd like to remove
it completely and just add a dependency on a org.json package in a Maven
repository. The only one available is org.json though, so here's the
question: Is acceptable to use org.json with it's silly license (see
below) if we
Hi,
We would like to start using gradle's new implementation dependency
notation in our build files.
This will affect downstream consumers of geode-core, hopefully in a good
way, in that many of our dependencies will now be marked runtime
dependencies in the pom instead of compile. That means it
I have a PR[1] to include LICENSE and NOTICE changes to develop.
Once I have merged this to develop then I will cherry-pick this onto 1.9.0
release branch.
[1] https://github.com/apache/geode/pull/3313
On Wed, Feb 27, 2019 at 5:32 PM Anthony Baker wrote:
> I was reviewing the release branch and
11 matches
Mail list logo
