Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-10-04 Thread Robert Houghton
This has been merged to develop.

On Tue, Oct 1, 2019 at 8:15 AM Jens Deppe  wrote:

> Somewhat related to this - I've found that the V1 Admin Rest API
> (geode-web) will not start when Spring 5 libs are on the classpath. I've
> raised https://issues.apache.org/jira/browse/GEODE-7261. I'd like to see
> this included too.
>
> --Jens
>
> On Mon, Sep 30, 2019 at 12:35 PM Udo Kohlmeyer  wrote:
>
> > @Robert, I think the consensus is that WAR is the correct option.
> >
> > So unless someone objects, GEODE-7241 is a GO!
> >
> > --Udo
> >
> > On 9/30/19 10:58 AM, Robert Houghton wrote:
> > > I am unclear on the consensus of this thread.
> > >
> > > On Wed, Sep 25, 2019 at 12:55 PM John Blum  wrote:
> > >
> > >> @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I
> never
> > >> heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
> > >>
> > >> On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett 
> > >> wrote:
> > >>
> > >>> Udo,
> > >>>
> > >>> I didn’t say we shouldn’t fix it for the future. I said I don’t
> believe
> > >> it
> > >>> warrants a backport and a patch release.
> > >>>
> > >>> -Jake
> > >>>
> > >>>
> > >> --
> > >> -John
> > >> john.blum10101 (skype)
> > >>
> >
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-10-01 Thread Jens Deppe
Somewhat related to this - I've found that the V1 Admin Rest API
(geode-web) will not start when Spring 5 libs are on the classpath. I've
raised https://issues.apache.org/jira/browse/GEODE-7261. I'd like to see
this included too.

--Jens

On Mon, Sep 30, 2019 at 12:35 PM Udo Kohlmeyer  wrote:

> @Robert, I think the consensus is that WAR is the correct option.
>
> So unless someone objects, GEODE-7241 is a GO!
>
> --Udo
>
> On 9/30/19 10:58 AM, Robert Houghton wrote:
> > I am unclear on the consensus of this thread.
> >
> > On Wed, Sep 25, 2019 at 12:55 PM John Blum  wrote:
> >
> >> @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
> >> heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
> >>
> >> On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett 
> >> wrote:
> >>
> >>> Udo,
> >>>
> >>> I didn’t say we shouldn’t fix it for the future. I said I don’t believe
> >> it
> >>> warrants a backport and a patch release.
> >>>
> >>> -Jake
> >>>
> >>>
> >> --
> >> -John
> >> john.blum10101 (skype)
> >>
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-30 Thread Udo Kohlmeyer

@Robert, I think the consensus is that WAR is the correct option.

So unless someone objects, GEODE-7241 is a GO!

--Udo

On 9/30/19 10:58 AM, Robert Houghton wrote:

I am unclear on the consensus of this thread.

On Wed, Sep 25, 2019 at 12:55 PM John Blum  wrote:


@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.

On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett 
wrote:


Udo,

I didn’t say we shouldn’t fix it for the future. I said I don’t believe

it

warrants a backport and a patch release.

-Jake



--
-John
john.blum10101 (skype)



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-30 Thread Robert Houghton
I am unclear on the consensus of this thread.

On Wed, Sep 25, 2019 at 12:55 PM John Blum  wrote:

> @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
> heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
>
> On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett 
> wrote:
>
> > Udo,
> >
> > I didn’t say we shouldn’t fix it for the future. I said I don’t believe
> it
> > warrants a backport and a patch release.
> >
> > -Jake
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread John Blum
@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.

On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett  wrote:

> Udo,
>
> I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
> warrants a backport and a patch release.
>
> -Jake
>
>

-- 
-John
john.blum10101 (skype)


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Jacob Barrett
Udo,

I didn’t say we shouldn’t fix it for the future. I said I don’t believe it 
warrants a backport and a patch release.

-Jake



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Udo Kohlmeyer
@Jake, whilst I agree with your statement that there is a preference 
that sers use GFSH to manage their clusters. With that statement are you 
also making a blanket statement we should remove the exposed public 
API's we expose in GEODE to start a Client/Server/Locator?


