Issues preventing a Usergrid 2.x release

[Dave <sn...@gmail.com>]

I’m looking into creating a Usergrid 2.x release, both in source-code and
binary (convenience release) form.

Problem is, Usergrid 2.x depends on some patched dependencies. These are
Java WNS, for sending Windows Phone push notifications, and Astyanax for
Cassandra storage.  We need the patched versions to work around critical
bugs in these components.

Currently, these two components are stored as JAR files in local Maven
repositories within our Git repo and cannot be included in our source code
release.

Possible solutions to this problem:

1. Wait for component owners to accept our patches, make releases and
publish to Maven Central
We’ve been waiting for a long time and may have to wait longer.
Not really an acceptible solution.

2. Wait for somebody else to publish their own patched version of these
components to Maven Central
Somebody else can fork and public patched builds to Maven Central with a
different groupId.
Are there Apache Policy restrictions that prevent us from doing this?

3. With our source code release: include docs that explain how to patch and
build those components.
This is very annoying and inconvenient for our users.
Are there Apache Policy restrictions that prevent us from doing this?
Would be better to have use Git to get our release tag.

I believe that the problems with Java WNS and Astyanax are not really a
problem for our binary (convenience) release. The dependencies above would
simply be build into the ROOT.war and would not cause problems for
end-users.

At this point I think a combination of solution #2 and #3 is best for our
end-users. We would depend on patched versions of the components published
to Maven Central by somebody (Apigee) *and* we would include instructions
on how to recreate those components from the original sources.

More food for thought: I’m thinking about the following layout for our
binary release:

+- apache-usergrid-2.1.0
   - README.txt
   - webapps/ROOT.war
   - lib/usergrid-java-sdk.jar
   - lib/usergrid-deployment-example.properties
   - lib/usregrid.js

Thoughts?

Thanks,
Dave

Re: Issues preventing a Usergrid 2.x release

[Michael Russo <mi...@gmail.com>]

The issues with dependencies in Usergrid 2.x source code have been fixed.
Astyanax and java-wns dependencies are now pulled in from maven central and
not local maven repositories.  Astyanax merged the needed PR, released, and
published a new version (3.9.0).  The java-wns library (forked and patched
compatible version) was released and published to Maven Central by Apigee.

The *master* and *release* branches have these issues fixed and are no
longer an issue.

Thanks.
-Michael

On Tue, Jan 26, 2016 at 6:42 AM, Dave <sn...@gmail.com> wrote:

> I’m looking into creating a Usergrid 2.x release, both in source-code and
> binary (convenience release) form.
>
> Problem is, Usergrid 2.x depends on some patched dependencies. These are
> Java WNS, for sending Windows Phone push notifications, and Astyanax for
> Cassandra storage.  We need the patched versions to work around critical
> bugs in these components.
>
> Currently, these two components are stored as JAR files in local Maven
> repositories within our Git repo and cannot be included in our source code
> release.
>
> Possible solutions to this problem:
>
> 1. Wait for component owners to accept our patches, make releases and
> publish to Maven Central
> We’ve been waiting for a long time and may have to wait longer.
> Not really an acceptible solution.
>
> 2. Wait for somebody else to publish their own patched version of these
> components to Maven Central
> Somebody else can fork and public patched builds to Maven Central with a
> different groupId.
> Are there Apache Policy restrictions that prevent us from doing this?
>
> 3. With our source code release: include docs that explain how to patch and
> build those components.
> This is very annoying and inconvenient for our users.
> Are there Apache Policy restrictions that prevent us from doing this?
> Would be better to have use Git to get our release tag.
>
> I believe that the problems with Java WNS and Astyanax are not really a
> problem for our binary (convenience) release. The dependencies above would
> simply be build into the ROOT.war and would not cause problems for
> end-users.
>
> At this point I think a combination of solution #2 and #3 is best for our
> end-users. We would depend on patched versions of the components published
> to Maven Central by somebody (Apigee) *and* we would include instructions
> on how to recreate those components from the original sources.
>
> More food for thought: I’m thinking about the following layout for our
> binary release:
>
> +- apache-usergrid-2.1.0
>    - README.txt
>    - webapps/ROOT.war
>    - lib/usergrid-java-sdk.jar
>    - lib/usergrid-deployment-example.properties
>    - lib/usregrid.js
>
> Thoughts?
>
> Thanks,
> Dave
>