[IMP] Releasing 2.1.7 on Tuesday

[Carsten Ziegeler]

Hi,

due to the infraton over the weekend where svn etc. will not be
available for some time, I'm planning to delay the release of 2.1.7 for
one day and release on tuesday instead of monday.
So we have the whole monday to do final work - if required.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

[Sylvain Wallez]

Linden H van der (MI) wrote:
Sylvain,
I think he means that adding "readonly='readonly'" as attribute to his
own  tag is passed through the styling XSL files. IIRC there
is a template that deals with extra attributes in the styling tag.
 

Ok. He can add whatever attribute to his styling, the stylesheets are 
built for this, but I don't want to see this "readonly" attribute 
handled in the stylesheets, as we have other mechanisms for this, namely 
widget states.

It's important to use widget states for this not only for consistency, 
but also because non-active (i.e. disabled/output/hidden) widget states 
instruct the widget not to read its value from the request, which would 
otherwise reset their value.

I am still missing something?
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Supported and unsupported blocks

[Reinhard Poetz]

Reinhard Poetz wrote:
Bertrand Delacretaz wrote:
Le 16 mars 05, à 19:11, Tim Larson a écrit :
...I do not need to discuss more, as Upayavira captured my thoughts
on the matter very well.  Since we do not have a vote thread
started yet, my *opinion* is +1 flat structure, -0 directories.
(i.e. Strongly prefer flat, but would not try to veto directories.)

Same here - I do actually prefer a flat structure, with enough 
metadata in block.xml (for example) to build a page with the status of 
each block. More flexible and easier to manage.

Reinhard, you put my name in the "people who support directories" list 
- I do support whatever valuable work is being done, and classifying 
blocks via directories is valuable IMHO. But given the choice I prefer 
the "flat" option.

First sorry for misinterpreting you. I also withdraw my proposal of 
putting blocks into a classifying directory structure (although I still 
think that the community status is *the* classifying property). I don't 
want to waste any further energy in this, as we have to do more 
important things.

If nobody stops me, I will put all blocks into 
/cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It 
will contain an element indicating the community status and for now 
*all* blocks get the status "committed". If somebody wants to see a 
block somewhere else, he needs to start a vote (and for this voting the 
wiki page will be very helpful ...)

So hopefully we can move on to some more productive work ;-)
Forgot to mention that I will wait with the move until after the infraton. So 
there is some time if there are still some arguments against the move ...

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Reinhard Poetz]

Bertrand Delacretaz wrote:
Le 16 mars 05, à 19:11, Tim Larson a écrit :
...I do not need to discuss more, as Upayavira captured my thoughts
on the matter very well.  Since we do not have a vote thread
started yet, my *opinion* is +1 flat structure, -0 directories.
(i.e. Strongly prefer flat, but would not try to veto directories.)

Same here - I do actually prefer a flat structure, with enough metadata 
in block.xml (for example) to build a page with the status of each 
block. More flexible and easier to manage.

Reinhard, you put my name in the "people who support directories" list - 
I do support whatever valuable work is being done, and classifying 
blocks via directories is valuable IMHO. But given the choice I prefer 
the "flat" option.
First sorry for misinterpreting you. I also withdraw my proposal of putting 
blocks into a classifying directory structure (although I still think that the 
community status is *the* classifying property). I don't want to waste any 
further energy in this, as we have to do more important things.

If nobody stops me, I will put all blocks into 
/cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It will 
contain an element indicating the community status and for now *all* blocks get 
the status "committed". If somebody wants to see a block somewhere else, he 
needs to start a vote (and for this voting the wiki page will be very helpful ...)

So hopefully we can move on to some more productive work ;-)
--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Bertrand Delacretaz]

Le 16 mars 05, à 19:11, Tim Larson a écrit :
...I do not need to discuss more, as Upayavira captured my thoughts
on the matter very well.  Since we do not have a vote thread
started yet, my *opinion* is +1 flat structure, -0 directories.
(i.e. Strongly prefer flat, but would not try to veto directories.)
Same here - I do actually prefer a flat structure, with enough metadata 
in block.xml (for example) to build a page with the status of each 
block. More flexible and easier to manage.

Reinhard, you put my name in the "people who support directories" list 
- I do support whatever valuable work is being done, and classifying 
blocks via directories is valuable IMHO. But given the choice I prefer 
the "flat" option.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Supported and unsupported blocks

[Bertrand Delacretaz]

Le 17 mars 05, à 01:56, David Crossley a écrit :
Reinhard Poetz wrote:
...The wiki page is only an indicator which should help us to decide 
to get an
answer on the community aspect which is one part of the answer which 
state
a block has (the others are interface stability, implementation 
stability
and available automated tests)
The things that disturb me are the name "supported" and the list of 
committers.
Perhaps we should remove that Wiki page once the "job" is done...
Agreed, associating people's names with blocks is useful at this 
decision stage but the page should vanish as soon as possible. Blocks 
are either supported *by the community* or not.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: Supported and unsupported blocks

[Reinhard Poetz]

David Crossley wrote:
Reinhard Poetz wrote:
Whenever I work as trainer or consultant and Cocoon is the subject, people 
always ask me the same questions about maturity and community of Cocoon and 
its blocks. We should tell our users clearly what *we* consider as 
"supported", "deprecated" and "committed" and then everybody can decide 
himself what he does with this information.

The wiki page is only an indicator which should help us to decide to get an 
answer on the community aspect which is one part of the answer which state 
a block has (the others are interface stability, implementation stability 
and available automated tests).

The things that disturb me are the name "supported" and the list of committers.
Perhaps we should remove that Wiki page once the "job" is done.
no problem as it's only a snapshop of March 2005.
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

[GUMP@brutus]: Project cocoon-block-template (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-template has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-template :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [template-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html
Work Name: build_cocoon_cocoon-block-template (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dbuild=build/cocoon-16032005 -Dblock-name=template 
gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/template/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/works

Re: Supported and unsupported blocks

[David Crossley]

Mark Leicester wrote:
> Hi Jeremy (et al),
> 
> Ahem... If someone is prepared to nominate me as a committer I'll 
> gladly support the midi block. :)

Hah, you and others like you have been on my radar for a long time
to invite as committers. Later.

However, your comment reinforces one of my points. We are creating
a problem for community development and user perception, by making it
look like only committers provide support. It should be the whole
dev community.

--David

Re: Supported and unsupported blocks

[David Crossley]

Reinhard Poetz wrote:
> 
> Whenever I work as trainer or consultant and Cocoon is the subject, people 
> always ask me the same questions about maturity and community of Cocoon and 
> its blocks. We should tell our users clearly what *we* consider as 
> "supported", "deprecated" and "committed" and then everybody can decide 
> himself what he does with this information.
> 
> The wiki page is only an indicator which should help us to decide to get an 
> answer on the community aspect which is one part of the answer which state 
> a block has (the others are interface stability, implementation stability 
> and available automated tests).

The things that disturb me are the name "supported" and the list of committers.
Perhaps we should remove that Wiki page once the "job" is done.

> Additionally I like Bertrands idea of a more verbose description of a block 
> status, that could be part of every block documentation (see 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111096531612907&w=2 for 
> details).

Agreed.

--David

Re: Supported and unsupported blocks

[Reinhard Poetz]

David Crossley wrote:
Jeremy Quinn wrote:
Don't get me wrong, I am happy you are being pro-active about this.
However, I see several items on the "unsupported" list which are IMHO 
important components of Cocoon, or are blocks that I use regularly in 
my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
others). In most cases, the fact that they do not currently have >2 
supporters does not effect their quality and usefulness.

On reviewing this list again, I see several blocks that I have worked 
on that I probably should have put my name to, and I notice several 
blocks that I know people actively care about, that they have not put 
their name to.

Maybe I misunderstand the purpose of having "supported" and 
"unsupported" blocks, but I would hate to useful work being sidelined 
by not attracting usage or new contributions.

Thanks for raising these issues. I wrote a similar mail but didn't
yet send it ...
I am concerned about the signals that this classification,
and listing of committers, sends for community-building.
Here are some random thoughts - sorry no time ...
Some blocks have no committers listed, e.g. midi, asciiart
However, they probably don't need much maintenance, so why would
they be listed as unsupported, or worse, moved offsite because it
appears that no-one cares.
I am not putting my name against any blocks, but that doesn't mean
that i won't help with them. Whenever i make some spare time
to attend to Bugzilla, i will work on patches for any block.
We try not to mention specific committers names. In fact, we voted
a while ago to remove author tags from code (but not yet done).
We really don't want to encourage the community to contact individuals.
Whenever I work as trainer or consultant and Cocoon is the subject, people 
always ask me the same questions about maturity and community of Cocoon and its 
blocks. We should tell our users clearly what *we* consider as "supported", 
"deprecated" and "committed" and then everybody can decide himself what he does 
with this information.

The wiki page is only an indicator which should help us to decide to get an 
answer on the community aspect which is one part of the answer which state a 
block has (the others are interface stability, implementation stability and 
available automated tests).

Additionally I like Bertrands idea of a more verbose description of a block 
status, that could be part of every block documentation (see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111096531612907&w=2 for details).

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Mark Leicester]

Hi Jeremy (et al),
Ahem... If someone is prepared to nominate me as a committer I'll 
gladly support the midi block. :)

I must admit I haven't had a lot of requests for MIDI block support 
since I cobbled it together back in 2003, and neither have I extended 
it in any of the ways that I thought I might. Nevertheless, I would 
like to see it survive as an example of how much fun Cocoon can be.

Thanks guys, for encouraging enthusiasts like me to create Cocoon 
blocks - of all sorts! Long may it continue.