IF the expected usage of the product is to download it and not use 
dependency management, should we then also remove `geode-core`, 
`geode-wan`, `geode-lucene` artifacts, as all of these would also be 
within the dependencies listed in the geode-dependecies.jar?


It DOES sound counter productive and in essence a little backwards, but 
if our "prescribed" approach to interact/bootstrap/configure/manage 
Geode is to use GFSH, then we should remove all other temptations.


--Udo

On 9/25/19 12:10 PM, Jacob Barrett wrote:


-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  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  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


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Jacob Barrett
-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  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  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



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Udo Kohlmeyer
@Anthony, you must have missed the LACK OF excitement in that 
question... 1.8.x should stay as is... I was merely asking the question.


--Udo

On 9/25/19 11:58 AM, Anthony Baker wrote:

Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to 
there.  I’m personally not as excited about a new 1.8 patch release but I’m 
open to hearing your ideas :-)

Anthony



On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  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  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


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Anthony Baker
Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to 
there.  I’m personally not as excited about a new 1.8 patch release but I’m 
open to hearing your ideas :-)

Anthony


> On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  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  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



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Udo Kohlmeyer
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  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


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Jacob Barrett


> On Sep 25, 2019, at 11:01 AM, John Blum  wrote:
> -1 to publishing a GWAR file.  These are still valid WAR files regardless
> of the dependencies they provide or don't provide (which is a documentation
> concern in my mind).

Just to be really clear, GWAR was a joke and a reference to the popular 80/90s 
band. 落落落落

-Jake




Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread John Blum
It occurred to me after *Charlie* shared the link to installing *Pulse* in
a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly
describe how to handle the Geode dependencies (e.g. geode-core).  Again,
this is not bundled as part of the Geode WAR files.

-1 to publishing a GWAR file.  These are still valid WAR files regardless
of the dependencies they provide or don't provide (which is a documentation
concern in my mind).


On Wed, Sep 25, 2019 at 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 
> 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
>
>

-- 
-John
john.blum10101 (skype)


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Anthony Baker
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  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



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Udo Kohlmeyer
@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

On 9/25/19 8:32 AM, Anthony Baker wrote:

Udo,

Can you update GEODE-7241 to help us understand the reason why we need to 
publish geode-web* WARs to maven?  I get that we used to do this but I can’t 
recall why we choose that approach.

There is one request for Pulse on maven (GEODE-6208).

Anthony



On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:

Maybe the better question is, WHY are we publishing geode-web and geode-web-api.

Pulse, from what I remember, could be a standalone deployment. At least that is 
what I remember.

Most likely an oversight...

--Udo

On 9/24/19 3:38 PM, Robert Houghton wrote:

The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?

On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
wrote:


I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?

I think this problem was an oversight from the changes PurelyApplied and I
made to the build when we made the publish plugin 'opt-in' instead of
forced by the root project. Easy to publish one or the other, but I am not
qualified to decide whether a war or jar is more appropriate for these
modules.

Thank you,
-Robert



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Charlie Black
Just incase here is the docs on pushing the war:
https://geode.apache.org/docs/guide/16/tools_modules/pulse/pulse-hosted.html

On Wed, Sep 25, 2019 at 9:53 AM Jacob Barrett  wrote:

>
>
> > On Sep 25, 2019, at 9:33 AM, Dan Smith  wrote:
> >
> > +1 to making them .GWAR instead :)
>
> Ok I think this constitutes consensus on GWAR!  ;)
>


-- 
Charlie Black | cbl...@pivotal.io


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Jacob Barrett



> On Sep 25, 2019, at 9:33 AM, Dan Smith  wrote:
> 
> +1 to making them .GWAR instead :)

Ok I think this constitutes consensus on GWAR!  ;)


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Juan José Ramos
+1 to Jens and John comments.
I'm 100% sure some of our users certainly deploy the *war* file (at least
the *PULSE* one) to external web application servers.
Cheers.

On Wed, Sep 25, 2019 at 5:07 PM Jens Deppe  wrote:

