Stefan Bodewig <[EMAIL PROTECTED]> wrote on 07/17/2008 04:01:34 AM:
> > I spent a lot of time & effort writing a thread-safe logger for our
> > own internal use.
>
> Sounds as if it was more painful than I had expected.
It's been quite a while, so my memory is a little hazy, but IIRC much of
th
On Thu, Jul 17, 2008 at 4:16 PM, Scheper, Erik-Berndt <
[EMAIL PROTECTED]> wrote:
> I've been thinking about suggesting this before, but now that the trunk has
> broken (undesired) changes that worked fine in beta-2, it might be a good
> idea to postpone most of the outstanding issues for RC1 to a
I've been thinking about suggesting this before, but now that the trunk has
broken (undesired) changes that worked fine in beta-2, it might be a good idea
to postpone most of the outstanding issues for RC1 to a RC2 and release RC1
asap.
That would promote better testing of the 100+ bug-fixes
Just a wild guess, but maybe you could use IvyAntSettings again (like your
original code was), but instead of calling the execute method you can register
it yourself as Reference in the Project, something like:
IvyAntSettings settings = new IvyAntSettings();
settings.setXXX...
getProject().addRe
On Thu, Jul 17, 2008 at 10:00 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jul 2008, Xavier Hanin <[EMAIL PROTECTED]> wrote:
>
> > Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was
> > broken in that sense. Introducing a setId method for backward
> compatiblity
>
On Fri, 11 Jul 2008, Jeffrey E. Care <[EMAIL PROTECTED]> wrote:
> I spent a lot of time & effort writing a thread-safe logger for our
> own internal use.
Sounds as if it was more painful than I had expected.
> If there's sufficient interest I'd be willing to get the ball
> rolling on getting the
On Wed, 16 Jul 2008, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was
> broken in that sense. Introducing a setId method for backward compatiblity
> with something broken in concept doesn't sound really nice IMO. We will
> probably fo