BTW Jeremy, I always meant to thank you for this feedback. :)
> I just updated Cocoon, and took a wizz around the samples 
> In the MIDI section, I clicked on "A Short MIDI File", and it played 
in my browser =:-()
> I NEARLY DROPPED MY CHIPS !
> Well done!!!
(from http://www.mail-archive.com/dev@cocoon.apache.org/msg02395.html)

Take care everyone,
Mark
On 16 Mar 2005, at 23:19, David Crossley wrote:
Jeremy Quinn wrote:
Don't get me wrong, I am happy you are being pro-active about this.
However, I see several items on the "unsupported" list which are IMHO
important components of Cocoon, or are blocks that I use regularly in
my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and
others). In most cases, the fact that they do not currently have >2
supporters does not effect their quality and usefulness.
On reviewing this list again, I see several blocks that I have worked
on that I probably should have put my name to, and I notice several
blocks that I know people actively care about, that they have not put
their name to.
Maybe I misunderstand the purpose of having "supported" and
"unsupported" blocks, but I would hate to useful work being sidelined
by not attracting usage or new contributions.
Thanks for raising these issues. I wrote a similar mail but didn't
yet send it ...
I am concerned about the signals that this classification,
and listing of committers, sends for community-building.
Here are some random thoughts - sorry no time ...
Some blocks have no committers listed, e.g. midi, asciiart
However, they probably don't need much maintenance, so why would
they be listed as unsupported, or worse, moved offsite because it
appears that no-one cares.
I am not putting my name against any blocks, but that doesn't mean
that i won't help with them. Whenever i make some spare time
to attend to Bugzilla, i will work on patches for any block.
We try not to mention specific committers names. In fact, we voted
a while ago to remove author tags from code (but not yet done).
We really don't want to encourage the community to contact individuals.
--David

Re: Supported and unsupported blocks

[Ugo Cei]

Il giorno 16/mar/05, alle 14:21, Stefano Mazzocchi ha scritto:
Daniel Fagerstrom wrote:
If I have to choose between an abandoned one man show with full junit 
test support (whatever that means) and a block with an active 
community but no tests there would need to be *very* strong other 
advantages for the one man show, for me to even consider it.
If there is general consensus than a test suite can be more useful 
than a few individuals actually working on the code, we have a 
problem.
This looks much like a false dichotomy. If we have code with no active 
committers but a comprehensive test-suite, we have a problem but it's 
easier for newcomers to change it without fear of breaking it. If we 
have an active community but no tests, we have a problem but we can 
hope that of alll those people, someone will step up to write the 
tests. We should try to have both, not fight about which is better or 
worse.

Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/blojsom/blog/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/


smime.p7s
Description: S/MIME cryptographic signature

Re: Supported and unsupported blocks

[David Crossley]

Jeremy Quinn wrote:
> 
> Don't get me wrong, I am happy you are being pro-active about this.
> 
> However, I see several items on the "unsupported" list which are IMHO 
> important components of Cocoon, or are blocks that I use regularly in 
> my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
> others). In most cases, the fact that they do not currently have >2 
> supporters does not effect their quality and usefulness.
> 
> On reviewing this list again, I see several blocks that I have worked 
> on that I probably should have put my name to, and I notice several 
> blocks that I know people actively care about, that they have not put 
> their name to.
> 
> Maybe I misunderstand the purpose of having "supported" and 
> "unsupported" blocks, but I would hate to useful work being sidelined 
> by not attracting usage or new contributions.

Thanks for raising these issues. I wrote a similar mail but didn't
yet send it ...

I am concerned about the signals that this classification,
and listing of committers, sends for community-building.

Here are some random thoughts - sorry no time ...

Some blocks have no committers listed, e.g. midi, asciiart
However, they probably don't need much maintenance, so why would
they be listed as unsupported, or worse, moved offsite because it
appears that no-one cares.

I am not putting my name against any blocks, but that doesn't mean
that i won't help with them. Whenever i make some spare time
to attend to Bugzilla, i will work on patches for any block.

We try not to mention specific committers names. In fact, we voted
a while ago to remove author tags from code (but not yet done).
We really don't want to encourage the community to contact individuals.

--David

Re: Supported and unsupported blocks

[Reinhard Poetz]

Ralph Goers wrote:
Reinhard Poetz wrote:
This vote shows that at least one committer cares about the block (he 
calls for a vote) and he has to list good reasons why he thinks that 
it is stable (community, interfaces and implementation).

Of course we can group a several of votes into one voting process to 
avoid dozens of votings :-p

If you are speaking of current blocks, this is backwards.  Our policy is 
to require comments only on -1 votes.  Therefore, only blocks to be 
marked unstable would require justification.



What I meant was that the person calling for a vote has to list the reasons why 
he has the opinion that the status of a block has changed. If somebody starts a 
vote without explaining why a block has reached e.g. "supported", I would vote 
-1 and maybe I'm not the only one.

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Testers wanted for release 2.1.7

[Sylvain Wallez]

Folks,
We are in code freeze since monday to release Cocoon 2.1.7 next week and 
so far not much feedback has been given on the stability of the current 
code base.

The code freeze period should be for everybody the time to get the 
latest source tree of the 2.1 branch, either directly from SVN [1] or by 
downloading a snapshot [2] and go through the various samples, 
eventually testing with your own apps and report problems.

Please help us building a robust release.
Sylvain
[1] svn co http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/
[2] http://cvs.apache.org/snapshots/cocoon-2.1/
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: [cforms] Widget states in request-scoped forms

[Sylvain Wallez]

Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form 
object serializable and save the state in a hidden form field. 
The price to pay would be increased network traffic but the 
advantage of a stateless presentation layer wouldn't get lost. 
Hmmm the more I think about it the more I like this idea  wdot?



You should have a look at the XMLAdapter class in 
o.a.c.form.util. It does handles form 
serialization/deserialization in XML. AFAIK it doesn't keep 
state, but this could easily be added.



Thanks for the pointer! This should be very helpful, if I go this 
way.

Is there anything else that is necessary to _completly_ describe 
the state of a form, except the value and the "visibility state"? 
(events, validation errors, ...?)



Events are inherently transient (i.e. they are produced and 
consumed as part of the processing of a request). Validation errors 
are part of the global state of a form, as non-active widgets will 
loose their value and any validation as they don't read their value 
on the request.

You also have to include  in your form template 
so that the size of repeaters is transmitted back and forth as a 
hidden input.


ok, so we need following information to describe the state of a form:
 1. widget value
 2. widget visibility state
 3. validation errors
 4. repeater size

Yes, that should be ok.

Thinking further, the use of  isn't needed as this 
information will be part of the serialized state.

This means that I would have to enhance XMLAdapter to save this 
information too. Then I would extend the FormsTransformer to add a 
hidden input field that contains the compressed and encrypted XML.

Encrypted? Beware of security through obscurity, which is not a good 
solution, especially when the encryption/decryption code is 
opensource ;-)

yes, but if the encryption key is customizeable (e.g. in cocoon.xconf) 
this shouldn't be a problem

Ah, ok. That makes sense.
When the request comes back to the server, the controller checks for 
the hidden field and deserializes it.

By 'controller', do you mean FormSubmitAction?

for example, yes.

It would be cool to have a ready-to-run action in Cocoon for those 
situations where you cannot use flowscript.

Maybe this could be implemented as a new  template 
instruction.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: FW: Cocoon issue

[Sylvain Wallez]

Vadim Gritsenko wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Hi,
thanks for informing us about this possible issue - now, without the
concrete test case we can't do anything, we are searching for this
possible bug for a long time, but where never able to find it.
Please report your problems (together with the test case) to the cocoon
developer list. Then either we or any other Cocoon committer will help
you asap.

I'm not sure what are the two "Cocoon processes" below, but exactly 
same problem (Cocoon object was not re-entrant) was fixed for 
situation when Cocoon Portal invokes Cocoon JSR168Portlet. So it might 
be fixed in 2.1.6.

I encountered this problem in Cocoon application where we wanted to use 
the CocoonBean to produce the snapshot of a website as the result of an 
http request.

I guess this is what is meant by "two Cocoon processes": two Cocoon 
systems running in a single JVM and calling each other.

This problem has been fixed in 2.1.6.
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 25102] - RawRequestParameterModule don't work correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25102


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version||All




--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 22:45 ---
I have just encountered this bug.  I'll see if I can come up with a fix.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

Re: Supported and unsupported blocks

[Ralph Goers]

Reinhard Poetz wrote:
This vote shows that at least one committer cares about the block (he 
calls for a vote) and he has to list good reasons why he thinks that 
it is stable (community, interfaces and implementation).

Of course we can group a several of votes into one voting process to 
avoid dozens of votings :-p
If you are speaking of current blocks, this is backwards.  Our policy is 
to require comments only on -1 votes.  Therefore, only blocks to be 
marked unstable would require justification.

DO NOT REPLY [Bug 34044] New: - Exception during the running of a pipeline

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34044

   Summary: Exception during the running of a pipeline
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


ProcessingException("Environment stack has not been cleaned up properly. " +

  "Please report this (and if possible, 
together with a test case) " +

  "to the Cocoon developers.");

 

This is generated from CocoonComponentManager.checkEnvironment.  I am using 
Cocoon 2.1.4 in my application.

My case can be summarized as follows: I use one Cocoon process (call it 
Cocoon1) with one simple pipeline (a generator and a serializer).  In the 
serializer, I submit a cocoon.process(Environment env) to a total different 
Cocoon process (call it Cocoon2) with different sitemap (again one  simple 
pipeline with a generator and a serializer) and everything.  The exception 
occurred when the Cocoon2 is about to finish.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Gone live

[Ralph Goers]

I just thought I'd mention that the company I work for has just gone 
live with its first product using Cocoon.  While I can't say too much, 
you can view Digital Insight's press releases at 
http://www.digitalinsight.com/press_room/press_releases.html.

Ralph

DO NOT REPLY [Bug 34044] - Exception during the running of a pipeline

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34044





--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 20:40 ---
Created an attachment (id=14499)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14499&action=view)
The test case to duplicate the problem

