Cool. I wouldn’t expect much improvement but your observations will be really helpful when we tackle GEODE-27 in earnest.
Anthony > On Feb 10, 2016, at 10:05 AM, John Blum <[email protected]> wrote: > > No problem, :-). As an FYI... I am retesting Spring Session with Apache > Geode M1 release to see if the release POM helps resolve the dependency > issues I had. Will report back my findings. > > On Wed, Feb 10, 2016 at 9:52 AM, Anthony Baker <[email protected]> wrote: > >> John, thanks for working through this. Great suggestions! >> >> Anthony >> >>> On Feb 10, 2016, at 8:21 AM, John Blum <[email protected]> wrote: >>> >>> Following up... >>> >>> I spent a few extra cycles researching the *Apache Geode* dependencies >>> further. >>> >>> Looking at the POM file >>> < >> https://repo1.maven.org/maven2/org/apache/geode/gemfire-core/1.0.0-incubating.M1/gemfire-core-1.0.0-incubating.M1.pom >>> >>> [0] >>> (for gemfire-core) for the M1 release of *Apache Geode* in Maven Central, >>> it appears the Repository declarations were removed (+1). >>> >>> However, you still want to clean up the Repository declarations on >> develop >>> as much as possible. Certainly, we should remove mavenLocal(), >>> mavenCentral() and all *Spring repo* declarations (here >>> < >> https://github.com/apache/incubator-geode/blob/develop/build.gradle#L46-L52 >>> >>> [1]). >>> mavenCentral() is redundant. mavenLocal() is dangerous. And, all >> *Spring* >>> dependencies (e.g. *Spring Data GemFire*), at least versions that *Apache >>> Geode* should depend on (i.e. "GA" versions; or >>> major.minor.maint.*RELEASE*) are >>> all available in Maven Central (e.g. here >>> <http://search.maven.org/#search%7Cga%7C1%7Cspring-data-gemfire> [2]). >>> >>> But... >>> >>> With respect to *Apache Geode* dependencies, you really have to decide >>> whether the POM file will be used to "*build* *Apache Geode"*, or rather, >>> just resolve dependencies required by *Apache Geode* to "*build* and >> *run* >>> applications". This is a significant difference, and in most cases, you >>> want the later, especially since *Apache Geode* already has an elaborate >>> "build" developed with Gradle. >>> >>> So, this means a developer should not see things like "test" dependencies >>> in the POM resolved from Maven Central (e.g. powermock (yikes), >>> mockito/jmock or even junit for that matter), especially when the user's >>> application (test) dependencies may be quite different. >>> >>> Even dependencies such as Jetty should not appear (i.e. OPTIONAL) in the >>> POM, since technically, this is a dependency for other Geode services >> that >>> only come into play if the service is enabled (e.g. Management's HTTP >>> service hosting Pulse or the Management REST API that tunnels *Gfsh* >> calls >>> through HTTP rather than JMX RMI). Other good examples include Netty or >>> MX4J. >>> >>> As an example, compare the dependencies defined by *Spring Data >> GemFire's* >>> build >>> < >> https://github.com/spring-projects/spring-data-gemfire/blob/master/build.gradle#L64-L104 >>> >>> [3] >>> as compared to *Spring Data GemFire's* POM >>> < >> https://repo1.maven.org/maven2/org/springframework/data/spring-data-gemfire/1.7.2.RELEASE/spring-data-gemfire-1.7.2.RELEASE.pom >>> >>> [4] >>> file. >>> >>> In general, the fewer dependencies a user has to pick up in order to >> build >>> an application using *Apache Geode*, the better! Often times, developers >>> concern themselves unnecessarily with JAR file size when it is actually >> the >>> number of JAR files that really matters. Moving more towards a more >>> modular architecture (similar to the core *Spring Framework*) will go a >>> long ways in helping to control the dependencies at appropriate times and >>> places. >>> >>> Hope this helps clarify my point and the reason for GEODE-27. >>> >>> Thanks! >>> John >>> >>> >>> [0] - >>> >> https://repo1.maven.org/maven2/org/apache/geode/gemfire-core/1.0.0-incubating.M1/gemfire-core-1.0.0-incubating.M1.pom >>> [1] - >>> >> https://github.com/apache/incubator-geode/blob/develop/build.gradle#L46-L52 >>> [2] - http://search.maven.org/#search%7Cga%7C1%7Cspring-data-gemfire >>> [3] - >>> >> https://github.com/spring-projects/spring-data-gemfire/blob/master/build.gradle#L64-L104 >>> [4] - >>> >> https://repo1.maven.org/maven2/org/springframework/data/spring-data-gemfire/1.7.2.RELEASE/spring-data-gemfire-1.7.2.RELEASE.pom >>> >>> On Tue, Feb 9, 2016 at 7:23 PM, John Blum <[email protected]> wrote: >>> >>>> Technically, GEODE-27 <https://issues.apache.org/jira/browse/GEODE-27> >> [0] >>>> was less about the format and more about fixing the POM so it is >> correct. >>>> >>>> Revising my earlier comments (in the JIRA), the repository declarations >>>> < >> https://github.com/apache/incubator-geode/blob/develop/build.gradle#L45-L54> >> [1], >>>> especially if publishing to *Maven Central* should be removed >> altogether. >>>> The dependencies needed to be cleaned up so that they are appropriately >>>> marked as either OPTIONAL, or not, with the appropriate SCOPE (e.g. >> test, >>>> runtime, etc) and exclusions to avoid conflicts, etc. >>>> >>>> Previously, Geode was pulling in the world and I at least ran into 1 >>>> conflict while working on the Spring Session GemFire adapter, for which >> I >>>> needed to add exclusions... >>>> >>>> >>>> >> https://github.com/jxblum/spring-session/blob/sgf373-apachegeode/spring-session-data-gemfire/build.gradle#L11-L16 >>>> >>>> This may have been cleaned up for the release (1.0.0-incubating.M1), >>>> though I am not certain since I have not checked recently (well, after >> the >>>> release) and have since then moved onto other things. >>>> >>>> -John >>>> >>>> [0] - https://issues.apache.org/jira/browse/GEODE-27 >>>> [1] - >>>> >> https://github.com/apache/incubator-geode/blob/develop/build.gradle#L45-L54 >>>> >>>> >>>> On Tue, Feb 9, 2016 at 4:03 PM, Dan Smith <[email protected]> wrote: >>>> >>>>> This seems like a pretty reasonable list to me. Maybe add in GEODE-818 >> to >>>>> M2 as well? GEODE-27 talks about cleaning up the pom, but it's more >> about >>>>> fixing the format. GEODE-818 is about removing uneeded dependencies. >>>>> >>>>> -Dan >>>>> >>>>> On Tue, Feb 9, 2016 at 8:23 AM, Anthony Baker <[email protected]> >> wrote: >>>>> >>>>>> I walked through JIRA this morning. There’s a lot of really >> interesting >>>>>> stuff we should consider for M2. However, I think we should err on >> the >>>>>> conservative side given that we already have a lot of work in flight >>>>> (e.g. >>>>>> Pulse, Modules, WAN, CQ, etc) and we don’t want to run too long before >>>>> our >>>>>> next release. Given the new code additions, I would expect 2-3 RC’s >>>>> will >>>>>> be needed. >>>>>> >>>>>> I’ve grouped and stack ranked the tickets that seem relevant to M2 >>>>> below. >>>>>> This is just IMO and I would appreciate community input on this. >>>>>> >>>>>> Tests: >>>>>> GEODE-944 (Test failure when ISP intercepts DNS failure) >>>>>> RC2 test failures from Brian Dunlap [1] >>>>>> ----- ^ M2 ^ ----- >>>>>> >>>>>> Security: >>>>>> GEODE-562 (Remove or upgrade commons-collections) >>>>>> ----- ^ M2 ^ ----- >>>>>> >>>>>> IP: >>>>>> GEODE-906 (Cleanup source headers) >>>>>> GEODE-905 (Source headers) >>>>>> GEODE-901 (Source headers) >>>>>> GEODE-907 (Remove JSON code from pulse) >>>>>> GEODE-903 (Copyright date on footer) >>>>>> GEODE-914 (NOTICE) >>>>>> GEODE-904 (LICENSE) >>>>>> GEODE-918 (Add license header to generated pom) >>>>>> ----- ^ M2 ^ ----- v M3 v ----- >>>>>> GEODE-835 (remove gemfire-joptsimple) >>>>>> GEODE-629 (JSON parser) >>>>>> GEODE-868 (Autogenerate NOTICE) >>>>>> >>>>>> Maven: >>>>>> GEODE-26 (remove mavenLocal) >>>>>> GEODE-917 (rename artifacts to geode) >>>>>> GEODE-27 (Maven POM) >>>>>> GEODE-946 (maven artifacts) >>>>>> ----- ^ M2 ^ ----- v M3 v ----- >>>>>> GEODE-919 (Don’t checksum signature files) >>>>>> >>>>>> Docs: >>>>>> GEODE-945 (Javadoc warning) >>>>>> GEODE-54 (javadocs) >>>>>> GEODE-887 (README) >>>>>> GEODE-884 (README) >>>>>> GEODE-876 (Add README to binary distro) >>>>>> GEODE-874 (COMPILING / RUNNING) >>>>>> ----- ^ M2 ^ ----- v M3 v ----- >>>>>> GEODE-33 (example code) >>>>>> >>>>>> Other: >>>>>> GEODE-12 (Pulse) >>>>>> ----- ^ M2 ^ ----- v M3 v ----- >>>>>> GEODE-25 (crypto audit) >>>>>> GEODE-786 (Update SDG to 1.7.2) >>>>>> GEODE-543 (Upgrade jline and spring shell) >>>>>> GEODE-57 (Update library versions) >>>>>> GEODE-52 (@author) >>>>>> GEODE-37 (package renaming) >>>>>> GEODE-36 (Rename gfsh) >>>>>> >>>>>> >>>>>> Anthony >>>>>> >>>>>> [1] >>>>>> >>>>> >> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201601.mbox/%3ccafdh8_1cuvs36a7yppjod9b4k1cip_p8kepkxn+wbxe4kzq...@mail.gmail.com%3e >>>>>> >>>>>> >>>>>>> On Feb 5, 2016, at 3:39 PM, Nitin Lamba <[email protected]> wrote: >>>>>>> >>>>>>> Thanks Dan! >>>>>>> We should perhaps discuss this topic in detail during our next Geode >>>>>> Clubhouse. >>>>>>> >>>>>>> @Mike, agree 100% with your prioritization though WAN and CQ have >>>>>> already been merged with develop. So unless any testing/ performance >>>>> issues >>>>>> pop-up, we'll get those included as part of the next milestone release >>>>>> automatically. >>>>>>> >>>>>>> - Nitin >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Dan Smith <[email protected]> >>>>>>> Sent: Thursday, February 4, 2016 1:46 PM >>>>>>> To: geode >>>>>>> Subject: Re: [DISCUSS] Next Release Scope - version >>>>> 1.0.0-incubating.M2 >>>>>>> >>>>>>> I added the bugs listed above, and a some others, to the M2 wiki page >>>>> so >>>>>> we >>>>>>> don't lose track of them. We can discuss if some of these need to get >>>>>>> pushed out of M2. >>>>>>> >>>>>>> I also created some subtasks for GEODE-823. >>>>>>> >>>>>>> On Mon, Feb 1, 2016 at 7:09 AM, Michael Stolz <[email protected]> >>>>> wrote: >>>>>>> >>>>>>>> I'd like to see the focus on docs and dependencies first. >>>>>>>> Then incorporation of WAN and CQ features. >>>>>>>> >>>>>>>> -- >>>>>>>> Mike Stolz >>>>>>>> Principal Engineer, GemFire Product Manager >>>>>>>> Mobile: 631-835-4771 >>>>>>>> >>>>>>>> On Fri, Jan 29, 2016 at 12:26 PM, Nitin Lamba <[email protected]> >>>>> wrote: >>>>>>>> >>>>>>>>> Thought of starting a separate thread to discuss next release >>>>> scope. So >>>>>>>>> far we have the following suggestions: >>>>>>>>> >>>>>>>>> Dan: >>>>>>>>> - GEODE-823 - remove gemfire-joptsimple, gemfire-json, rename to >>>>>> geode-, >>>>>>>>> other misc issues >>>>>>>>> - GEODE-818 - clean up dependencies >>>>>>>>> - GEODE-572 - generate public javadocs (part of GEODE-54) >>>>>>>>> - GEODE-33 - create project examples >>>>>>>>> >>>>>>>>> John: >>>>>>>>> - GEODE-27 - fix POM dependencies - related to RC feedback above >>>>>>>>> (GEODE-818) >>>>>>>>> >>>>>>>>> Few left-over from prior discussions: >>>>>>>>> >>>>>>>>> - GEODE-386 - fixing xsd namespace to Apache >>>>>>>>> - GEODE-36 - fixing gfsh cli (Removing GemFire references) >>>>>>>>> - GEODE-37 - package re-naming >>>>>>>>> >>>>>>>>> Some of these are big ticket items so we may have to space these >> out >>>>>>>>> across Milestones. >>>>>>>>> >>>>>>>>> ACTION: Please suggest on this thread OR edit the wiki page[1] so >>>>> that >>>>>>>>> JIRA [2] can be prioritized accordingly. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Nitin >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>> >>>>>> >>>>> >> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release >>>>>>>>> [2] >>>>>>>>> >>>>>>>> >>>>>> >>>>> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> -John >>>> 503-504-8657 >>>> john.blum10101 (skype) >>>> >>> >>> >>> >>> -- >>> -John >>> 503-504-8657 >>> john.blum10101 (skype) >> >> > > > -- > -John > 503-504-8657 > john.blum10101 (skype)
signature.asc
Description: Message signed with OpenPGP using GPGMail
