You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/03/19 16:29:20 UTC
Planning 2.1B1
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
Thanks
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
Re: Planning 2.1B1
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>
>
>>Could please everyone add (his) open issues for a 2.1b1 release
>>to the todo.docs? So, we have one single source of information.
>
>
> "b" implies beta... We go straight to beta without an alpha???
yes, we have never released alpha code. There is a CVS for that.
Stefano.
Re: Planning 2.1B1
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>>
>> "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>>
>>> Could please everyone add (his) open issues for a 2.1b1 release
>>> to the todo.docs? So, we have one single source of information.
>>
>> "b" implies beta... We go straight to beta without an alpha???
>>
> Not necessary. I only want a todo list for a beta release. We
> can make an alpha version at any time - if required.
Ah! +1 :-) I'll think about it later tonight after work...
> In addition, my perception during some recent threads was, that an
> alpha version is not required and I think Stefano suggested this as
> well - but I might be mistaken.
That could well be a first in Apache history... Beta without alphas...
I feel so old and conservative :-) :-) :-)
Pier
RE: Planning 2.1B1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>
> > Could please everyone add (his) open issues for a 2.1b1 release
> > to the todo.docs? So, we have one single source of information.
>
> "b" implies beta... We go straight to beta without an alpha???
>
Not necessary. I only want a todo list for a beta release. We
can make an alpha version at any time - if required.
In addition, my perception during some recent threads was, that an
alpha version is not required and I think Stefano suggested this as
well - but I might be mistaken.
Anyway, when we have a list, I planned to make a short poll about
it.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
Re: Planning 2.1B1
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> Could please everyone add (his) open issues for a 2.1b1 release
> to the todo.docs? So, we have one single source of information.
"b" implies beta... We go straight to beta without an alpha???
Pier
AbstractMethodError: org/apache/excalibur/event/impl/AbstractQueue.enqueue
Posted by Upayavira <uv...@upaya.co.uk>.
The CLI works fine from the batch file, but gives an exception when I run it from in
IDEA. I've done what I remember to be the usual: build clean, checking I've got all the
latest jars in my classpath. Any ideas what might be causing the following exception?
java.lang.AbstractMethodError:
org/apache/excalibur/event/impl/AbstractQueue.enqueue
at
org.apache.excalibur.event.command.AbstractThreadManager$PipelineRunner.run(A
bstractThreadManager.java:310)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:
727)
at java.lang.Thread.run(Thread.java:479)
java.lang.AbstractMethodError:
org/apache/excalibur/event/impl/AbstractQueue.enqueue
at
org.apache.excalibur.event.command.AbstractThreadManager$PipelineRunner.run(A
bstractThreadManager.java:310)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:
727)
at java.lang.Thread.run(Thread.java:479)
java.lang.AbstractMethodError:
org/apache/excalibur/event/impl/AbstractQueue.enqueue
at
org.apache.excalibur.event.command.AbstractThreadManager$PipelineRunner.run(A
bstractThreadManager.java:310)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:
727)
at java.lang.Thread.run(Thread.java:479)
java.lang.AbstractMethodError:
org/apache/excalibur/event/impl/AbstractQueue.enqueue
at
org.apache.excalibur.event.command.AbstractThreadManager$PipelineRunner.run(A
bstractThreadManager.java:310)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:
727)
at java.lang.Thread.run(Thread.java:479)
java.lang.NoSuchMethodError:
org.apache.avalon.excalibur.component.ComponentHandler: method initialize()V not
found
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(Excal
iburComponentManager.java:555)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:323)
at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:213)
at org.apache.cocoon.Main.main(Main.java:409)
java.lang.AbstractMethodError:
org/apache/excalibur/event/impl/AbstractQueue.enqueue
at
org.apache.excalibur.event.command.AbstractThreadManager$PipelineRunner.run(A
bstractThreadManager.java:310)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:
727)
at java.lang.Thread.run(Thread.java:479)
Re: Planning 2.1B1
Posted by Upayavira <uv...@upaya.co.uk>.
On 20 Mar 2003 at 17:28, Nicola Ken Barozzi wrote:
> What about working to fix the errors I get in the faster CLI...
I have every intention of checking that out, just haven't had a chance yet.
> > I'm prepared to work on both, and have ideas...
> We know you do, your contributions are always very interesting and
> well accepted :-D
Rest assured, I won't work on my suggested ideas until I've dealt with the problem
you relate - I was just wanting to make my concerns/wishes public, that's all.
Regards, Upayavira
RE: Planning 2.1B1
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
> >Could please everyone add (his) open issues for a 2.1b1 release
> >to the todo.docs? So, we have one single source of information.
> >
> Has everyone updated the todo.xml? Is anything missing?
I have suggested that I would like to add two things:
* the CLI working within the binary distribution
* the CocoonBean (and hence CLI) using ModifiableSources rather than its
own Destination objects.
But cannot add them to todo.xml. I don't know if people consider them sufficiently
important to go into 2.1b.
Regards, Upayavira
RE: Planning 2.1B1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Carsten Ziegeler wrote:
>
>Could please everyone add (his) open issues for a 2.1b1 release
>to the todo.docs? So, we have one single source of information.
>
Has everyone updated the todo.xml? Is anything missing?
Carsten
Re: Planning 2.1B1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote, On 20/03/2003 15.15:
> Carsten Ziegeler wrote:
>
>>Could please everyone add (his) open issues for a 2.1b1 release
>>to the todo.docs? So, we have one single source of information.
>
> There are two things I would like to see in 2.1beta:
> * the CLI working within the binary distribution
> * the CocoonBean (and hence CLI) using ModifiableSources rather than its own
> Destination objects
What about working to fix the errors I get in the faster CLI...
Change the attribute about it in cli.xconf and run 'build docs', you
will see the errors.
...
> I'm prepared to work on both, and have ideas...
We know you do, your contributions are always very interesting and well
accepted :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Planning 2.1B1
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
> Could please everyone add (his) open issues for a 2.1b1 release
> to the todo.docs? So, we have one single source of information.
There are two things I would like to see in 2.1beta:
* the CLI working within the binary distribution
* the CocoonBean (and hence CLI) using ModifiableSources rather than its own
Destination objects.
First is more important than second and would presumably be done as a part of
making Jetty work in the binary distrubutioni.
The second would make the CLI a lot more powerful (CLI can write to anything for
which there is a ModifiableSource), and if people agree that this is a good idea,
then it is worth doing before release, as afterwards we'd need to honour the
'Destination' interface.
I'm prepared to work on both, and have ideas...
Regards, Upayavira