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)