The attached zip file contains the test case the problem I found.  The zip file
includes all the jar file that is necessary to run the batch file
(cocoontest.bat).  All the cocoon needed jars need to be included in the class
path since I can't attach a big zip file here.  The cocoontest.jar is my test
case jar.  Unjar it, you will see the source files.  There are two Cocoon
processes, using the sitemap.xmap in cocoon1 and cocoon2 directory,
respectively.  Each one of them includes a simple pipeline.  In the first one,
the generator is the file generator and the serializer is that one I wrote that
simply calls the second pipeline in cocoon2 at the endDocument method.  The
second pipeline has a file generator and xml serializer.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: FW: Cocoon issue

[Vadim Gritsenko]

From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 

Hi,
thanks for informing us about this possible issue - now, without the
concrete test case we can't do anything, we are searching for this
possible bug for a long time, but where never able to find it.
Please report your problems (together with the test case) to the cocoon
developer list. Then either we or any other Cocoon committer will help
you asap.
I'm not sure what are the two "Cocoon processes" below, but exactly same problem 
(Cocoon object was not re-entrant) was fixed for situation when Cocoon Portal 
invokes Cocoon JSR168Portlet. So it might be fixed in 2.1.6.

Vadim

Thanks
Carsten
Kaiyu Pan wrote:
I am e-mailing to you because I got the following exception:
ProcessingException("Environment stack has not been cleaned up
properly. " +
 "Please report this (and if
possible, together with a test case) " +
 "to the Cocoon
developers.");

This is generated from CocoonComponentManager.checkEnvironment.  I am
using Cocoon 2.1.4 in my application.  I am on a deadline now and I
will
try to come up with a simple test case when I get a chance.  My case
can
be summarized as follows: I use one Cocoon process (call it Cocoon1)
with one simple pipeline (a generator and a serializer).  In the
serializer, I submit a cocoon.process(Environment env) to a total
different Cocoon process (call it Cocoon2) with different sitemap
(again
one  simple pipeline with a generator and a serializer) and
everything. 

The exception occurred when the Cocoon2 is about to finish.

Thanks.

Kaiyu

FW: Cocoon issue

[Kaiyu Pan]

The attached gz file contains the test case the problem I found.  The
zip file includes all the jar files that are necessary to run the batch
file (cocoontest.bat).  All the jar files are built with cocoon-2.1.4
source.  The cocoontest.jar is my test case jar.  Unjar it, you will see
the source files.  There are two Cocoon processes, using the
sitemap.xmap in cocoon1 and cocoon2 directory, respectively.  Each one
of them includes a simple pipeline.  In the first one, the generator is
the file generator and the serializer is that one I wrote that simply
calls the second pipeline in cocoon2 at the endDocument method.  The
second pipeline has a file generator and xml serializer.

Kaiyu

-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 10, 2005 10:25 AM
To: Kaiyu Pan
Cc: [EMAIL PROTECTED]
Subject: Re: Cocoon issue

Hi,

thanks for informing us about this possible issue - now, without the
concrete test case we can't do anything, we are searching for this
possible bug for a long time, but where never able to find it.
Please report your problems (together with the test case) to the cocoon
developer list. Then either we or any other Cocoon committer will help
you asap.
Although you're on a tight schedule, I suggest to try the latest Cocoon
from subversion (2.1.7-dev) if you can reproduce the problem.

Thanks
Carsten

Kaiyu Pan wrote:
> I am e-mailing to you because I got the following exception:
> 
> ProcessingException("Environment stack has not been cleaned up
properly. " +
> 
>   "Please report this (and if
> possible, together with a test case) " +
> 
>   "to the Cocoon
developers.");
> 
>  
> 
> This is generated from CocoonComponentManager.checkEnvironment.  I am
> using Cocoon 2.1.4 in my application.  I am on a deadline now and I
will
> try to come up with a simple test case when I get a chance.  My case
can
> be summarized as follows: I use one Cocoon process (call it Cocoon1)
> with one simple pipeline (a generator and a serializer).  In the
> serializer, I submit a cocoon.process(Environment env) to a total
> different Cocoon process (call it Cocoon2) with different sitemap
(again
> one  simple pipeline with a generator and a serializer) and
everything. 
> The exception occurred when the Cocoon2 is about to finish.
> 
>  
> 
> Thanks.
> 
>  
> 
> Kaiyu
> 
>  
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Title: BLOCKED FILE ALERT
  BLOCKED FILE ALERT A file has been blocked due to the 'Blocked attachments' rule. See your system administrator for further information.  Context: 'cocoontest.bat' Disallowed due to filename Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeesecurity.com 

Re: Supported and unsupported blocks

[Peter Hunsberger]

On Wed, 16 Mar 2005 19:27:23 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Upayavira wrote:
> > Reinhard Poetz wrote:



> > It has been said that moving directories around is likely to cause
> > confusion - where has my block gone? etc.
> 
> That's FUD, the whole lifecycle contributed->supported->deprecated is
> likely to take many years (for the few blocks that go through all
> three). And each step is a sigificant step in the blocks life and
> important for the users and is certainly not based on a sudden whim from
> the community.

Personally, I don't think that's FUD.  No matter how long it takes for
a block to make the transition form one state to another the moment if
moves directories people are not going to know where it went.

If the block build process can automatically fetch my included blocks
no matter what directory they are located in then this a lot less of a
concern. Even then, people actually working on the block will have to
realize that block X moved and not keep working on "unstable/X" since
the version used by the build is now in "stable/X".  Only moving
blocks on release boundaries would help here, but I'm not sure it
removes the problem.

So, until we have automatic block retrieval I'd vote for a flat structure.



> >
> > The principal argument against putting blocks into directories is that
> > we cannot know now what is the most significant designation of a block.
> 
> We certainly know: community support is by far the most significant
> designation of a block.

A stable block that has worked for years and is never in need of
maintenance might be a very valuable contribution.  Such things could
fall through the cracks if all you measure is how many people are
working on a block.

-- 
Peter Hunsberger

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Upayavira wrote:
Reinhard Poetz wrote:
Can anyone of you explain to me why it should be harmful following the 
proposed directory structure? I understand that some of you think that 
it is useless for you, but some of us (Carsten, Daniel, Bertrand, I, 
and maybe some others) appreciate this information at directory level.
I personally prefer a flat structure.
We are following a flat structure for our documentation - there we have 
seen that hierarchies can be problematic on the source level.

But we can overlay heirearchies at a navigational level, and we can have 
multiple orthoganal hierarchies covering a set of items in the flat 
structure.
Community support is not another hierarchial level among thousands, it 
is *the currency* in open software development.

It has been said that moving directories around is likely to cause 
confusion - where has my block gone? etc.
That's FUD, the whole lifecycle contributed->supported->deprecated is 
likely to take many years (for the few blocks that go through all 
three). And each step is a sigificant step in the blocks life and 
important for the users and is certainly not based on a sudden whim from 
the community.

Build processes can read the meta info for a block and use it to both 
build documentation specifying which blocks are stable, verified, etc, 
and also package all stable blocks together, all contributed ones, all 
verified ones, or all blocks relating to a particular task, etc.

The principal argument against putting blocks into directories is that 
we cannot know now what is the most significant designation of a block.
We certainly know: community support is by far the most significant 
designation of a block.

/Daniel

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 12:11, Tim Larson dijo:
> On Wed, Mar 16, 2005 at 11:59:09AM -0600, Antonio Gallardo wrote:
>> On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
>> > Can anyone of you explain to me why it should be harmful following the
>> > proposed
>> > directory structure? I understand that some of you think that it is
>> > useless for
>> > you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some
>> others)
>> > appreciate this information at directory level.
>>
>> Upayavira already answered this.
>>
>> Lets start a vote? need we to discuss more the topic?
>
> I do not need to discuss more, as Upayavira captured my thoughts
> on the matter very well.  Since we do not have a vote thread
> started yet, my *opinion* is +1 flat structure, -0 directories.
> (i.e. Strongly prefer flat, but would not try to veto directories.)

Same here.

Best Regards,

Antonio Gallardo.
>
> --Tim Larson
>

Re: Supported and unsupported blocks

[Tim Larson]

On Wed, Mar 16, 2005 at 11:59:09AM -0600, Antonio Gallardo wrote:
> On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
> > Can anyone of you explain to me why it should be harmful following the
> > proposed
> > directory structure? I understand that some of you think that it is
> > useless for
> > you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others)
> > appreciate this information at directory level.
> 
> Upayavira already answered this.
> 
> Lets start a vote? need we to discuss more the topic?

I do not need to discuss more, as Upayavira captured my thoughts
on the matter very well.  Since we do not have a vote thread
started yet, my *opinion* is +1 flat structure, -0 directories.
(i.e. Strongly prefer flat, but would not try to veto directories.)

--Tim Larson

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo:
> Antonio Gallardo wrote:
>> On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
>>
>>>So, what about a simple "the majority wins"? wrt to the directory
>>>structure? We do a vote and whatever gets more voices will be done.
>>
>>
>> Good idea! Lets vote about this topic.
>
> Can anyone of you explain to me why it should be harmful following the
> proposed
> directory structure? I understand that some of you think that it is
> useless for
> you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others)
> appreciate this information at directory level.

Upayavira already answered this.

Lets start a vote? need we to discuss more the topic?

Best Regards,

Antonio Gallardo.

Re: Supported and unsupported blocks

[Upayavira]

Reinhard Poetz wrote:
Antonio Gallardo wrote:
On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
So, what about a simple "the majority wins"? wrt to the directory
structure? We do a vote and whatever gets more voices will be done.

Good idea! Lets vote about this topic.

Can anyone of you explain to me why it should be harmful following the 
proposed directory structure? I understand that some of you think that 
it is useless for you, but some of us (Carsten, Daniel, Bertrand, I, and 
maybe some others) appreciate this information at directory level.
I personally prefer a flat structure.
We are following a flat structure for our documentation - there we have 
seen that hierarchies can be problematic on the source level.