> I also cannot recall any reason as to the need to *publish* wars.
>
> However, please do not change the files to .jar. To John's point, despite
> the lack of some dependent jars, the structure still conforms to a .war
> format.
>
> --Jens
>
> On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:
>
> > Actually, to clarify 2 points.
> >
> > 1. Technically, it is a bit more involved than simply just validating the
> > "format".  For instance, the web.xml file must be valid and well-formed.
> > 2. There was a reason why the geode-core and other Apache Geode libs were
> > not bundled in WEB-INF/lib of the WAR files, since then it would create
> > duplication on the global as well as the WAR file's (isolated)
> ClassLoader
> > classpath, particularly for the "embedded" Geode Servlet Container case,
> > and as such, ClassLoader problems would occur.
> >
> >
> >
> > On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
> >
> > > Udo,
> > >
> > > Can you update GEODE-7241 to help us understand the reason why we need
> to
> > > publish geode-web* WARs to maven?  I get that we used to do this but I
> > > can’t recall why we choose that approach.
> > >
> > > There is one request for Pulse on maven (GEODE-6208).
> > >
> > > Anthony
> > >
> > >
> > > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > > >
> > > > Maybe the better question is, WHY are we publishing geode-web and
> > > geode-web-api.
> > > >
> > > > Pulse, from what I remember, could be a standalone deployment. At
> least
> > > that is what I remember.
> > > >
> > > > Most likely an oversight...
> > > >
> > > > --Udo
> > > >
> > > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > > >> The geode-pulse module also builds a war, but does not publish it.
> Is
> > > this
> > > >> an oversight, or by design?
> > > >>
> > > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > >> wrote:
> > > >>
> > > >>> I am working on the change to get the geode-web and geode-web-api
> war
> > > >>> artifacts published instead of the jars. I have found the
> > > >>> geode-web-management project is also producing a war artifact, in
> > > addition
> > > >>> to a jar. Do we want it to be published as well? What is the
> > criterion
> > > we
> > > >>> use to decide?
> > > >>>
> > > >>> I think this problem was an oversight from the changes
> PurelyApplied
> > > and I
> > > >>> made to the build when we made the publish plugin 'opt-in' instead
> of
> > > >>> forced by the root project. Easy to publish one or the other, but I
> > am
> > > not
> > > >>> qualified to decide whether a war or jar is more appropriate for
> > these
> > > >>> modules.
> > > >>>
> > > >>> Thank you,
> > > >>> -Robert
> > > >>>
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
Juan José Ramos Cassella
Senior Software Engineer
Email: jra...@pivotal.io


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Dan Smith
I could see value in publishing the war files, if geode will actually pick
up the war file from the classpath and deploy it when these features are
enabled. Udo - it looks like you actually made a change with GEODE-5660 to
enable that?

+1 to making them .GWAR instead :)

-Dan

On Wed, Sep 25, 2019 at 9:07 AM Jens Deppe  wrote:

> I also cannot recall any reason as to the need to *publish* wars.
>
> However, please do not change the files to .jar. To John's point, despite
> the lack of some dependent jars, the structure still conforms to a .war
> format.
>
> --Jens
>
> On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:
>
> > Actually, to clarify 2 points.
> >
> > 1. Technically, it is a bit more involved than simply just validating the
> > "format".  For instance, the web.xml file must be valid and well-formed.
> > 2. There was a reason why the geode-core and other Apache Geode libs were
> > not bundled in WEB-INF/lib of the WAR files, since then it would create
> > duplication on the global as well as the WAR file's (isolated)
> ClassLoader
> > classpath, particularly for the "embedded" Geode Servlet Container case,
> > and as such, ClassLoader problems would occur.
> >
> >
> >
> > On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
> >
> > > Udo,
> > >
> > > Can you update GEODE-7241 to help us understand the reason why we need
> to
> > > publish geode-web* WARs to maven?  I get that we used to do this but I
> > > can’t recall why we choose that approach.
> > >
> > > There is one request for Pulse on maven (GEODE-6208).
> > >
> > > Anthony
> > >
> > >
> > > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > > >
> > > > Maybe the better question is, WHY are we publishing geode-web and
> > > geode-web-api.
> > > >
> > > > Pulse, from what I remember, could be a standalone deployment. At
> least
> > > that is what I remember.
> > > >
> > > > Most likely an oversight...
> > > >
> > > > --Udo
> > > >
> > > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > > >> The geode-pulse module also builds a war, but does not publish it.
> Is
> > > this
> > > >> an oversight, or by design?
> > > >>
> > > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > >> wrote:
> > > >>
> > > >>> I am working on the change to get the geode-web and geode-web-api
> war
> > > >>> artifacts published instead of the jars. I have found the
> > > >>> geode-web-management project is also producing a war artifact, in
> > > addition
> > > >>> to a jar. Do we want it to be published as well? What is the
> > criterion
> > > we
> > > >>> use to decide?
> > > >>>
> > > >>> I think this problem was an oversight from the changes
> PurelyApplied
> > > and I
> > > >>> made to the build when we made the publish plugin 'opt-in' instead
> of
> > > >>> forced by the root project. Easy to publish one or the other, but I
> > am
> > > not
> > > >>> qualified to decide whether a war or jar is more appropriate for
> > these
> > > >>> modules.
> > > >>>
> > > >>> Thank you,
> > > >>> -Robert
> > > >>>
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Jens Deppe
I also cannot recall any reason as to the need to *publish* wars.

