if you want, I have ERJGroupsSynchronizer.framework zipped. I can send you mine. it is jgroups 3.6.1. you should be able to just drop it in!
Ted On May 1, 2015, at 12:36 PM, Samuel Pelletier <sam...@samkar.com> wrote: > This kind of situation is the main problem with the current Wonder structure > of having everything on a single repo that produce a huge package. This > create dead lock situation like this one where it is not possible to upgrade > Wonder without upgrade ERJGroupsSynchronizer but we want to upgrade > ERJGroupsSynchronizer without upgrading others without their consent or even > knowledge. > > With separate projects in independent repo, each of theses frameworks can be > managed and versioned. So upgrading Wonder would not imply upgrading the > ERJGroupsSynchronizer. > > The actual situation is almost required by the current ant build system, this > is why I think the Gradle presentation was really eye opening. If we can > switch to a modern build system that manage dependency, we will be able to > break that dead lock cycle by creating many sub repository for each > specialized frameworks or family of interdependent frameworks. > > Is this make sense ? > > Samuel > > >> Le 2015-05-01 à 09:13, Ken Anderson <kenli...@anderhome.com> a écrit : >> >> Paul, >> >> These are the basic reasons I didn’t tackle this as well. I can’t imagine >> anyone would want to use the very old JGroups jar, but who knows? Maybe we >> need a way for someone to post feedback so that we can determine whether or >> not it’s OK to upgrade. >> >> Ken >> >>> On May 1, 2015, at 9:10 AM, Paul Hoadley <pa...@logicsquad.net> wrote: >>> >>> Hi Ted, >>> >>> On 1 May 2015, at 10:05 pm, Theodore Petrosky <tedp...@yahoo.com> wrote: >>> >>>> don’t know if this is of interest but I created a pull request for this: >>>> >>>> https://github.com/wocommunity/wonder/pull/626 >>> >>> Thanks for pointing this out. I didn’t know this pull request was open. >>> It kind of helps to demonstrate, though, why I was reluctant to touch the >>> framework directly myself—I simply don’t know enough about it. What I got >>> running on EC2, for example, uses the 3.4.0 JAR. Does this matter? I >>> don’t know. Does updating 2.6.8 to 3.4.0 (let alone 3.6.1) cause >>> backward-compatibility issues? I don’t know. Mike Schrag wrote it, and >>> he’s long gone—does anyone else understand it deeply? I don’t know. >>> >>> This also ties in nicely with the thread started by Jean Pierre Malrieu the >>> other day. A pull request like Ted’s doesn’t sit there for three months >>> untouched because no one cares, it’s because no one _dares_. >>> >>> >>> -- >>> Paul Hoadley >>> http://logicsquad.net/ >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com >>> >>> This email sent to kenli...@anderhome.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >> >> This email sent to sam...@samkar.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com > > This email sent to tedp...@yahoo.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