But we can overlay heirearchies at a navigational level, and we can have 
multiple orthoganal hierarchies covering a set of items in the flat 
structure.

It has been said that moving directories around is likely to cause 
confusion - where has my block gone? etc.

Build processes can read the meta info for a block and use it to both 
build documentation specifying which blocks are stable, verified, etc, 
and also package all stable blocks together, all contributed ones, all 
verified ones, or all blocks relating to a particular task, etc.

The principal argument against putting blocks into directories is that 
we cannot know now what is the most significant designation of a block.
Moving blocks into other directories is likely to be disruptive. Simply 
adding another line into the meta-data file isn't likely to be disruptive.

There's my thoughts. Does that help?
Regards, Upayavira

Re: Supported and unsupported blocks

[Reinhard Poetz]

Antonio Gallardo wrote:
On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
So, what about a simple "the majority wins"? wrt to the directory
structure? We do a vote and whatever gets more voices will be done.

Good idea! Lets vote about this topic.
Can anyone of you explain to me why it should be harmful following the proposed 
directory structure? I understand that some of you think that it is useless for 
you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others) 
appreciate this information at directory level.

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Reinhard Poetz]

Antonio Gallardo wrote:
On Mie, 16 de Marzo de 2005, 10:17, Daniel Fagerstrom dijo:
Everything can be done in numerous ways.
The directory structure is easy to understand, it is what we have
discussed at the list for quite a while, it is what Reinhard actually
have implemented and above all it moves us forward.
There should of course be a metadata file for the block as well and
documentation generated from that. But AFAIK no one have started to work
on any such documentation functinonallity. So for the moment I think we
should focus on the *important* question:
Which blocks do we support?

Well, this is a hard question. I read all the mails related to this topic
and still I don't have a decision:
1-"The blocks used for my company will be supported by me". I guess every
committer already did that. So I don't see here a problem, but.
2-"Blocks not used by 'me', but are interesting or have big potential
success". This is the hard question. How I can know if a block has
potential success between people?. Even we know that cocoon has potential,
but a lot of people don't use it. I hope this illustrate what I have in
mind.
In my case, in the first fill of the wiki Block poll, I added some blocks
that I don't need for my work and never used it, but I found interesting
and already worked on them just for fun. For example, qdox.
In the second raid, I checked other blocks where I already worked outside
my own interests, just for the community follwing some bugzilla reports
and I hope I can use some time in the future to support in this way again.
I know we have a problem, people wants to drops some blocks from his own
POV. But perhaps this blocks are used by other people.
I think this isn't that difficult. If someone wants a block being marked as 
"supported" he has to call for a vote. This vote has to be well-grounded:

-
[Vote] Community support for block xyz
We (committer1, committer2, committer3) are working on block xyz and consider it 
as stable. It provides support for bla, bla, bla, ... and comes with an 
extensive suite of test cases. The interfaces bla, bla, bla are stable and the 
implementation is stable as well and used in many projects.

[ ] mark block xyz as "supported"
[ ] block xyz isn't mature enough
Please cast your votes!
-
This vote shows that at least one committer cares about the block (he calls for 
a vote) and he has to list good reasons why he thinks that it is stable 
(community, interfaces and implementation).

Of course we can group a several of votes into one voting process to avoid 
dozens of votings :-p

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 10:17, Daniel Fagerstrom dijo:
> Everything can be done in numerous ways.
>
> The directory structure is easy to understand, it is what we have
> discussed at the list for quite a while, it is what Reinhard actually
> have implemented and above all it moves us forward.
>
> There should of course be a metadata file for the block as well and
> documentation generated from that. But AFAIK no one have started to work
> on any such documentation functinonallity. So for the moment I think we
> should focus on the *important* question:
>
> Which blocks do we support?

Well, this is a hard question. I read all the mails related to this topic
and still I don't have a decision:

1-"The blocks used for my company will be supported by me". I guess every
committer already did that. So I don't see here a problem, but.

2-"Blocks not used by 'me', but are interesting or have big potential
success". This is the hard question. How I can know if a block has
potential success between people?. Even we know that cocoon has potential,
but a lot of people don't use it. I hope this illustrate what I have in
mind.

In my case, in the first fill of the wiki Block poll, I added some blocks
that I don't need for my work and never used it, but I found interesting
and already worked on them just for fun. For example, qdox.

In the second raid, I checked other blocks where I already worked outside
my own interests, just for the community follwing some bugzilla reports
and I hope I can use some time in the future to support in this way again.

I know we have a problem, people wants to drops some blocks from his own
POV. But perhaps this blocks are used by other people.

Best Regards,

Antonio Gallardo.

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 10:15, Carsten Ziegeler dijo:
> So, what about a simple "the majority wins"? wrt to the directory
> structure? We do a vote and whatever gets more voices will be done.

Good idea! Lets vote about this topic.

Best Regards,

Antonio Gallardo

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Antonio Gallardo wrote:
On Mie, 16 de Marzo de 2005, 9:59, Daniel Fagerstrom dijo:
 


The proposed life cycle of block is rather:
* You get a cool new idea and create a contributed block.
* After a while it might have happened that a number of other developers
also have become interested in the block and have started to contribute.
At this point someone starts a vote about that the block should become a
supported block, and people agree.
* After some years it might happen that new technology or something else
makes the block less relevant and someone start a vote about deprecating
it.
   

The lifecycle was agreed for the community, the point is if a directory
structure is the best to implement it. Other people (me included) think it
can be implemented using the metadata file that all in all every block
will have.
 

Everything can be done in numerous ways.
The directory structure is easy to understand, it is what we have 
discussed at the list for quite a while, it is what Reinhard actually 
have implemented and above all it moves us forward.

There should of course be a metadata file for the block as well and 
documentation generated from that. But AFAIK no one have started to work 
on any such documentation functinonallity. So for the moment I think we 
should focus on the *important* question:

Which blocks do we support?
/Daniel

Re: Supported and unsupported blocks

[Carsten Ziegeler]

Ok, I think we can discuss this for ages. Some of us like to emphasize
the state of a block by an equal directory structure, some not.
I think we all agree, that the meta information about a block should
also contain this info.

So, what about a simple "the majority wins"? wrt to the directory
structure? We do a vote and whatever gets more voices will be done.

Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 9:59, Daniel Fagerstrom dijo:
> Antonio Gallardo wrote:
>
>>On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
>>
>>
> 
>
>>>Am I and Reinhard the only ones that are concerned about what the 50+
>>>blocks in an unordered lump in Cocoon does for the perception about our
>>>project?
>>>
>>>
>>
>>Well, I need to say I am not concerned. Playing with the directory
>>structure is not good. I can see in the future people mails:
>>
>> - O -
>>
>>mail: "I canot find the block 'X' in the 'supported' dir as is stated in
>>the mail 'Y'.
>>reply: "No it was noved to contributted lat week on the SVN"
>>re:reply: "It will be on the "resurected" block the next week
>>
>>
> You are exagerating quite a bit ;)

Yep. I know. But the mails will be there.

> The proposed life cycle of block is rather:
>
> * You get a cool new idea and create a contributed block.
> * After a while it might have happened that a number of other developers
> also have become interested in the block and have started to contribute.
> At this point someone starts a vote about that the block should become a
> supported block, and people agree.
> * After some years it might happen that new technology or something else
> makes the block less relevant and someone start a vote about deprecating
> it.

The lifecycle was agreed for the community, the point is if a directory
structure is the best to implement it. Other people (me included) think it
can be implemented using the metadata file that all in all every block
will have.

Best Regards,

Antonio Gallardo

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Antonio Gallardo wrote:
On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
 


Am I and Reinhard the only ones that are concerned about what the 50+
blocks in an unordered lump in Cocoon does for the perception about our
project?
   

Well, I need to say I am not concerned. Playing with the directory
structure is not good. I can see in the future people mails:
- O -
mail: "I canot find the block 'X' in the 'supported' dir as is stated in
the mail 'Y'.
reply: "No it was noved to contributted lat week on the SVN"
re:reply: "It will be on the "resurected" block the next week
 

You are exagerating quite a bit ;) The proposed life cycle of block is 
rather:

* You get a cool new idea and create a contributed block.
* After a while it might have happened that a number of other developers 
also have become interested in the block and have started to contribute. 
At this point someone starts a vote about that the block should become a 
supported block, and people agree.
* After some years it might happen that new technology or something else 
makes the block less relevant and someone start a vote about deprecating it.

/Daniel

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 8:41, Carsten Ziegeler dijo:
> Daniel Fagerstrom wrote:
>>
>> Can't we put the whiteboard code in the trunk as well and let the
>> compile script decide what should be included in the builds based on
>> meta data in the source files ;)
>>
>>--- o0o ---
>>
>> Am I and Reinhard the only ones that are concerned about what the 50+
>> blocks in an unordered lump in Cocoon does for the perception about our
>> project?
>>
>> If we stop whishful thinking and feeling pitty for blocks with few
>> supporters for a while, it is enough to take a look at the SVN log to
>> see that we have our share of more or less abandoned one man shows.
>> There are quite a few blocks that hasn't been touched in any essentail
>> way for a year or more. Blocks where all work have been done by one
>> person, that in some cases haven't been around for long. Blocks that
>> nearly never are discussed on the list.
>>
>> IMO it is an esential service for our users that we in a honest and
>> realistic way tell what we actually, in practicem, with real work,
>> support rather than what we whish we supported.
>>
> Hmm, I thought we already agreed on putting blocks in different
> directories to give a better overview about the state of a block - but
> perhaps that's my weak memory...

Nope. It shows that people mind evolve with the time. This raise often on
the mail list. One month "X" is cool and three months later is'not. Or the
oposite. ;-)

> Anyways, I think we should *not* put all blocks in one directory. Moving
> things with svn is painless.

Just because SVN allow it, does not mean we need to use this feature. ;-)

Best Regards,