However, please do not change the files to .jar. To John's point, despite
the lack of some dependent jars, the structure still conforms to a .war
format.

--Jens

On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:

> Actually, to clarify 2 points.
>
> 1. Technically, it is a bit more involved than simply just validating the
> "format".  For instance, the web.xml file must be valid and well-formed.
> 2. There was a reason why the geode-core and other Apache Geode libs were
> not bundled in WEB-INF/lib of the WAR files, since then it would create
> duplication on the global as well as the WAR file's (isolated) ClassLoader
> classpath, particularly for the "embedded" Geode Servlet Container case,
> and as such, ClassLoader problems would occur.
>
>
>
> On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
>
> > Udo,
> >
> > Can you update GEODE-7241 to help us understand the reason why we need to
> > publish geode-web* WARs to maven?  I get that we used to do this but I
> > can’t recall why we choose that approach.
> >
> > There is one request for Pulse on maven (GEODE-6208).
> >
> > Anthony
> >
> >
> > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > >
> > > Maybe the better question is, WHY are we publishing geode-web and
> > geode-web-api.
> > >
> > > Pulse, from what I remember, could be a standalone deployment. At least
> > that is what I remember.
> > >
> > > Most likely an oversight...
> > >
> > > --Udo
> > >
> > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > >> The geode-pulse module also builds a war, but does not publish it. Is
> > this
> > >> an oversight, or by design?
> > >>
> > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton  >
> > >> wrote:
> > >>
> > >>> I am working on the change to get the geode-web and geode-web-api war
> > >>> artifacts published instead of the jars. I have found the
> > >>> geode-web-management project is also producing a war artifact, in
> > addition
> > >>> to a jar. Do we want it to be published as well? What is the
> criterion
> > we
> > >>> use to decide?
> > >>>
> > >>> I think this problem was an oversight from the changes PurelyApplied
> > and I
> > >>> made to the build when we made the publish plugin 'opt-in' instead of
> > >>> forced by the root project. Easy to publish one or the other, but I
> am
> > not
> > >>> qualified to decide whether a war or jar is more appropriate for
> these
> > >>> modules.
> > >>>
> > >>> Thank you,
> > >>> -Robert
> > >>>
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread John Blum
Actually, to clarify 2 points.

1. Technically, it is a bit more involved than simply just validating the
"format".  For instance, the web.xml file must be valid and well-formed.
2. There was a reason why the geode-core and other Apache Geode libs were
not bundled in WEB-INF/lib of the WAR files, since then it would create
duplication on the global as well as the WAR file's (isolated) ClassLoader
classpath, particularly for the "embedded" Geode Servlet Container case,
and as such, ClassLoader problems would occur.



On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:

