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 2004/04/28 09:55:51 UTC
Planning the 2.1.5 release
It's time to think about the next release. As far as I can see there
are currently no real showstoppers.
So, is there something that we should do for the 2.1.5 release?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
Re: OOME on building serializers block (was Re: Planning the 2.1.5 release)
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On 30 Apr 2004, at 19:30, Pier Fumagalli wrote:
> PS. "GIZA" comes from Jeremy... Spending too much time w/ that guy
> lately! :-P
I think you mean "geezer" or "geeza" ;-) ... see
http://www.peevish.co.uk/slang/g.htm
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
Re: OOME on building serializers block (was Re: Planning the 2.1.5 release)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 30 Apr 2004, at 08:07, Marc Portier wrote:
> Joerg Heinicke wrote:
>
>> On 29.04.2004 19:48, Pier Fumagalli wrote:
>>>> There is a problem with the new serializers block. From the
>>>> developers I seem to
>>>> be the only one having problems [1], but today this issue was also
>>>> raised by two
>>>> persons on the users list [2]. Imagine what happens if this is
>>>> released as it is!
>>>
>>> I seriously suspect that it breaks because of memory leaks in JavaC
>> Might be.
>>> when doing a full cocoon build, from the beginning with a lot of
>>> blocks enabled.
>> I tested it with only the serializers block enabled:
>> OutOfMemoryError. While I can build Cocoon with all blocks enabled
>> except serializers block.
>
> same here
>
>> Something special must be about this block's sources, maybe the huge
>> arrays.
>>> I'm sure that if that block could be built easily if the "javac"
>>> task "fork" attribute can be set to true...
>> This might work for the build system, but not for Eclipse or other
>> IDEs.
>
> well, I just modify the project/properties in eclipse and throw away
> the block sources from the build path... that just works
>
> would be nice though if we had a version of the 'eclipse-project'
> target that would do it for me by taking into account the
> local.blocks.properties (hey, was that a hint?)
Unfortunately I'm not one of the few poor "giza"(s) using Eclipse, so,
got no clue of what you're talking about... :-P
Anyhow, I split up the block... The big-big OOME-generating part are
the charsets, and I've simply factored them out into an ignorable
subdirectory, with its own build file, generating a JAR which gets
copied at compile time...
Also, to generate the charsets you mostly need J2SDK 1.4, so, it might
have broken some other stuff... blablabla... Putting all into a JAR
solves the problem AFAICS...
Can the Eclipsers give it a shot?
Pier
PS. "GIZA" comes from Jeremy... Spending too much time w/ that guy
lately! :-P
OOME on building serializers block (was Re: Planning the 2.1.5 release)
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> On 29.04.2004 19:48, Pier Fumagalli wrote:
>
>>> There is a problem with the new serializers block. From the
>>> developers I seem to
>>> be the only one having problems [1], but today this issue was also
>>> raised by two
>>> persons on the users list [2]. Imagine what happens if this is
>>> released as it is!
>>
>> I seriously suspect that it breaks because of memory leaks in JavaC
>
> Might be.
>
>> when doing a full cocoon build, from the beginning with a lot of
>> blocks enabled.
>
>
> I tested it with only the serializers block enabled: OutOfMemoryError.
> While I can build Cocoon with all blocks enabled except serializers block.
>
same here
> Something special must be about this block's sources, maybe the huge
> arrays.
>
>> I'm sure that if that block could be built easily if the "javac" task
>> "fork" attribute can be set to true...
>
>
> This might work for the build system, but not for Eclipse or other IDEs.
>
well, I just modify the project/properties in eclipse and throw away the
block sources from the build path... that just works
would be nice though if we had a version of the 'eclipse-project' target
that would do it for me by taking into account the
local.blocks.properties (hey, was that a hint?)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: Planning the 2.1.5 release
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.04.2004 19:48, Pier Fumagalli wrote:
>>> It's time to think about the next release. As far as I can see there
>>> are currently no real showstoppers.
>>>
>>> So, is there something that we should do for the 2.1.5 release?
>>
>> There is a problem with the new serializers block. From the developers
>> I seem to
>> be the only one having problems [1], but today this issue was also
>> raised by two
>> persons on the users list [2]. Imagine what happens if this is
>> released as it is!
>
>
> I seriously suspect that it breaks because of memory leaks in JavaC
Might be.
> when
> doing a full cocoon build, from the beginning with a lot of blocks enabled.
I tested it with only the serializers block enabled: OutOfMemoryError.
While I can build Cocoon with all blocks enabled except serializers block.
Something special must be about this block's sources, maybe the huge arrays.
> I'm sure that if that block could be built easily if the "javac" task
> "fork" attribute can be set to true...
This might work for the build system, but not for Eclipse or other IDEs.
Joerg
Re: Planning the 2.1.5 release
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 28 Apr 2004, at 15:57, Joerg Heinicke wrote:
> Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:
>
>> It's time to think about the next release. As far as I can see there
>> are currently no real showstoppers.
>>
>> So, is there something that we should do for the 2.1.5 release?
>
> There is a problem with the new serializers block. From the developers
> I seem to
> be the only one having problems [1], but today this issue was also
> raised by two
> persons on the users list [2]. Imagine what happens if this is
> released as it is!
I seriously suspect that it breaks because of memory leaks in JavaC
when doing a full cocoon build, from the beginning with a lot of blocks
enabled.
I noticed it once doing a full build, and then it went away once I
removed some other blocks.
I'm sure that if that block could be built easily if the "javac" task
"fork" attribute can be set to true...
Is there a way to override compilation settings for individual blocks?
Pier
RE: Planning the 2.1.5 release
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Yes, this happended some minutes ago to me as well :(
We could simply exclude the block for the release.
Carsten
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Joerg Heinicke
> Sent: Wednesday, April 28, 2004 4:57 PM
> To: dev@cocoon.apache.org
> Subject: Re: Planning the 2.1.5 release
>
> Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:
>
> > It's time to think about the next release. As far as I can
> see there
> > are currently no real showstoppers.
> >
> > So, is there something that we should do for the 2.1.5 release?
>
> There is a problem with the new serializers block. From the
> developers I seem to be the only one having problems [1], but
> today this issue was also raised by two persons on the users
> list [2]. Imagine what happens if this is released as it is!
>
> Joerg
>
> [1]
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108276440112212&w=4
> [2] http://marc.theaimsgroup.com/?t=108313573200002&r=1&w=4
>
>
Re: Planning the 2.1.5 release
Posted by Joerg Heinicke <jo...@gmx.de>.
Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:
> It's time to think about the next release. As far as I can see there
> are currently no real showstoppers.
>
> So, is there something that we should do for the 2.1.5 release?
There is a problem with the new serializers block. From the developers I seem to
be the only one having problems [1], but today this issue was also raised by two
persons on the users list [2]. Imagine what happens if this is released as it is!
Joerg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108276440112212&w=4
[2] http://marc.theaimsgroup.com/?t=108313573200002&r=1&w=4
Re: Planning the 2.1.5 release
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Upayavira wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> It's time to think about the next release. As far as I can see there
>>> are currently no real showstoppers.
>>>
>>> So, is there something that we should do for the 2.1.5 release?
>>
>>
>>
>> Liaise with the CForms guys to find the best time for them.Theirs is
>> the code that is changing the most, and if 2.1.5 is going to be a
>> CForms snapshot, we want it to be a reasonably good one!
>
>
>
> CForms is stabilizing quickly, but we'll still need a bit more time to
> stamp it as "stable". So let's not consider CForms as a blocking item
> for a 2.1.5. On the contrary, I think many people are waiting for it
> to start the move from Woody to CForms.
But we should not do 2.1.5 release in the middle of some cforms commit,
so to speak. That's the concern, as I understand it, Upayavira raised.
If current state of cforms is "stable" enough in its instability, then
fine, we can do a release. But if no enough testing was done since last
commit to cforms, let's do it and make release later, once we know that
current state of cforms is not worth than woody.
Vadim
Re: Planning the 2.1.5 release
Posted by Tim Larson <ti...@keow.org>.
On Wed, Apr 28, 2004 at 04:29:01PM +0200, Bruno Dumon wrote:
> On Wed, 2004-04-28 at 16:12, Carsten Ziegeler wrote:
> > Upayavira wrote:
> > >
> > > I wasn't considering it a blocking item - I was just saying,
> > > more or less, "let's not release in the middle of a commit!"
> > >
> > Good point!
> >
> > > All I'd want is a CForms chap to say, "Yes, now is an okay
> > > time to release, CForms is working". Then I'd be happy (and
> > > delighted, actually) to have a release.
> > >
> > Ok, "cforms chap", make yourself heard :)
>
> marc had to postpone the work he planned for this week, no need to wait
> for that in order to do a release.
Since I am working with Marc and also held up by other projects, this
means there is no need to wait for me either. I would love to see a
release with the woody->cforms renaming done so we can convert to it.
Also, I have been busy on other things and not able to check, but is
the "early validation" problem completely fixed? That is one issue
that should not slip into the next release.
--Tim Larson
RE: Planning the 2.1.5 release
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-04-28 at 16:12, Carsten Ziegeler wrote:
> Upayavira wrote:
> >
> > I wasn't considering it a blocking item - I was just saying,
> > more or less, "let's not release in the middle of a commit!"
> >
> Good point!
>
> > All I'd want is a CForms chap to say, "Yes, now is an okay
> > time to release, CForms is working". Then I'd be happy (and
> > delighted, actually) to have a release.
> >
> Ok, "cforms chap", make yourself heard :)
marc had to postpone the work he planned for this week, no need to wait
for that in order to do a release.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: Planning the 2.1.5 release
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Upayavira wrote:
>
> I wasn't considering it a blocking item - I was just saying,
> more or less, "let's not release in the middle of a commit!"
>
Good point!
> All I'd want is a CForms chap to say, "Yes, now is an okay
> time to release, CForms is working". Then I'd be happy (and
> delighted, actually) to have a release.
>
Ok, "cforms chap", make yourself heard :)
Carsten
Re: Planning the 2.1.5 release
Posted by Upayavira <uv...@upaya.co.uk>.
Sylvain Wallez wrote:
> Upayavira wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> It's time to think about the next release. As far as I can see there
>>> are currently no real showstoppers.
>>>
>>> So, is there something that we should do for the 2.1.5 release?
>>
>>
>>
>> Liaise with the CForms guys to find the best time for them.Theirs is
>> the code that is changing the most, and if 2.1.5 is going to be a
>> CForms snapshot, we want it to be a reasonably good one!
>
>
>
> CForms is stabilizing quickly, but we'll still need a bit more time to
> stamp it as "stable". So let's not consider CForms as a blocking item
> for a 2.1.5. On the contrary, I think many people are waiting for it
> to start the move from Woody to CForms.
I wasn't considering it a blocking item - I was just saying, more or
less, "let's not release in the middle of a commit!"
All I'd want is a CForms chap to say, "Yes, now is an okay time to
release, CForms is working". Then I'd be happy (and delighted, actually)
to have a release.
Hope that's clear enough!
Upayavira
>
> Sylvain
>
Re: Planning the 2.1.5 release
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Carsten Ziegeler wrote:
>
>> It's time to think about the next release. As far as I can see there
>> are currently no real showstoppers.
>>
>> So, is there something that we should do for the 2.1.5 release?
>
>
> Liaise with the CForms guys to find the best time for them.Theirs is
> the code that is changing the most, and if 2.1.5 is going to be a
> CForms snapshot, we want it to be a reasonably good one!
CForms is stabilizing quickly, but we'll still need a bit more time to
stamp it as "stable". So let's not consider CForms as a blocking item
for a 2.1.5. On the contrary, I think many people are waiting for it to
start the move from Woody to CForms.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Planning the 2.1.5 release
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Upayavira wrote:
> Carsten Ziegeler wrote:
>
>> It's time to think about the next release. As far as I can see there
>> are currently no real showstoppers.
>>
>> So, is there something that we should do for the 2.1.5 release?
>>
>>
> Liaise with the CForms guys to find the best time for them.Theirs is
> the code that is changing the most, and if 2.1.5 is going to be a
> CForms snapshot, we want it to be a reasonably good one!
I second this opinion (from the looks of it seems that there is no
roadblock for 2.1.5? I'm behind my mail....)
Vadim
Re: Planning the 2.1.5 release
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
>It's time to think about the next release. As far as I can see there
>are currently no real showstoppers.
>
>So, is there something that we should do for the 2.1.5 release?
>
>
Liaise with the CForms guys to find the best time for them.Theirs is the
code that is changing the most, and if 2.1.5 is going to be a CForms
snapshot, we want it to be a reasonably good one!
Otherwise - just go for it!
Upayavira
RE: Planning the 2.1.5 release
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ugo Cei wrote:
>
> Il giorno 28/apr/04, alle 09:55, Carsten Ziegeler ha scritto:
>
> > It's time to think about the next release. As far as I can
> see there
> > are currently no real showstoppers.
>
> The friday after the next is a First Friday, isn't it?
>
Yepp, May 14th - for me this seems to be the ideal candidate -
first friday on the 7th, one week freeze and then the release :)
Carsten
Re: Planning the 2.1.5 release
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 28/apr/04, alle 09:55, Carsten Ziegeler ha scritto:
> It's time to think about the next release. As far as I can see there
> are currently no real showstoppers.
The friday after the next is a First Friday, isn't it?
Ugo