What's happened to Gump?
You think the Gump environment has changed? Hmm, the JDK was upgraded
(within major release, not above) a short while ago. Other than that,
nothing ought have changed, AFAIK. Could this be a problem?
This was running ok previously.
So is this NullPointer bogus?
On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
*
A test Gump went rogue. I'll silence it, until it speaks the truth.
regards,
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
-
To unsubscribe, e-mail:
I am CCing [EMAIL PROTECTED], avalon-dev and commons-dev to elicit input
for this endeavor.
I'm no expert in this area, simply an external user (with no insights into
history/politics/whatever). That said, I'm not shy to provide my input...
I've loved logging (log4j, simple), I've hated
gump.xml is the descriptor generated by maven gump IIRC. Since
Gump's support for Maven as a build tool is rather new, there probably
is no automated way to generate a Gump descriptor from project.xml
yet.
We've asked the Maven folks not to change the 'gump' goal *yet* (to produce
maven
I looked into this wondering if somehow Gump had something 'stale' lying
around that caused it, but I see it is writing to an in-memory buffer
reading from same, so no (at least not there). Could there be some stray
class lying around that could be out sync? I find that hard to imagine,
but will
within build_ws-xmlrpc_ws-xmlrpc?
I do not see the compile error mentioned in the message below in the
page:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
s-
xmlrpc_ws-xmlrpc.html
Thank you,
Gary
-Original Message-
From: Adam R. B. Jack
Folks,
An interested compatibility issue has surfaced from this:
http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_ws-xmlrpc_ws-xmlrpc.html
/usr/local/gump/public/workspace/ws-xmlrpc/src/java/org/apache/xmlrpc/Defaul
tTypeFactory.java:133: exception
With some changes to log4j HEAD and the following patch to
commons-logging, it is now possible to compile commons-logging with
1.3alpha and run it with both 1.3 *and* 1.2.8.
Is it too late to ask if things in log4j could be put back to where they
were a week ago, while we work together for a
On the log4j we are making a very serious effort to keep everyone
happy.
And that is greatly appreciated. :)
I really wish you weren't having to go through this, I can hardly imagine
how frustrating it must be to maintain an old interface for two years,
attempting a clean deprecation, only run
What about the option of having commons-logging 1.0.3 and earlier work
with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do
whatever it feels like (since that's now possible with Ceki's recent
changes)?
I'm not gung ho about bending over backwards in order to not
remove an
BTW: I also wish folks had updated long ago, we'd have had a much smaller
transition, be having discovered this sooner.
I worded this poorly, and failed to get my point across. I meant ... I wish
projects had stopped using deprecated stuff a year ago, heck ... or two.
Progress has to be allowed
You guys stopped me in my tracks for a mo, and I am (in my time) trying to
get towards Gump w/ specific versions, but for here and now ...
If it ain't broke, don't fix it.
I can understand that for larger projects, but not for
infrastructure/wrappers like C-L. C-L, by it's nature, is sitting in
i've added some optional unit tests that give me confidence that a
version of commons-logging compiled against log4j CVS HEAD will run
against 1.2.7. it'd be a good idea to find a way for gump to run this
test (but i'm not too sure at the moment how to do this). i'll probably
add another
If so, the trick would be to run commons-logging unit tests separately
from
the compile, and run two of them with a dependency on logging-log4j and
logging-log4j-12.
something along those lines would probably work.
Basically depend upon C-L to get what you just built, and then set an
Version numbers
Together with deprecations this makes it easy (well sort of) to see
which piece of software that is a drop-in replacement and which will
require changes to your own code. In my book upgrading from 1.0.1 to
1.0.2 should be a walk in the park, but upgrading from 1.0 to 2.0
i'm very open to suggestions about the best way to structure the build
scripts.
You able to benefit from Ant 1.6 (or are they earlier?) selectors? Ant's own
build file uses them (along with available and such to do some pretty slick
conditional compilation.
regards,
Adam
Please ignore this, this is due to commons-logging not working against log4j
CVS HEAD, this is NOT a latka problem.
regards
Adam
- Original Message -
From: Ted Husted [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 17, 2004 7:01 PM
Subject: [EMAIL PROTECTED]:
I know logger know this better than I, but in case quick answer help w/
timezones...
i am more than a little confused about this whole issue. i've taken a
look in cvs and priority still seems to be in existence (and
undeprecated). when i looked at the gump record for sunday,
common-logging
I'm no expert on when to [or not to] cross post, but this looks like a good
topic for discussion in these two places at once.
regards
Adam
- Original Message -
From: Mario Ivankovits [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Monday, May 17, 2004 2:33
please take into account that most old hands on jakarta commons use
filtering extensively to ensure they have some time to do coding
(rather than just reading mailing lists). cross posts may well be filed
into low priority directories. unless the rules of the commons-dev
mailing list are
There is a convergence between the Gump Integration and this unstable
repository which I hope is occurring, eventually, we hope that Gump will
be used to produce a nightly build repository for projects, and that
most projects will start taking advantage of this Continuous Integration
for
* Is VFS still in a state of flux?
Well - quite some time not much happened in VFS - i picked it up now and
try to implement what ever comes in my head.
Awesome! As a long time user of VFS (first Ruper, now Depot), this is great
news. VFS is nicely done, and it'd be a real a shame to be
At this point I'm not sure what is correct. I only know that the efforts
up to this point are to enable gump to use maven to accomplish a nightly
build of a mavenized project, in which case you have an opportunity to
control some of the dependencies when your project is integrated via the
My impression was, GUMP always use the cvs-head to build the
dependencies - and fixing the dependency to a given release
is not the intention of GUMP.
From experience, I can tell you that I welcome the new ability to fix
certain dependencies. For example, the Avalon Project has made API
Gump has some of this already. It can use a CVS tag (or SVN branch)
of some module to allow this.
Which would work really well if Avalon had tagged their stuff prior to
complaints about why tagging is sort of vital, but all that we have are
the current jars. Not even the Avalon folks
Actually we don't differ at all. Once we have support for last good
builds or something similar in Gump, they can certainly live in a
ASF-format repository. And if pushing the created jars into
repository structure helps with anything we do, then go for it.
Actually, it does it today
From: Mario Ivankovits [EMAIL PROTECTED] wrote:
Just for the records - i already posted a patch, maybe a
logging-committer might pick it up
http://issues.apache.org/bugzilla/show_bug.cgi?id=28933
Excellent, thank you. I really hope one of the commons logging folks will
get to it today, and we
- Original Message -
From: Noel J. Bergman [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 4:44 PM
Subject: RE: [collections] new snapshot to ibiblio
I understand the desire to not having projects use snapshots, but the
reality
Made a change to get more log info from ant script. Will probably fail
again
tonight :-(
All I can see from here is the one failure unit test:
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-collections/gump_work/build_jakarta-commons_commons-collections.html
If you turn on
the site build.
Phil
Adam R. B. Jack wrote:
Mark,
Have you thought about enlisting the help of Gump for the manual effort
here? We are trying to allow Gump to be able to use Maven (instead of
Ant)
for projects that prefer builds this way. We are making progress
I have a vested interest in wanting VFS to be well tested (for Depot Ruper)
so I'm game to see this...
regards
Adam
- Original Message -
From: Noel J. Bergman [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, March 19, 2004 10:14
Hi,
This started failing a while back:
http://lsd.student.utwente.nl/gump/jakarta-turbine-stratum/gump_work/build_jakarta-turbine-stratum_jakarta-turbine-stratum.html#Output
[javac]
/data3/gump/jakarta-turbine-stratum/src/java/org/apache/stratum/component/Co
mponentLoader.java:217: cannot
ws-xmlrpc recently started failing to be Gumped against codec, see:
http://lsd.student.utwente.nl/gump/ws-xmlrpc/ws-xmlrpc.html
inside the build:
http://lsd.student.utwente.nl/gump/ws-xmlrpc/gump_work/build_ws-xmlrpc_ws-xmlrpc.html
stating:
[javac]
This is a proposal to begin to end the abuse of the sandbox. (The sandbox
was intended as a temporary 'play area' for new ideas, not a long term
project home)
This is a fascinating approach, and not unlike something that drove me
towards Gump in the first place. I was a heavy user of a common
It doesn't matter to Gump which you chose, the main thing is that if the
Gump descriptor for a project references a license filename, and that
filename is missing, it'll complain.
That has caught us on few LICENSE - LICENSE.txt changes recently.
regards
Adam
- Original Message -
From:
Ought this say interaction not http?
property name=final.name value=commons-jelly-tags-http-20031128/
http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-interaction.html
http://lsd.student.utwente.nl/gump/jelly-tags/work/list_commons-jelly-tags-interaction_dir1_target.html
Fixed in CVS, although I have to admit that I wasn't aware that gump was
building javadocs.
Yup, it is overkill. Somebody set the Gump descriptor to have an ant target
of 'dist'.
ant basedir=collections target=dist/
Could you suggest a target that only does compilation, and
Hi,
Could I trouble you guys to look this and tell me if this is a
commons-collections problem, or a Gump problem, or some combination?
This is from Python Gump:
http://gump.dotnot.org/jakarta-commons/commons-collections.html
Forgive me for jumping in with a comment, I have the interest if not the
experience (at least not of the rest of this thread.) I'm wondering ... is
the issue loading the local webapp's version of commons logging, or getting
to it's configuration? Assuming a robust/stable interface/implementation
You asked for opinions, here's mine...
There is no point maintaining broken stuff, it just leads to more real world
misery. Backwards compatible or not. I'd rather if it break at
compile/dynamic link time, not runtime (with broken stuff). I want a
ubiquitous HttpClient I can rely upon, and it
My single threaded user of VFS (an HttpClient user, that uses
MultiThreadedHttpConnectionManager) hangs [I suspect indefinitely] on minor
activity. I've turned on HttpClient debug and I see this, the last line
being the last thing I get...
2003/10/09 09:34:26:482 MDT [DEBUG] wire - -
Thanks, this works for me. I appreciate the patch.
regards
Adam
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 8:44 PM
Subject: cvs commit:
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient
Folks wrote:
[JRCS]
The obvious problem is that the project is becomming invisible, and in
so
few people are working on it.
It IS invisible, hence no one (ok, few people) knows it is here.
[Daemon]
I believe that now is the right time to reform the API since it seems
like no one(*) is
Stefan wrote:
Please note that there already is a commons-httpclient-2.0-branch
project in Gump's workspace. It would be trivial for projects to
depend on that branch instead of CVS HEAD and in fact jakarta-slide
and xml-rpc already do so.
Thanks, I'd not seen that.
However, most of my
Mike wrote:
I must disagree with you here. I responded to your bug report about 5
hours after you posted it. I was unable to reproduce this problem
given the details you have provided. If you have some more detail
about how to reproduce this problem, or perhaps a wire log, I would be
I will take your sample and attempt to reproduce it here. Unfortunately
(for
debugging this) I am using Commons VFS, which in turn uses HttpClient, so
maybe it is some usage/re-usage/configuration sequence that causes this. I
will see what I can do to reproduce.
I found the settings that VFS
I updated the bug database (I believe) so this is posted there.
FWIIW: I do not believe I am receiving e-mails from the bug tracker. Are
other folks? Did you get my update?
regards
Adam
-
To unsubscribe, e-mail: [EMAIL
Oleg wrote:
Adam, with all due respect let me point out that we have stable
HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API
and/or code stability. If GUMP cannot be configured to use any other CVS
branch but
HEAD, this is a totally different kind of a problem, and it
Oleg wrote:
We will be more than happy to play by the rules, as long as they are
clearly articulated and agreed upon, not just imposed upon us.
I completely agree, and like I said -- these aren't even mandatory rules
more here is how to play nicely w/ other Gumpers. I also agree it is upon
the
Folks, what was the outcome of this discussion?
From my perspective, it fizzled and died here. I logged a bug report on
HttpClient (on one crash I received) but I don't believe any action has
occurred. The Krysalis stack of projects still fail nightly on Gump with
VFS/HttpClient. Please see:
Mike wrote:
Yes, it looks like you are using HttpClient from HEAD. 2.0 code has
been moved into a branch and we've started 2.1 in HEAD. All unit
tests
are passing but HEAD contains essentially alpha code. If you are
looking for something stable I suggest 2.0. Mostly
A few more details/thoughts/questions:
1) The FSM appears to be using UrlFileObject although I have HttpClient in
my path. (This was when run from inside Eclipse and not command line, with
Eclipse project dependency upon HttpClient. With command line I get the
right one. Could this be some issue
can reproduce the
error and help sniff out a solution.
+jeff
-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 7:47 AM
To: [EMAIL PROTECTED]
Subject: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
A few more details
to run all unit test
before checking in.
Regards
Ortwin Glück
Adam R. B. Jack wrote:
5) Given all this, would it be possible for the two teams (VFS and
HttpClient) to add test projects to gump to augment the compile
projects? Meaning commons-httpclient-test and commons-vfs-test that
depend
to run all unit test
before checking in.
Regards
Ortwin Glück
Adam R. B. Jack wrote:
5) Given all this, would it be possible for the two teams (VFS and
HttpClient) to add test projects to gump to augment the compile
projects? Meaning commons-httpclient-test and commons-vfs-test that
depend
Over the last few days we've started to see runtime failures due to a crash
inside VFS.
An example is on the public gump (so using nightly from CVS) and it has
happened two nights in a row (at least).
http://cvs.apache.org/builds/gump/2003-08-20/krysalis-centipede-site.html
The crash is at:
--- Jeff Barrett [EMAIL PROTECTED] wrote:
[...]
- FileSystemException prints nested exceptions
instead of hiding them
Is this safe for JDK's earlier that JDK1.4? A quick
eyeball of the diff.txt makes me think otherwise.
regards,
Adam
=
--
Adam R. B. Jack
Should be. I'm using jdk 1.3.1. What did you see
that made you suspicious?
I assumes the inherited throwable member data was part
of JDK1.4 'cause' stuff. If you've tested it on JDK
1.3.1 great, and obviously not, so my bad.
regards
Adam
=
--
Adam R. B. Jack
tasks.
regards
Adam
=
--
Adam R. B. Jack
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
60 matches
Mail list logo