> Udo,
>
> Can you update GEODE-7241 to help us understand the reason why we need to
> publish geode-web* WARs to maven?  I get that we used to do this but I
> can’t recall why we choose that approach.
>
> There is one request for Pulse on maven (GEODE-6208).
>
> Anthony
>
>
> > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> >
> > Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
> >
> > Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
> >
> > Most likely an oversight...
> >
> > --Udo
> >
> > On 9/24/19 3:38 PM, Robert Houghton wrote:
> >> The geode-pulse module also builds a war, but does not publish it. Is
> this
> >> an oversight, or by design?
> >>
> >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> >> wrote:
> >>
> >>> I am working on the change to get the geode-web and geode-web-api war
> >>> artifacts published instead of the jars. I have found the
> >>> geode-web-management project is also producing a war artifact, in
> addition
> >>> to a jar. Do we want it to be published as well? What is the criterion
> we
> >>> use to decide?
> >>>
> >>> I think this problem was an oversight from the changes PurelyApplied
> and I
> >>> made to the build when we made the publish plugin 'opt-in' instead of
> >>> forced by the root project. Easy to publish one or the other, but I am
> not
> >>> qualified to decide whether a war or jar is more appropriate for these
> >>> modules.
> >>>
> >>> Thank you,
> >>> -Robert
> >>>
>
>

-- 
-John
john.blum10101 (skype)


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Anthony Baker
Udo, 

Can you update GEODE-7241 to help us understand the reason why we need to 
publish geode-web* WARs to maven?  I get that we used to do this but I can’t 
recall why we choose that approach.

There is one request for Pulse on maven (GEODE-6208).

Anthony


> On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> 
> Maybe the better question is, WHY are we publishing geode-web and 
> geode-web-api.
> 
> Pulse, from what I remember, could be a standalone deployment. At least that 
> is what I remember.
> 
> Most likely an oversight...
> 
> --Udo
> 
> On 9/24/19 3:38 PM, Robert Houghton wrote:
>> The geode-pulse module also builds a war, but does not publish it. Is this
>> an oversight, or by design?
>> 
>> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
>> wrote:
>> 
>>> I am working on the change to get the geode-web and geode-web-api war
>>> artifacts published instead of the jars. I have found the
>>> geode-web-management project is also producing a war artifact, in addition
>>> to a jar. Do we want it to be published as well? What is the criterion we
>>> use to decide?
>>> 
>>> I think this problem was an oversight from the changes PurelyApplied and I
>>> made to the build when we made the publish plugin 'opt-in' instead of
>>> forced by the root project. Easy to publish one or the other, but I am not
>>> qualified to decide whether a war or jar is more appropriate for these
>>> modules.
>>> 
>>> Thank you,
>>> -Robert
>>> 



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread John Blum
Bundling "all" dependencies in a WAR file is a rather subjective topic
since, typically, in practice developers did not bundle things like JDBC
drivers in a WAR file for their Web app.  Common practice was to put
"shared" libs in the Servlet Containers global libs directory (using the
Common ClassLoader) for shared consumption by all Web apps, for better or
worse.

WAR files (like JAR and EAR) are based on "format" (e.g. containing a
WEB-INF/web.xml file, with WEB-INF/classes of the app and possibly libs in
WEB-INF/lib), not simply just deps. As such, by following this format, the
container will consider this a "valid" WAR file.

However, if we are just basing it on libs, then none of the WAR files are
valid by that definition (not even Pulse) because none contain the
necessary Apache Geode libs (e.g. geode-core).  Therefore, none of the WAR
files could stand on their own, not even Pulse.


On Wed, Sep 25, 2019 at 8:17 AM Udo Kohlmeyer  wrote:

> Seems these should have been Jars all along...
>
> On 9/24/19 8:09 PM, Jacob Barrett wrote:
> > Why publish them as WAR files at all? As they are currently packaged
> they can't be deployed in just any J2EE web container because they lack all
> the dependencies. Sure they look like WAR files internally but they are
> really modules that expect to run in and only in the Geode server.
> Publishing them as a WAR file gives the false impression that they can be
> consumed by any project as a full fledged WAR.
> >
> > We should make up our own JAR spec based on WAR, perhaps calling it
> Geode Web ARchive or GWAR for short. Yes, I just went there… GWAR!!!
> 落落落落
> >
> > But seriously, unless it can be deployed in any J2EE web container it
> shouldn’t be considered a WAR.
> >
> > -Jake
> >
> >> On Sep 24, 2019, at 3:34 PM, Robert Houghton 
> wrote:
> >>
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
>


-- 
-John
john.blum10101 (skype)


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-25 Thread Udo Kohlmeyer

Seems these should have been Jars all along...

On 9/24/19 8:09 PM, Jacob Barrett wrote:

