-1 for updating previous releases or merging into the current release. I see no overwhelming need to have these published so that a downstream project can subvert the prescribed why of starting a server with all its dependencies. A workaround to this issue is to depend on the full distribution tgz and use gfsh or geode-dependencies.jar to start things up.
-Jake > On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > > So it seems there is consensus around jar vs war. WAR's win by nose. (until > we can find a more creative way to expose said artifacts) > > That said, do we need to start another thread about fixing 1.8.x or 1.9.x? > > I'm already considering proposing that GEODE-7241 is included into 1.9.2, as > that patch release is already discussed to backport GEODE-7121. > > --Udo > > On 9/25/19 10:53 AM, Anthony Baker wrote: >> Thanks for the reminder. If these files are required to start a geode >> member, I agree they should be published artifacts. Perhaps there’s a >> better way to pull them in…but this seems like the best option for now. >> >> Anthony >> >> >>> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: >>> >>> @Anthony. Ticket was updated.. In a nutshell, to run integration tests, >>> using the REST endpoints, requires the starting of the server with and >>> embedded web-server. >>> >>> As all tests run on dependency management only and don't have access to a >>> downloaded product, the HTTP endpoints are not part of the dependency. >>> These are added in by including the WAR files from mavenCentral. >>> >>> As @Dan pointed out, GEODE-5660 enabled this behavior. >>> >>> I think this approach might actually even help with the testing of the REST >>> Controller in the Geode codebase itself. >>> >>> --Udo
