On Fri, 28 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> Considering the 'inactivity' of Phoenix. Could it be possible to
> permanent bring across its dependency and have them in some local
> location?
Yes.
I'll see whether I can find some time for this today.
Stefan
--
On Fri, 28 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> One thing is clear, 3.0 is GPL!
The good news is that excalibur-store doesn't compile against 3.0
either 8-)
> So, I have requested clarification from the source, and in the
> meantime I strongly suggest that we keep depending on 2
..
> [get]
> [get]
> -
>
>
>
>
> To subscribe to this information via syndicated feeds:
> RSS:
> http://brutus
ajack 2004/05/27 14:31:18
Modified:python/gump/document/xdocs documenter.py
..cvsignore
Log:
1) Cosmetic change.
2) .cvsignore _runlog.txt
Revision ChangesPath
1.9 +19 -18gump/python/gump/document/xdocs/documenter.py
Index: docum
> > RC3 doesn't seem so happy -- *as I installed it*. Do I need to run it
once
> > (online) or something? Any particular goal?
>
> Ok, assuming the answer is yes, I tried. Why does it want rc2 for rc3?
Some
> plugins need clearing out or something?
Gosh I hate it when I have public conversations
> RC3 doesn't seem so happy -- *as I installed it*. Do I need to run it once
> (online) or something? Any particular goal?
Ok, assuming the answer is yes, I tried. Why does it want rc2 for rc3? Some
plugins need clearing out or something?
regards
Adam
__ __
| \/ |__ _Apache__ ___
| |\/| / _
> > > > Also, RC3 is out... Might want to upgrade :)
>
> Done (on brutus).
>
Brett,
RC3 doesn't seem so happy -- *as I installed it*. Do I need to run it once
(online) or something? Any particular goal?
http://brutus.apache.org:8080/gump/apache-gump-test/gump-test-maven1/gump_work/build_apache
On Thursday 27 May 2004 22:50, Stefan Bodewig wrote:
> On Thu, 27 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> > This is the previous project descriptor in Cocoon.
>
> Will be in rather soon.
>
> >
>
> I took the liberty to pick up the latest release instead ;-)
>
> BTW, whoever depen
ajack 2004/05/27 09:47:52
Modified:python/gump/document documenter.py
Log:
Allow prepareRun to be optional (e.g. for TextDocumenter)
Revision ChangesPath
1.17 +2 -2 gump/python/gump/document/documenter.py
Index: documenter.py
===
On Thursday 27 May 2004 22:50, Stefan Bodewig wrote:
> BTW, whoever depends on jisp in excalibur should take a look at jisp's
> license. GPL, not even the lesser/library one. Aparantly older
> versions have been under a different license, but I fail to locate
> either an older version or its lic
> Note: Since gumpy.py is running when it calls CVS to update Gump itself,
> this is the one file that doesn't get automatically updated from CVS. I'll
> manually update it on Brutus (and others if/when I get time).
Ah. This used to be the case when we used gumpy.sh to do the cvs update, but
since
bodewig 2004/05/27 07:51:56
Modified:profile gump.xml
Added: project jisp.xml
Log:
Install jisp
Revision ChangesPath
1.345 +2 -0 gump/profile/gump.xml
Index: gump.xml
===
RCS file:
On Thu, 27 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> This is the previous project descriptor in Cocoon.
Will be in rather soon.
>
I took the liberty to pick up the latest release instead ;-)
BTW, whoever depends on jisp in excalibur should take a look at jisp's
license. GPL,
ajack 2004/05/27 07:35:28
Modified:.gumpy.py
python/gump/utils __init__.py
python/gump/document/xdocs documenter.py
Log:
1) Added runlog
2) Modified 'run details' page to show start and end date/time
3) Re-organized 'run details' page to
I have doubts/concerns about the reliability of Brutus' cron, and/or the
length of runs on Brutus, or both. I've added a runlog to gumpy.py that
simply stores (1) local date/time (2) PID (3) message. Hopefully this will
grant us some insights.
27 May 04 08:13:19 : 3044 : Gump Start-up. Arguments [
On Thursday 27 May 2004 21:47, Stefan Bodewig wrote:
> On Thu, 27 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> > Ok... What do we do about it? Avalon Excalibur Store (not actively
> > developed) and James(?) depends on it.
>
> Turn it into an installed package.
>
> Where can I find it?
T
The solution to this curious problem was to directly implement the
DefaultHandler.resolveEntity functionality which is simply to return
null. Trying to be OO and calling DefaultHandler.resolveEntity can
quickly develop to become a monstrous headache as the signature of
DefaultHandler.resolveEntity
On Thu, 27 May 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> Ok... What do we do about it? Avalon Excalibur Store (not actively
> developed) and James(?) depends on it.
Turn it into an installed package.
Where can I find it?
Stefan
-
On Thursday 27 May 2004 20:49, Adam R. B. Jack wrote:
> Seems they removed it:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/gump.xml
> It existed here:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/gump.xml?rev=1.155&view=markup
Ok... What do we do about it?
Avalon Excalibur Store (not act
On Thursday 27 May 2004 20:36, Adam R. B. Jack wrote:
> > > get-mx4j:
> > > [mkdir] Created dir:
> > > /usr/local/gump/public/workspace/avalon-phoenix/lib/repo/mx4j [get]
> > > Getting:
>
> http://telia.dl.sourceforge.net/sourceforge/mx4j/mx4j-1.1.1.tar.gz
>
> > > [get]
Ryan,
Thanks, nice research/write up. [I am copying Gump to keep a centralized
archive, and I'll try to post a blog entry once complete.]
So, theoretically the new code will still run against codec 1.12 (no
signatures have explicitly changed), it just won't compile against it (seems
reasonable).
Folks,
I'm taking a long weekend down in Santa Fe (never been there, excited to go,
dead happy to get away) so I won't be reading/responding to any mail. I'd
really appreciate it if folks could:
1) Act as Gumpmeisters (we need more of these) and help folks when needed.
2) Keep an eye on Brutus.
> I have no clue how this can happen.
> AbstractLogEnabled is possibly the most used class in Avalon, and is part
of
> avalon-framework.api.jar (in classpath), and yet Javac fails.
When you mark a dependency as optional, and it fails to build, the dependee
still gets built. As such, it ought be op
> On Thursday 27 May 2004 04:39, Gump Integration Build wrote:
>
> > -ERROR- Bad Dependency. Project: jisp unknown to *this* workspace
>
> We have not changed the code nor the gump descriptor.
> What happened to Jisp ?
Seems it existed as a projects within the Cocoon descriptor, they were
bring
>> I don't know if it hanged, the built timeout has been shortened or
>> what is really happening here.
possibly just some kind of network problem - wouldn't the first time,
in particular with SF.net on the other side.
On Thu, 27 May 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> so only Gum
> > get-mx4j:
> > [mkdir] Created dir:
> > /usr/local/gump/public/workspace/avalon-phoenix/lib/repo/mx4j [get]
> > Getting:
http://telia.dl.sourceforge.net/sourceforge/mx4j/mx4j-1.1.1.tar.gz
> > [get]
> > [get] .
> Which version of the org.xml.sax package is used on brutus? I am a bit
> at a loss here.
The very latest (CVS HEAD) of xerces.
http://brutus.apache.org:8080/gump/logging-log4j/logging-log4j/details.html#Boot+Classpath
This issue is seeming vaguely familiar -- I think somebody else hit it
befor
Problem solved. It appears that the org.xml.sax classes included in
the JDK differ from those of the original.
Dancing around the discrepancy is not too difficult once you know that
it exists. Thanks to gump for pointing out the difference.
How inconsiderate on the part of Sun to modify an existing
Hello all,
It appears that log4j is failing to compile on brutus. It compiles
fine on my side using JDK 1.4, 1.3 or 1.2. The problem appears to be
linked to the signature of the resolveEntity() method in
org.xml.sax.helpers.DefaultHandler. Contrary to what is declared by
the resolveEntity method in
There is a problem with the run at : CSI14:CSI14.xml
The log ought be at:
/gumpy_log.txt
The last (up to) 50 lines of the log are :
- GUMP run in env:
TMP -> [C:\D
30 matches
Mail list logo