Why publish them as WAR files at all? As they are currently packaged they can't 
be deployed in just any J2EE web container because they lack all the 
dependencies. Sure they look like WAR files internally but they are really 
modules that expect to run in and only in the Geode server. Publishing them as 
a WAR file gives the false impression that they can be consumed by any project 
as a full fledged WAR.

We should make up our own JAR spec based on WAR, perhaps calling it Geode Web 
ARchive or GWAR for short. Yes, I just went there… GWAR!!! 落落落落

But seriously, unless it can be deployed in any J2EE web container it shouldn’t 
be considered a WAR.

-Jake


On Sep 24, 2019, at 3:34 PM, Robert Houghton  wrote:

I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?

I think this problem was an oversight from the changes PurelyApplied and I
made to the build when we made the publish plugin 'opt-in' instead of
forced by the root project. Easy to publish one or the other, but I am not
qualified to decide whether a war or jar is more appropriate for these
modules.

Thank you,
-Robert


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-24 Thread Jacob Barrett
Why publish them as WAR files at all? As they are currently packaged they can't 
be deployed in just any J2EE web container because they lack all the 
dependencies. Sure they look like WAR files internally but they are really 
modules that expect to run in and only in the Geode server. Publishing them as 
a WAR file gives the false impression that they can be consumed by any project 
as a full fledged WAR.

We should make up our own JAR spec based on WAR, perhaps calling it Geode Web 
ARchive or GWAR for short. Yes, I just went there… GWAR!!! 落落落落

But seriously, unless it can be deployed in any J2EE web container it shouldn’t 
be considered a WAR.

-Jake

> On Sep 24, 2019, at 3:34 PM, Robert Houghton  wrote:
> 
> I am working on the change to get the geode-web and geode-web-api war
> artifacts published instead of the jars. I have found the
> geode-web-management project is also producing a war artifact, in addition
> to a jar. Do we want it to be published as well? What is the criterion we
> use to decide?
> 
> I think this problem was an oversight from the changes PurelyApplied and I
> made to the build when we made the publish plugin 'opt-in' instead of
> forced by the root project. Easy to publish one or the other, but I am not
> qualified to decide whether a war or jar is more appropriate for these
> modules.
> 
> Thank you,
> -Robert



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-24 Thread Michael Oleske
For context, these are the docs for running Pulse as stand alone
https://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_795C97B46B9843528961A094EE520782

The instructions always seemed odd since we tell folks to go "tools/pulse"
to copy the pulse.war file to their dedicated web application server.  I
don't think we have many tests that test that particular configuration
though.

-michael

On Tue, Sep 24, 2019 at 3:44 PM Udo Kohlmeyer  wrote:

> Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
>
> Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
>
> Most likely an oversight...
>
> --Udo
>
> On 9/24/19 3:38 PM, Robert Houghton wrote:
> > The geode-pulse module also builds a war, but does not publish it. Is
> this
> > an oversight, or by design?
> >
> > On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> > wrote:
> >
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
> >>
>


Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-24 Thread Udo Kohlmeyer
Maybe the better question is, WHY are we publishing geode-web and 
geode-web-api.


Pulse, from what I remember, could be a standalone deployment. At least 
that is what I remember.


Most likely an oversight...

--Udo

On 9/24/19 3:38 PM, Robert Houghton wrote:

The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?

On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
wrote:


I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?

I think this problem was an oversight from the changes PurelyApplied and I
made to the build when we made the publish plugin 'opt-in' instead of
forced by the root project. Easy to publish one or the other, but I am not
qualified to decide whether a war or jar is more appropriate for these
modules.

Thank you,
-Robert



Re: [DISCUSS] GEODE-7241 - make Jar not War?

2019-09-24 Thread Robert Houghton
The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?

On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
wrote:

> I am working on the change to get the geode-web and geode-web-api war
> artifacts published instead of the jars. I have found the
> geode-web-management project is also producing a war artifact, in addition
> to a jar. Do we want it to be published as well? What is the criterion we
> use to decide?
>
> I think this problem was an oversight from the changes PurelyApplied and I
> made to the build when we made the publish plugin 'opt-in' instead of
> forced by the root project. Easy to publish one or the other, but I am not
> qualified to decide whether a war or jar is more appropriate for these
> modules.
>
> Thank you,
> -Robert
>