Antonio Gallardo.

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 8:57, Carsten Ziegeler dijo:
> Vadim Gritsenko wrote:
>>
>> And I think nobody disagrees with that. Status page (suggested somewhere
>> up the
>> thread) indicating the status of the block, some additional information
>> about
>> the block, etc, will accomplish this even with flat directory structure
>> in SVN.
>>
>> What exactly changing directory structure buys you? If there is clear
>> and
>> structured documentation about the blocks (it can use structure like
>> supported/unsupported/contributed/abandoned/whatever) and similarly
>> structured
>> hierarchy in the sample webapp, what, on top of this, directory
>> structure in SVN
>> gives?
>>
>> I'm not so against moving stuff, but I'm just trying to understand why
>> to move.
>>
> Documenting the state is one thing, but imho just doing this in some
> descriptor isn't very visible. Who reads documentation or looks into a
> meta descriptor? :)
> So, by using a directory structure, it's immediately visible for everyone.

We can generate automatically a forrest page with this info in the same
sense as we generate now the ant build.xml for blocks. It will be pretty
easy to do. In short, this is not an argument for a directory structure.

Best Regards,

Antonio Gallardo.

Re: Supported and unsupported blocks

[Antonio Gallardo]

On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
> Vadim Gritsenko wrote:
>
>> Tim Larson wrote:
>>
>>> On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
>>>
 Vadim Gritsenko wrote:

> Reinhard Poetz wrote:
>
>> I propose to reflect these lifecycle-states in our SVN directory
>> structure.
>
>
>
> Why do you think directory structure is required here at all?
> What's wrong with plain list of all blocks in one directory?


 IIRC the idea was to give a quick overview of the current status.
 Having a list iwth 50+ blocks makes it more difficult.
>>>
>>>
>>>
>>> This overview can be accomplished in better ways than by inducing
>>> churn in the svn archive as projects change state.
>>
> Moving things in SVN is not that hard.
>
>>>
>>> Why not just make the current state of a block be reflected in its
>>> meta-data and then use this to generate documentation pages with
>>> separate lists of the groups of blocks in different states?
>>
>>
>> And we already have this for stable/unstable blocks - see
>> .../samples/blocks/.
>>
>> Vadim
>
> Can't we put the whiteboard code in the trunk as well and let the
> compile script decide what should be included in the builds based on
> meta data in the source files ;)
>
>--- o0o ---
>
> Am I and Reinhard the only ones that are concerned about what the 50+
> blocks in an unordered lump in Cocoon does for the perception about our
> project?

Well, I need to say I am not concerned. Playing with the directory
structure is not good. I can see in the future people mails:

 - O -

mail: "I canot find the block 'X' in the 'supported' dir as is stated in
the mail 'Y'.
reply: "No it was noved to contributted lat week on the SVN"
re:reply: "It will be on the "resurected" block the next week

- O -

And I don't see where is the real block deal when still they have a core
dependency with a cocoon directory structure. I think the "status" of the
block should be orthonal to the place where it is stored. What if we are
going to store some block on sourceforge? Where will be there the "right"
location, etc.

Block status should be included in a meta attributes file.

Best Regards,

Antonio Gallardo.

> If we stop whishful thinking and feeling pitty for blocks with few
> supporters for a while, it is enough to take a look at the SVN log to
> see that we have our share of more or less abandoned one man shows.
> There are quite a few blocks that hasn't been touched in any essentail
> way for a year or more. Blocks where all work have been done by one
> person, that in some cases haven't been around for long. Blocks that
> nearly never are discussed on the list.
>
> IMO it is an esential service for our users that we in a honest and
> realistic way tell what we actually, in practicem, with real work,
> support rather than what we whish we supported.
>
> /Daniel
>

Re: Supported and unsupported blocks

[Tim Larson]

On Wed, Mar 16, 2005 at 03:57:34PM +0100, Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
> > 
> > And I think nobody disagrees with that. Status page (suggested somewhere up 
> > the 
> > thread) indicating the status of the block, some additional information 
> > about 
> > the block, etc, will accomplish this even with flat directory structure in 
> > SVN.
> > 
> > What exactly changing directory structure buys you? If there is clear and 
> > structured documentation about the blocks (it can use structure like 
> > supported/unsupported/contributed/abandoned/whatever) and similarly 
> > structured 
> > hierarchy in the sample webapp, what, on top of this, directory structure 
> > in SVN 
> > gives?
> > 
> > I'm not so against moving stuff, but I'm just trying to understand why to 
> > move.
> > 
> Documenting the state is one thing, but imho just doing this in some
> descriptor isn't very visible. Who reads documentation or looks into a
> meta descriptor? :)
> So, by using a directory structure, it's immediately visible for everyone.

If the documentation is clear and easy to find and read, and the user
still does not bother to check it how are we going to give them any
help?  ...by also putting this documentation where they will read it,
embedded in the samples pages, just like the current stable/unstable
distinction.

FWIW, When I evaluate other projects I view distinction of modules
via directories with a grain of salt, because I know there is a higher
threshold (more inertia) to moving directories around to mantain
an accurate reflection of status than to just update a descriptor.

--Tim Larson

Re: Supported and unsupported blocks

[Tim Larson]

On Wed, Mar 16, 2005 at 09:41:37AM -0500, Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
> >IMO it is an esential service for our users that we in a honest and 
> >realistic way tell what we actually, in practicem, with real work, 
> >support rather than what we whish we supported.
> 
> And I think nobody disagrees with that. Status page (suggested somewhere up 
> the thread) indicating the status of the block, some additional information 
> about the block, etc, will accomplish this even with flat directory 
> structure in SVN.
> 
> What exactly changing directory structure buys you? If there is clear and 
> structured documentation about the blocks (it can use structure like 
> supported/unsupported/contributed/abandoned/whatever) and similarly 
> structured hierarchy in the sample webapp, what, on top of this, directory 
> structure in SVN gives?
> 
> I'm not so against moving stuff, but I'm just trying to understand why to 
> move.

I can live with dividing blocks up into directories and moving blocks
around occasionally if that is what we decide, but I have a hard time
understanding the reason for doing this, unless...
...are we dividing into separate directories so we can have separate
downloads, e.g. cocoon-core.tgz, cocoon-extras.tgz, etc.?  If so,
then perhaps the distinction should be made by what is commonly used
together, rather than by how supported, tested, etc. the components
are (with an exception for truly experimental, not really released code.)
Otherwise we are just creating more decisions to make when developing
and downloading while not saving ourselves or our users any bandwidth.

I think it is very important to create the types of distinctions between
blocks which we are talking about (level of support, liveliness of
development, degree of test coverage, etc.)  I just don't see the
benefit of doing this via division into directories.  Directories only
allow for one dimension of grouping, and as we already see we have
several orthogonal concerns along which there is a tension to create
a clear categorization.  Meta-data used to generate separate
documentation listings seems ideal for this usecase.

--Tim Larson

Re: Supported and unsupported blocks

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> 
> And I think nobody disagrees with that. Status page (suggested somewhere up 
> the 
> thread) indicating the status of the block, some additional information about 
> the block, etc, will accomplish this even with flat directory structure in 
> SVN.
> 
> What exactly changing directory structure buys you? If there is clear and 
> structured documentation about the blocks (it can use structure like 
> supported/unsupported/contributed/abandoned/whatever) and similarly 
> structured 
> hierarchy in the sample webapp, what, on top of this, directory structure in 
> SVN 
> gives?
> 
> I'm not so against moving stuff, but I'm just trying to understand why to 
> move.
> 
Documenting the state is one thing, but imho just doing this in some
descriptor isn't very visible. Who reads documentation or looks into a
meta descriptor? :)
So, by using a directory structure, it's immediately visible for everyone.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Supported and unsupported blocks

[Vadim Gritsenko]

Daniel Fagerstrom wrote:
IMO it is an esential service for our users that we in a honest and 
realistic way tell what we actually, in practicem, with real work, 
support rather than what we whish we supported.
And I think nobody disagrees with that. Status page (suggested somewhere up the 
thread) indicating the status of the block, some additional information about 
the block, etc, will accomplish this even with flat directory structure in SVN.

What exactly changing directory structure buys you? If there is clear and 
structured documentation about the blocks (it can use structure like 
supported/unsupported/contributed/abandoned/whatever) and similarly structured 
hierarchy in the sample webapp, what, on top of this, directory structure in SVN 
gives?

I'm not so against moving stuff, but I'm just trying to understand why to move.
Vadim

Re: Supported and unsupported blocks

[Carsten Ziegeler]

Daniel Fagerstrom wrote:
> 
> Can't we put the whiteboard code in the trunk as well and let the 
> compile script decide what should be included in the builds based on 
> meta data in the source files ;)
> 
>--- o0o ---
> 
> Am I and Reinhard the only ones that are concerned about what the 50+ 
> blocks in an unordered lump in Cocoon does for the perception about our 
> project?
> 
> If we stop whishful thinking and feeling pitty for blocks with few 
> supporters for a while, it is enough to take a look at the SVN log to 
> see that we have our share of more or less abandoned one man shows. 
> There are quite a few blocks that hasn't been touched in any essentail 
> way for a year or more. Blocks where all work have been done by one 
> person, that in some cases haven't been around for long. Blocks that 
> nearly never are discussed on the list.
> 
> IMO it is an esential service for our users that we in a honest and 
> realistic way tell what we actually, in practicem, with real work, 
> support rather than what we whish we supported.
> 
Hmm, I thought we already agreed on putting blocks in different
directories to give a better overview about the state of a block - but
perhaps that's my weak memory...

Anyways, I think we should *not* put all blocks in one directory. Moving
things with svn is painless.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Vadim Gritsenko wrote:
Tim Larson wrote:
On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I propose to reflect these lifecycle-states in our SVN directory 
structure.

Why do you think directory structure is required here at all? 
What's wrong with plain list of all blocks in one directory?

