Re: [DISCUSS] GEODE-7241 - make Jar not War?
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?
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?
@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?
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?
@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?
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?
@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?
-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?
@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?
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?
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?
> 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?
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?
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?
@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?
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?
> 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?
+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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 >
[DISCUSS] GEODE-7241 - make Jar not War?
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