On May 31, 2010, at 1:31 AM, Stefan Bodewig wrote:
On 2010-05-30, carn...@apache.org wrote:
Added:
gump/metadata/project/logging-log4j-2.xml
- copied unchanged from r949450,
gump/metadata/project/logging-log4j-12.xml
this is likely not what you have intended (the unchanged
On Aug 19, 2008, at 3:23 AM, Stefan Bodewig wrote:
On Mon, 18 Aug 2008, Curt Arnold [EMAIL PROTECTED] wrote:
There are some pending tests for log4j that would require activemq-
core as a dependency.
I wouldn't expect activemq-core to ever build, so adding the
dependency will just lead
There are some pending tests for log4j that would require activemq-
core as a dependency. In r686446, I added a dependency to project/
logging-log4j-12.xml:
Index: project/logging-log4j-12.xml
===
--- project/logging-log4j-12.xml
I just noticed that ant-contrib was not building and was starting to
research it when I noticed that Stefan has already been working on
it. I believe there is both an Ivy 1.4 dependency and Ivy 2.0
dependency in the current code base, so it may need both the ivy and
On Aug 27, 2007, at 11:01 PM, Stefan Bodewig wrote:
On Tue, 28 Aug 2007, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=570292view=rev
Log:
Removing log4j 1.3 project descriptor
Removed:
gump/metadata/project/logging-log4j.xml
That's not enough, it has to be removed
That appears to have been painless. No project seemed to break by
reverting all projects back to log4j 1.2. At this point, project/
logging-log4j.xml could be removed from profile/gump.xml. I'll let
you make the call on whether to leave it in there to monitor the
health of our abandoned
On Aug 13, 2007, at 10:59 PM, Stefan Bodewig wrote:
On Mon, 13 Aug 2007, Curt Arnold [EMAIL PROTECTED] wrote:
We've reorganized the log4j repo to move log4j 1.3 to a branch
clearly marked abandoned and move log4j 1.2 back to trunk.
It may be a good idea to rename the logging-logj-12
On Aug 7, 2007, at 11:17 PM, Stefan Bodewig wrote:
The nlog4j project just seems abandoned (since it won't even come
close to compile with the re-structured slf4j).
unfortunately the directory projects seem to depend on it.
I problem should engage them to see what would prevent them from
On Aug 7, 2007, at 11:17 PM, Stefan Bodewig wrote:
The nlog4j project just seems abandoned (since it won't even come
close to compile with the re-structured slf4j).
unfortunately the directory projects seem to depend on it.
The directory project only seem to have slf4j dependencies and
We've reorganized the log4j repo to move log4j 1.3 to a branch
clearly marked abandoned and move log4j 1.2 back to trunk. I've had
seen issues previously when things have been moved around and the
previous snapshot has not reflected the move or subsequent changes.
If someone could blow
I do not believe it is a regression,but it was also broken on the old
vmgump. If you search the archives for log4net , the later entries
should describe the issue. If I remember correctly mono places a nant
( lower case no extension) on the path while gump invokes Nant.exe.
Either
Looks like the logging-log4j-receivers directory has the logging-
log4j-filters SVN content. Could someone delete that directory on
vmgump?
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: May 9, 2007 4:07:51 AM CDT
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Project
On Apr 29, 2007, at 3:39 PM, Bill Barker wrote:
Curt Arnold [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hope ApacheCON EU is starting well.
I've been getting suspicious nags from logging-log4j-component. The
behavior in the following message strongly suggests
Hope ApacheCON EU is starting well.
I've been getting suspicious nags from logging-log4j-component. The
behavior in the following message strongly suggests that the project
is trying to compile the wrong code base. The report looks just as I
would expect if
On Apr 24, 2007, at 1:39 PM, Stefan Bodewig wrote:
On Tue, 24 Apr 2007, Stefan Bodewig [EMAIL PROTECTED] wrote:
Which is a bug in the sync code IMHO.
Two sorts of bugs, ws-axis shows the other one.
I think we need to blow away the copy that Gump is working in, not
our checked out source
I inadvertently committed a symlink for a file in the logging-log4j-
component project's SVN. I corrected it in rev 531339 committed late
last night, but the subsequent Gump runs have had synchronization
errors. Could someone clear out the project working directory to
allow a fresh
I added project/logging-log4net.xml and updated profile/gump.xml
yesterday. The project is now attempted to build on both vmgump and
clarus and both fail with a message about NAnt.exe not being found.
I didn't expect the build to succeed since it will eventually fail
because it can't
On Feb 16, 2007, at 10:30 AM, Sander Temme wrote:
On Feb 16, 2007, at 7:46 AM, Gert Driesen wrote:
You either need a more recent version of Mono, or I could modify
NAnt to
allow it to compile on that version of Mono. I don't know if you'd
consider
using a nightly build (or any
On Feb 16, 2007, at 3:42 PM, Gert Driesen wrote:
Looking at the code that fails on Mono, it looks like the problem is
that Mono is detected as supporting .NET 2 but is missing a framework
method expected to be there.
NAnt by default targets that CLR on which its running, and it by
default
On Feb 16, 2007, at 7:09 PM, Curt Arnold wrote:
However, if you try to do nant or nant test, you will get a
failure that exec doesn't support the managed attribute. It
appears that the build file for NAnt requires features that are not
in NAnt 0.85. Removing the managed=true replaces
Going through the Incubator exit criteria for log4net and one of the
criteria was integrated with GUMP if appropriate. Thought it would
be a long shot, but quickly saw that Gump attempts but fails to build
NAnt and successfully builds dotnet-antlib. At least it appears
that the Mono
On Mar 18, 2006, at 3:52 AM, Gump Integration Build wrote:
To whom it may engage...
There have been no changes in the implementation or test in many many
months. The time of first failure appears to be the same as the time
that log4j started failing due to an Ant bug that occurs when
Any clues why this would break now? I didn't see any CVS commit
messages.
Also, it BCEL should be on the classpath for a Gump run, so it
shouldn't be necessary (or effective) to download BCEL.
On Mar 7, 2005, at 3:12 AM, Gump Integration Build wrote:
To whom it may engage...
AM, Stefan Bodewig wrote:
On Mon, 7 Mar 2005, Curt Arnold [EMAIL PROTECTED] wrote:
Any clues why this would break now?
Yes, there is no class VerifyDesignTest that javac could use. It
didn't compile outside of Gump either (before I fixed it ;-).
Stefan
Sorry, I inadvertently broke logging-log4j by removing its dependency
on jakarta-oro. I did not intend to commit that, however I was
surprised it failed since there is now a separate jar log4j-oro.jar
that I would have expected would contain all the oro dependent code.
I've modified the Gump
I'm so glad all that was logged and archived. Been a long day and I
didn't clue in that the address used in the nags was the mailing list
address. Thought it was some sort of pun on the military rank like
when General Gump says jump, you jump.
By the way, all of this was brought on by the
Oops, that would have been bad. I was trying to allow nags from
general@gump.apache.org to reach the log4cxx-dev mailing list.
However, my first attempt at mailing list administration almost routed
all the log4cxx-dev messages here. I'll try again not forgetting the
allow-subscribe and make
Sorry, posted to the wrong list. I meant to post this to
ant-contrib-developers to give them a heads up, not to
[EMAIL PROTECTED]
On Feb 2, 2005, at 1:37 AM, Curt Arnold wrote:
I took a shot at adding a Gump project to check for Ant 1.5
compatibility, but had not noticed that ant-1.5 itself
I took a shot at adding a Gump project to check for Ant 1.5
compatibility, but had not noticed that ant-1.5 itself had been removed
from the Gump. I assume it was done to try to conserve resources since
one of the machines ran out of disk space last week, so I was reluctant
to add it back.
This looks like an unintentional (or at least undiscussed) break due to
the packaging of log4j. I would discourage Cocoon from redirecting to
logging-log4j-12 until the log4j project has had a chance to discuss
the issue.
On Jan 20, 2005, at 6:43 AM, Stefan Bodewig wrote:
Hi all,
the Cocoon
Would there be any objections to attempting to create a logging-log4cxx
descriptor? The build might only assemble a source tar.gz, but if
there is a gcc on the box, we could use cpptasks to build log4cxx. I
would not expect to put the compilation products (libraries, etc) in
the Gump output
I had used the name of the XML file (jakarta-bcel), not the name of the
project (bcel). This has already been fixed and will hopefully build
on the next pass.
On Jan 10, 2005, at 4:10 AM, Gump Integration Build wrote:
To whom it may engage...
This is an automated request, but not an
I've made some committed changes to some long failing projects. I'm
not set up to actually test the changes, basically take a shot in the
dark and check the next morning if I hit anything.
ant-contrib-tests started failing around 8 Dec on the AntServerTest
with a broken pipe IOException. I
33 matches
Mail list logo