IIRC the idea was to give a quick overview of the current status. 
Having a list iwth 50+ blocks makes it more difficult.

This overview can be accomplished in better ways than by inducing
churn in the svn archive as projects change state.

Moving things in SVN is not that hard.
Why not just make the current state of a block be reflected in its
meta-data and then use this to generate documentation pages with
separate lists of the groups of blocks in different states?

And we already have this for stable/unstable blocks - see 
.../samples/blocks/.

Vadim
Can't we put the whiteboard code in the trunk as well and let the 
compile script decide what should be included in the builds based on 
meta data in the source files ;)

  --- o0o ---
Am I and Reinhard the only ones that are concerned about what the 50+ 
blocks in an unordered lump in Cocoon does for the perception about our 
project?

If we stop whishful thinking and feeling pitty for blocks with few 
supporters for a while, it is enough to take a look at the SVN log to 
see that we have our share of more or less abandoned one man shows. 
There are quite a few blocks that hasn't been touched in any essentail 
way for a year or more. Blocks where all work have been done by one 
person, that in some cases haven't been around for long. Blocks that 
nearly never are discussed on the list.

IMO it is an esential service for our users that we in a honest and 
realistic way tell what we actually, in practicem, with real work, 
support rather than what we whish we supported.

/Daniel

Re: Supported and unsupported blocks

[Vadim Gritsenko]

Tim Larson wrote:
On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I propose to reflect these lifecycle-states in our SVN directory 
structure.

Why do you think directory structure is required here at all? What's 
wrong with plain list of all blocks in one directory?
IIRC the idea was to give a quick overview of the current status. Having a 
list iwth 50+ blocks makes it more difficult.

This overview can be accomplished in better ways than by inducing
churn in the svn archive as projects change state.
Why not just make the current state of a block be reflected in its
meta-data and then use this to generate documentation pages with
separate lists of the groups of blocks in different states?
And we already have this for stable/unstable blocks - see 
.../samples/blocks/.
Vadim

Re: Supported and unsupported blocks

[Tim Larson]

On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
> >Reinhard Poetz wrote:
> >
> >>I propose to reflect these lifecycle-states in our SVN directory 
> >>structure.
> >
> >
> >Why do you think directory structure is required here at all? What's 
> >wrong with plain list of all blocks in one directory?
> 
> IIRC the idea was to give a quick overview of the current status. Having a 
> list iwth 50+ blocks makes it more difficult.

This overview can be accomplished in better ways than by inducing
churn in the svn archive as projects change state.

Why not just make the current state of a block be reflected in its
meta-data and then use this to generate documentation pages with
separate lists of the groups of blocks in different states?

--Tim Larson

Re: CForms: validation on binding (before submit)

[Luca Garulli]

I don't know if it can be useful, but you can use a client-side
validation for CForms:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32419

bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution

On Wed, 16 Mar 2005 14:22:34 +0100, BURGHARD Éric
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Is it possible to trigger the validate process just after a binding without
> submitting ? Let me explain.
> 
> We have a huge model with many validation rules. It's used by authentified
> users to edit/change their own data. Because it's huge we need to save the
> submitted data even if they are not valid.
> 
> When a user relog in (i assume he leaves the previous edition in an
> inconsistent state), he saw directly his form with the same error messages
> he had just before he left the editing process.
> 
> I can save data with errors by the mean of form.setBookmark, but after
> reloging i see my form/data without error msgs (i need to do a fake
> submit).
> 
> I quickly try to change v2/Form.js but without success.
> 
> Could someone point me to the direction to do that ?
> 
> thanks.
> 
> regards

CForms: validation on binding (before submit)

[BURGHARD Éric]

Hi,

Is it possible to trigger the validate process just after a binding without
submitting ? Let me explain.

We have a huge model with many validation rules. It's used by authentified
users to edit/change their own data. Because it's huge we need to save the
submitted data even if they are not valid.

When a user relog in (i assume he leaves the previous edition in an
inconsistent state), he saw directly his form with the same error messages
he had just before he left the editing process.

I can save data with errors by the mean of form.setBookmark, but after
reloging i see my form/data without error msgs (i need to do a fake
submit).

I quickly try to change v2/Form.js but without success.

Could someone point me to the direction to do that ?

thanks.

regards

Re: Supported and unsupported blocks

[Stefano Mazzocchi]

Daniel Fagerstrom wrote:
If I have to choose between an abandoned one man 
show with full junit test support (whatever that means) and a block with 
an active community but no tests there would need to be *very* strong 
other advantages for the one man show, for me to even consider it.
If there is general consensus than a test suite can be more useful than 
a few individuals actually working on the code, we have a problem.

--
Stefano.

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Torsten Curdt wrote:
It is useful for checking that we don't break anything
and also documents our learnings about what the code does. Starting to
write test code for allready existing code just because it "should be
tested" is more than "a lot of work" it is IMO pretty close to wasting
time.
   

May I now say... "Don't agree at all" ;)
It helps a lot(!) if you do refactoring.
How do you know whether it's working like
it was before? ...testing everything by hand?
...well, now that's what I would call a waste
of time ;)
 

If you reread the my message, you can see that we have about identical 
opinions about both why and that testing is  useful for refactoring. ;)

Also I believe that it is a very good idea to write new code in a test 
driven manner.

The point I wanted to make is that I don't think it is a good use of our 
effort to start adding tests to existing code *only* because we would 
like to approach 100% test coverage. It will mean that you write tests 
without have any spcific usecase for them. OTH when you refactor or do 
new development you know what parts you are going to change or what you 
want new functionality you want to achieve, this makes it much easier to 
write high quality test cases as you actually have a use for them.

So I think it is much better use of ones limited time to refactor parts 
that are hard to understand or have unclear communication patterns 
between components, and add test cases as a part of the job, than just 
add test cases in general.

/Daniel

Re: Supported and unsupported blocks

[Reinhard Poetz]

Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I propose to reflect these lifecycle-states in our SVN directory 
structure.

Why do you think directory structure is required here at all? What's 
wrong with plain list of all blocks in one directory?
IIRC the idea was to give a quick overview of the current status. Having a list 
iwth 50+ blocks makes it more difficult.

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Vadim Gritsenko]

Reinhard Poetz wrote:
I propose to reflect these lifecycle-states in our SVN directory 
structure.
Why do you think directory structure is required here at all? What's wrong with 
plain list of all blocks in one directory?

Vadim

[GUMP@brutus]: Project cocoon-block-paranoid (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-paranoid has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-paranoid :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-paranoid/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [paranoid-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-paranoid/gump_work/build_cocoon_cocoon-block-paranoid.html
Work Name: build_cocoon_cocoon-block-paranoid (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=paranoid gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gum

[GUMP@brutus]: Project cocoon-block-lucene (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-lucene has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-lucene :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-lucene/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [lucene-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-lucene/gump_work/build_cocoon_cocoon-block-lucene.html
Work Name: build_cocoon_cocoon-block-lucene (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=lucene gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/publ

[GUMP@brutus]: Project cocoon-block-asciiart (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-asciiart has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-asciiart :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-asciiart/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [asciiart-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-asciiart/gump_work/build_cocoon_cocoon-block-asciiart.html
Work Name: build_cocoon_cocoon-block-asciiart (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=asciiart gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/asciiart/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/asciiart/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdo

[GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-proxy has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-proxy :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [proxy-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/gump_work/build_cocoon_cocoon-block-proxy.html
Work Name: build_cocoon_cocoon-block-proxy (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=proxy gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/commons-httpclient-20-branch/dist/commons-httpclient-2.0-16032005.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/

[GUMP@brutus]: Project cocoon-block-javaflow (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-javaflow has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-javaflow :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-javaflow/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [javaflow-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-javaflow/gump_work/build_cocoon_cocoon-block-javaflow.html
Work Name: build_cocoon_cocoon-block-javaflow (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=javaflow gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr

[GUMP@brutus]: Project cocoon-block-axis (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-axis has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-axis :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-axis/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [axis-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-axis/gump_work/build_cocoon_cocoon-block-axis.html
Work Name: build_cocoon_cocoon-block-axis (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=axis gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-stx (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-stx has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-stx :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-stx/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [stx-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-stx/gump_work/build_cocoon_cocoon-block-stx.html
Work Name: build_cocoon_cocoon-block-stx (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=stx gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/avalon-trun

[GUMP@brutus]: Project cocoon-block-poi (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-poi has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-poi :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-poi/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [poi-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-poi/gump_work/build_cocoon_cocoon-block-poi.html
Work Name: build_cocoon_cocoon-block-poi (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=poi gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/avalon-trun

[GUMP@brutus]: Project cocoon-block-naming (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-naming has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-naming :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-naming/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [naming-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-naming/gump_work/build_cocoon_cocoon-block-naming.html
Work Name: build_cocoon_cocoon-block-naming (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=naming gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/publ

[GUMP@brutus]: Project cocoon-block-jsp (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-jsp has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-jsp :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jsp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [jsp-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jsp/gump_work/build_cocoon_cocoon-block-jsp.html
Work Name: build_cocoon_cocoon-block-jsp (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=jsp gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/jsp/mocks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velo

[GUMP@brutus]: Project cocoon-block-html (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-html has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-html :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [html-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-html/gump_work/build_cocoon_cocoon-block-html.html
Work Name: build_cocoon_cocoon-block-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=html gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-deli (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-deli has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-deli :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-deli/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [deli-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-deli/gump_work/build_cocoon_cocoon-block-deli.html
Work Name: build_cocoon_cocoon-block-deli (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=deli gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-bsf (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-bsf has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-bsf :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-bsf/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [bsf-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-bsf/gump_work/build_cocoon_cocoon-block-bsf.html
Work Name: build_cocoon_cocoon-block-bsf (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=bsf gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/avalon-trun

[GUMP@brutus]: Project cocoon-block-web3 (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-web3 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-web3 :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-web3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [web3-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-web3/gump_work/build_cocoon_cocoon-block-web3.html
Work Name: build_cocoon_cocoon-block-web3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=web3 gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/web3/mocks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jak

[GUMP@brutus]: Project cocoon-block-template (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-template has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-template :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [template-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html
Work Name: build_cocoon_cocoon-block-template (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=template gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/template/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/

[GUMP@brutus]: Project cocoon-block-slop (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-slop has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-slop :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-slop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [slop-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-slop/gump_work/build_cocoon_cocoon-block-slop.html
Work Name: build_cocoon_cocoon-block-slop (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=slop gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-serializers (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-serializers has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-serializers :  Java XML Framework


Full details are available at:

http://brutus.apache.org/gump/public/cocoon/cocoon-block-serializers/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [serializers-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-serializers/gump_work/build_cocoon_cocoon-block-serializers.html
Work Name: build_cocoon_cocoon-block-serializers (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=serializers 
gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/vel

[GUMP@brutus]: Project cocoon-block-qdox (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-qdox has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-qdox :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-qdox/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [qdox-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-qdox/gump_work/build_cocoon_cocoon-block-qdox.html
Work Name: build_cocoon_cocoon-block-qdox (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=qdox gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-profiler (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-profiler has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-profiler :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-profiler/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [profiler-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-profiler/gump_work/build_cocoon_cocoon-block-profiler.html
Work Name: build_cocoon_cocoon-block-profiler (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=profiler gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr

[GUMP@brutus]: Project cocoon-block-midi (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-midi has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-midi :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [midi-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html
Work Name: build_cocoon_cocoon-block-midi (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=midi gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-velocity (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-velocity has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-velocity :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-velocity/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [velocity-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-velocity/gump_work/build_cocoon_cocoon-block-velocity.html
Work Name: build_cocoon_cocoon-block-velocity (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=velocity gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr

[GUMP@brutus]: Project cocoon-block-linkrewriter (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-linkrewriter has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-linkrewriter :  Java XML Framework


Full details are available at:

http://brutus.apache.org/gump/public/cocoon/cocoon-block-linkrewriter/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [linkrewriter-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-linkrewriter/gump_work/build_cocoon_cocoon-block-linkrewriter.html
Work Name: build_cocoon_cocoon-block-linkrewriter (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=linkrewriter 
gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity

[GUMP@brutus]: Project cocoon-block-jfor (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-jfor has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-jfor :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jfor/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [jfor-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jfor/gump_work/build_cocoon_cocoon-block-jfor.html
Work Name: build_cocoon_cocoon-block-jfor (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=jfor gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/workspace/ava

[GUMP@brutus]: Project cocoon-block-itext (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-itext has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-itext :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-itext/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [itext-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-itext/gump_work/build_cocoon_cocoon-block-itext.html
Work Name: build_cocoon_cocoon-block-itext (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=itext gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/public/works

[GUMP@brutus]: Project cocoon-block-taglib (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-taglib has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-taglib :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-taglib/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [taglib-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-taglib/gump_work/build_cocoon_cocoon-block-taglib.html
Work Name: build_cocoon_cocoon-block-taglib (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=taglib gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-16032005.jar:/usr/local/gump/publ

[GUMP@brutus]: Project cocoon-block-chaperon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-chaperon has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-chaperon :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [chaperon-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/gump_work/build_cocoon_cocoon-block-chaperon.html
Work Name: build_cocoon_cocoon-block-chaperon (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=chaperon gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/chaperon/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/chaperon/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdo

[GUMP@brutus]: Project cocoon-block-batik (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-batik has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-batik :  Java XML Framework
- cocoon-block-fop :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-batik/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [batik-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-batik/gump_work/build_cocoon_cocoon-block-batik.html
Work Name: build_cocoon_cocoon-block-batik (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=batik gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-

[GUMP@brutus]: Project cocoon-block-session-fw (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-session-fw has an issue affecting its community 
integration.
This issue affects 2 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework


Full details are available at:

http://brutus.apache.org/gump/public/cocoon/cocoon-block-session-fw/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [session-fw-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-session-fw/gump_work/build_cocoon_cocoon-block-session-fw.html
Work Name: build_cocoon_cocoon-block-session-fw (Type: Build)
Work ended in a state of : Failed
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=session-fw gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-16032005.jar:/usr/lo

[GUMP@brutus]: Project cocoon-block-forms (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-forms has an issue affecting its community integration.
This issue affects 3 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-apples :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-tour :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [forms-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html
Work Name: build_cocoon_cocoon-block-forms (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=16032005 -Dblock-name=forms gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/forms/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/blocks/forms/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-16032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-16032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-16032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-16032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-16032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-16032005/checkstyle-16032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-16032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons

Re: Supported and unsupported blocks

[Torsten Curdt]

> It is useful for checking that we don't break anything
> and also documents our learnings about what the code does. Starting to
> write test code for allready existing code just because it "should be
> tested" is more than "a lot of work" it is IMO pretty close to wasting
> time.

May I now say... "Don't agree at all" ;)

It helps a lot(!) if you do refactoring.
How do you know whether it's working like
it was before? ...testing everything by hand?
...well, now that's what I would call a waste
of time ;)

cheers
--
Torsten


signature.asc
Description: OpenPGP digital signature

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34025


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34025


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34025


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [OT]MoonEdit collaborative editor

[Jorg Heymans]

Bertrand Delacretaz wrote:
Le 16 mars 05, à 11:12, Jorg Heymans a écrit :
...These tools would be a lot more useful if you could collaborate 
using drawings as well, sort of like a shared MSPaint session. I mean 
there are tools out there, but they are all in the multiple 1000EUR 
range.

Has anyone come accross anything affordable (apart from the 
VNC-MSPaint-Notepad combo) that gives this functionality ?..

Yes: Coccinella, http://hem.fyristorg.com/matben/
Last time I tested it it rocked.
Awesome tool, thanks for the tip!! My google searches must be getting 
weak :)

Jorg

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Reinhard Poetz wrote:
Bertrand Delacretaz wrote:
Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
...Remains the question: What shall we do with and call 
"unsupported/unverified" blocks?...

Why not put them in a "contributed" area? We'd make no guarantees 
about them (not even that they compile), and over time they might 
move elsewhere or be abandoned. More or less like the scratchpad of 
today.

The initial move would be to put as many blocks there as possible, 
and maybe move them back to "higher ground" later if there is actual 
support for them in the community.

My second search was more successful and I found 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2 
which already contains an excellent proposal by Stefano:

  +--(rebirth)-+
  v|
-(birth)-> [contributed] --(death)-> [deprecated]
  |^
  +--(maturity)-> [supported] --(retirement)---+

So we have following lifecycle states:
 - contributed
 - supported
 - deprecated
blocks.
The "verified" status could be orthogonal to these lifecycle-states 
and is an indicator of a (to be definded) block's quality (tested, 
stable interfaces, stable implementation, supported by community, ...)

Addtionally I like Betrands idea 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) 
of a narrative status description:

"Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."
I think we should provide some structure by providing a template that 
has some mandatory parts and a free text part.

 - o -
I propose to reflect these lifecycle-states in our SVN directory 
structure. Additionally we should add the directories "samples" and 
"core".

/cocoon/blocks/contributed
/cocoon/blocks/supported
/cocoon/blocks/deprecated
/cocoon/blocks/core
/cocoon/blocks/samples
Remains the question, where do "mini-apps" like the querybean fit in? 
In contrary to sample-blocks they have a lifecycle IMO. I'm not sure 
whether a distinction between "functional blocks" and "mini-apps" on 
SVN directory level really makes sense. For now I propose to put 
mini-apps into "contributed", "supported" or "deprecated" and if we 
get swamped with "mini-apps" we can find another solution if it is 
necessary.

WDOT?
+1
I agree about all of it. Contributed is more to the point than 
unsupported and doesn't have the negative conotation.

/Daniel

Re: [OT]MoonEdit collaborative editor

[Bertrand Delacretaz]

Le 16 mars 05, à 11:12, Jorg Heymans a écrit :
...These tools would be a lot more useful if you could collaborate 
using drawings as well, sort of like a shared MSPaint session. I mean 
there are tools out there, but they are all in the multiple 1000EUR 
range.

Has anyone come accross anything affordable (apart from the 
VNC-MSPaint-Notepad combo) that gives this functionality ?..
Yes: Coccinella, http://hem.fyristorg.com/matben/
Last time I tested it it rocked.
-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: auto-reloading of java classes

[Torsten Curdt]

Carsten Ziegeler wrote:
> I don't know which way is best, but whatever is done in this area,
> please make it configurable, so that all this checking can be turned off
> in production.

Of course :)

cheers
--
Torsten


signature.asc
Description: OpenPGP digital signature

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Torsten Curdt wrote:
...Where shall we draw the line between "supported" and
"unsupported"? Is it really the "two committers rule" that I applied
above?...
   

How about adding another condition: a block can only have "supported"
status if we have automated tests for all its critical functions?
 

That's a very interesting point.
+1, even if I'm not the most productive test writer :-)
   

This might make a big difference in the accountability of supported
stuff in our releases.
 

Yep. But this also means the core is currently unsupported ;-P
   

Hehe... Well, time to write some test then ;-P
Actually I somehow like the idea of required tests!
And it would also clearly draw the line. Much better
than the two-committer rule.
 

Don't agree at all ;) If I have to choose between an abandoned one man 
show with full junit test support (whatever that means) and a block with 
an active community but no tests there would need to be *very* strong 
other advantages for the one man show, for me to even consider it.

And take the >2 commiter rule as a starting point, if you want something 
to become supported, give us good reasons a start a vote.

...but a lot of work :-/
 

I agree that test driven programming is a an efficient and good way of 
developing code, and I have made good use of it in e.g. the JXTG 
refactoring. But as for everything else it is the quality of the tests 
that counts. It is far to easy to write tons of testing code that 
resembles the commenting style where you tell that "setFoo()" sets foo.

We should definively encourage our selves to write test code when we 
refactor things. It is useful for checking that we don't break anything 
and also documents our learnings about what the code does. Starting to 
write test code for allready existing code just because it "should be 
tested" is more than "a lot of work" it is IMO pretty close to wasting time.

/Daniel

Re: [OT]MoonEdit collaborative editor

[Jorg Heymans]

Rogier Peters wrote:
Some time ago there was a discussion about collaborative editors other than
SubEthaEdit which is OSX only. It seems that MoonEdit ( http://moonedit.com/ )
is a multiplatform SubEthaClone that does just that.
No Rendezvous autodiscovery, but it does have a server-mode to share a whole
directory at once. Not open source but free for non-commercial use.
These tools would be a lot more useful if you could collaborate using 
drawings as well, sort of like a shared MSPaint session. I mean there 
are tools out there, but they are all in the multiple 1000EUR range.

Has anyone come accross anything affordable (apart from the 
VNC-MSPaint-Notepad combo) that gives this functionality ?

Regards
Jorg

Re: auto-reloading of java classes

[Carsten Ziegeler]

I don't know which way is best, but whatever is done in this area,
please make it configurable, so that all this checking can be turned off
in production.

Carsten

Torsten Curdt wrote:
> I was just browsing the TreeProcessor code to
> see where to hook in the subscribe and unsubscribe
> to the fam notifications.
> 
> ...and I am wondering if it might make
> sense to change the sitemap reloading
> mechanism.
> 
> Right now we are checking the last-modified
> information for a sitemap.xconf change and
> reload if there is any change.
> 
> What we want now is to *also* reload if any
> of the files in the classpath has changed.
> ...which can be checked with a fam.
> 
> So either we could only subscribe the
> TreeProcessor for classpath changes notifications
> or let the fam check for the sitemap xconf as well.
> 
> Not sure. For n sitemaps the DelayedSource
> approach might be a bit more scaleable.
> Although I am not sure if thousands of
> sitemaps are really a real world scenario.
> 
> WDYGT?
> 
> As for the fam integeration: IIUC we could
> just add the subcribe to the SitemapLanguage
> where the ClassLoader is being created. The
> notification will then set a boolean we can
> check in TreeProcessor.buildConcreteProcessor()
> ...or did I miss something? ConcreteProcessor,
> ChildProcessor ...a lot of stuff in there :)
> 
> What I am still missing is a place the
> unsubscribe the classpath from the fam.
> 
> I also had a look into the current
> ClassLoaderFactory. It's Source-based
> while the fam in jci is file based :-/
> 
> ...I mean: we could come up with a Source-
> base fam. But not sure. Feels a bit like
> FS to support remote locations here.
> 
> WDYGT?
> 
> cheers
> --
> Torsten
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

auto-reloading of java classes

[Torsten Curdt]

I was just browsing the TreeProcessor code to
see where to hook in the subscribe and unsubscribe
to the fam notifications.

...and I am wondering if it might make
sense to change the sitemap reloading
mechanism.

Right now we are checking the last-modified
information for a sitemap.xconf change and
reload if there is any change.

What we want now is to *also* reload if any
of the files in the classpath has changed.
...which can be checked with a fam.

So either we could only subscribe the
TreeProcessor for classpath changes notifications
or let the fam check for the sitemap xconf as well.

Not sure. For n sitemaps the DelayedSource
approach might be a bit more scaleable.
Although I am not sure if thousands of
sitemaps are really a real world scenario.

WDYGT?

As for the fam integeration: IIUC we could
just add the subcribe to the SitemapLanguage
where the ClassLoader is being created. The
notification will then set a boolean we can
check in TreeProcessor.buildConcreteProcessor()
...or did I miss something? ConcreteProcessor,
ChildProcessor ...a lot of stuff in there :)

What I am still missing is a place the
unsubscribe the classpath from the fam.

I also had a look into the current
ClassLoaderFactory. It's Source-based
while the fam in jci is file based :-/

...I mean: we could come up with a Source-
base fam. But not sure. Feels a bit like
FS to support remote locations here.

WDYGT?

cheers
--
Torsten



signature.asc
Description: OpenPGP digital signature

Re: Supported and unsupported blocks

[Daniel Fagerstrom]

Jeremy Quinn wrote:
On 15 Mar 2005, at 09:14, Reinhard Poetz wrote:
Where shall we draw the line between "supported" and "unsupported"? 
Is it really the "two committers rule" that I applied above?

Don't get me wrong, I am happy you are being pro-active about this.
However, I see several items on the "unsupported" list which are IMHO 
important components of Cocoon, or are blocks that I use regularly in 
my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
others). In most cases, the fact that they do not currently have >2 
supporters does not effect their quality and usefulness.
It is not about quality and usefulness it is about the degree of 
community support.You probably remember Stefano's various discussions 
about open source dynamics. One of his main messages, as I understod it, 
is that "it's all about coomunity". Software that attracts community 
will sooner or later achieve high quality and usefulness and also adapt 
to changes in use patterns and development in the world outside, while 
software that don't attract community will not adapt to a changing world.

A common complaint about Cocoon is that it is "big, complicated, scary 
beast" 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110327845301789&w=2 and 
one of the reasons for that is the percieved lack of focus. For someone 
who hasn´t followed dev-list closely it can be quite hard to evaluate 
what Cocoon is and decide what parts that are safe bets to depend on.

Depending on a block that has support from some committers mean that you 
have much larger chance to get answers if you ask something and it also 
means that you have much larger chance to get your patches applied. In 
short community support it is a very important factor when you evaluate 
the techical risk in your project. IMO we should take responsibillity 
and give users an realistic idea about the actual level of community 
support.

Focus is about choosing and it might be painful, but giving the users 
the impression that everything is equally important is really to 
complicte life for them. And for us it mean unnecessry duplication of 
effort and no coherence in the result. Chosing CForms as the forms 
framework is an excelent illustration on what happens when one get from 
one man show to community support.

On reviewing this list again, I see several blocks that I have worked 
on that I probably should have put my name to,
You didin't.
and I notice several blocks that I know people actively care about, 
that they have not put their name to.

Maybe I misunderstand the purpose of having "supported" and 
"unsupported" blocks, but I would hate to useful work being sidelined 
by not attracting usage or new contributions.
That is of course a dissadvantage, but it should be compared to the 
frustration and lack of trust it creates for users to depend on blocks 
that are one man shows from people who not are around and support their 
work anymore.

   --- o0o ---
Taken togther IMO marking the block with >2 supporters as supported is a 
good and honest start. For the rest of the blocks, if anybody care 
enough it is just to motivate why the block should be marked as 
supported and start a vote about it.

/Daniel

Re: Supported and unsupported blocks

[Bertrand Delacretaz]

Le 16 mars 05, à 10:28, Reinhard Poetz a écrit :
...So we have following lifecycle states:

 - contributed
 - supported
 - deprecated
blocks.
+1
...The "verified" status could be orthogonal to these lifecycle-states 
and is an indicator of a (to be definded) block's quality (tested, 
stable interfaces, stable implementation, supported by community, 
...)..
+1
Addtionally I like Betrands idea 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) 
of a narrative status description:...
/me has no memory but the archives do ;-)
..."Yes - and maybe we shouldn't impose too much structure on this 
weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."

I think we should provide some structure by providing a template that 
has some mandatory parts and a free text part...
+1. One of the mandatory parts should be "automated tests coverage".
...I propose to reflect these lifecycle-states in our SVN directory 
structure. Additionally we should add the directories "samples" and 
"core".

/cocoon/blocks/contributed
/cocoon/blocks/supported
/cocoon/blocks/deprecated
/cocoon/blocks/core
/cocoon/blocks/samples
+1
...For now I propose to put mini-apps into "contributed", "supported" 
or "deprecated" and if we get swamped with "mini-apps" we can find 
another solution if it is necessary...
good enough, +1
WDOT?
Thanks for digging up this info, I'm all +1s as you can see, this looks 
good!

-Bertrand

smime.p7s
Description: S/MIME cryptographic signature

Re: Supported and unsupported blocks

[Reinhard Poetz]

Bertrand Delacretaz wrote:
Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
...Remains the question: What shall we do with and call 
"unsupported/unverified" blocks?...

Why not put them in a "contributed" area? We'd make no guarantees about 
them (not even that they compile), and over time they might move 
elsewhere or be abandoned. More or less like the scratchpad of today.

The initial move would be to put as many blocks there as possible, and 
maybe move them back to "higher ground" later if there is actual support 
for them in the community.
My second search was more successful and I found 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2 which 
already contains an excellent proposal by Stefano:

  +--(rebirth)-+
  v|
-(birth)-> [contributed] --(death)-> [deprecated]
  |^
  +--(maturity)-> [supported] --(retirement)---+

So we have following lifecycle states:
 - contributed
 - supported
 - deprecated
blocks.
The "verified" status could be orthogonal to these lifecycle-states and is an 
indicator of a (to be definded) block's quality (tested, stable interfaces, 
stable implementation, supported by community, ...)

Addtionally I like Betrands idea 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) of a 
narrative status description:

"Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."
I think we should provide some structure by providing a template that has some 
mandatory parts and a free text part.

 - o -
I propose to reflect these lifecycle-states in our SVN directory structure. 
Additionally we should add the directories "samples" and "core".

/cocoon/blocks/contributed
/cocoon/blocks/supported
/cocoon/blocks/deprecated
/cocoon/blocks/core
/cocoon/blocks/samples
Remains the question, where do "mini-apps" like the querybean fit in? In 
contrary to sample-blocks they have a lifecycle IMO. I'm not sure whether a 
distinction between "functional blocks" and "mini-apps" on SVN directory level 
really makes sense. For now I propose to put mini-apps into "contributed", 
"supported" or "deprecated" and if we get swamped with "mini-apps" we can find 
another solution if it is necessary.

WDOT?
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc