You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/04/13 16:47:00 UTC
[vote] Switching to refactored JXTG
I propose that we (in trunk) remove the current JXTG and replace it with
the refactored JXTG that is part of the Template block. The refactored
JXTG is supposed to be back compatible with the original JXTG and also
add the ability to use JXTG in the same way in a non flow context. The
only change will be that one has to include the Template block to get
JXTG it will not be part of core anymore. We change the class name of
the refactored JXTG to that of the old one.
There are certainly things left to do in the refactoring but everything
is supposed to work as it is right now and having two versions of the
same thing complicates support. If we have introduced any bugs and
incompabilities during refactoring it is better to find and fix them as
fast as possible.
I also suggest that we mark the Template block as being core (rather
than supported or contributed) as it together with CForms is core
functionality of Cocoon and it has been part of core this far.
Third, we have to decide how we should handle improvements and changes
in JXTG. My suggestion is that we keep JXTG more or less as is and that
we improve functionality and add new features in a new TemplateGenerator
that we refer to as CTemplate. In this way we can remove things we don't
like in JXTG without introduce problems for current users. Thanks to the
pluggable architecture in Template this will not lead to much code
duplications. Ideas about what we want in CTemplate can be found in
http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2.
Please cast your votes:
[ ] Let's switch to the refactored JXTG in trunk!
[ ] It can wait.
[ ] Mark the Template block core.
[ ] I suggest ...
[ ] Keep JXTG functionality as is and put template development efforts
in CTemplate
[ ] Add new things to JXTG while keeping it back compatible
[ ] Add new things to JXTG and allow back in compatibilities
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Daniel Fagerstrom wrote:
> Please cast your votes:
>
> [ +1 ] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [ +1 ] Mark the Template block core.
> [ ] I suggest ...
>
> [ +1 ] Keep JXTG functionality as is and put template development
> efforts in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> [X] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [X] Mark the Template block core.
> [ ] I suggest ...
>
> [X] Keep JXTG functionality as is and put template development efforts
> in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
Vadim
Re: [vote] Switching to refactored JXTG
Posted by Jeremy Quinn <je...@apache.org>.
On 13 Apr 2005, at 15:47, Daniel Fagerstrom wrote:
> Please cast your votes:
>
> [ X] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [ X] Mark the Template block core.
> [ ] I suggest ...
>
> [X ] Keep JXTG functionality as is and put template development
> efforts in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
>
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ugo Cei wrote:
> Il giorno 13/apr/05, alle 16:47, Daniel Fagerstrom ha scritto:
>
>> I propose that we (in trunk) remove the current JXTG and replace it
>> with the refactored JXTG that is part of the Template block. The
>> refactored JXTG is supposed to be back compatible with the original
>> JXTG and also add the ability to use JXTG in the same way in a non
>> flow context. The only change will be that one has to include the
>> Template block to get JXTG it will not be part of core anymore. We
>> change the class name of the refactored JXTG to that of the old one.
>
>
> I just have a small fear about this. If we switch to the refactored
> JXTG in 2.2, we will have three branches to work on:
>
> - fixing bugs in the old JXTG in 2.1, even though no new features are
> added
Yes.
> - fixing bugs in the refactored JXTG in 2.2 and maybe adding new
> features, since 2.2 is going to stay around for a long time.
> - developing the new TemplateGenerator.
This is not exactly two braches. After the refactoring we have a
configurable template framework (still some things left to do to get
there, but we are close). So JXTG and CTemplate will share almost all
code. They will differ in their configuration files and some of the
instructions might be in two different versions, if we want it that way.
As an example, the jx:import instruction and jx:set instruction have
peculiarities that we propbably want to get rid of in CTemplate, but
that we might want to keep in JXTG for back compability reasons.
> As long as the refactored JXTG is backward compatible, what's stopping
> us from dropping the old one completely?
We should test the refactored JXTG in trunk for some while before
droping the old one in 2.1. We also chosed not to have a copy of the
Template block in 2.1 as it would complicate the development work to
keep two branches in synch. But we can copy it to 2.1 when/if the
community want it that way.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 13/apr/05, alle 16:47, Daniel Fagerstrom ha scritto:
> I propose that we (in trunk) remove the current JXTG and replace it
> with the refactored JXTG that is part of the Template block. The
> refactored JXTG is supposed to be back compatible with the original
> JXTG and also add the ability to use JXTG in the same way in a non
> flow context. The only change will be that one has to include the
> Template block to get JXTG it will not be part of core anymore. We
> change the class name of the refactored JXTG to that of the old one.
I just have a small fear about this. If we switch to the refactored
JXTG in 2.2, we will have three branches to work on:
- fixing bugs in the old JXTG in 2.1, even though no new features are
added
- fixing bugs in the refactored JXTG in 2.2 and maybe adding new
features, since 2.2 is going to stay around for a long time.
- developing the new TemplateGenerator.
As long as the refactored JXTG is backward compatible, what's stopping
us from dropping the old one completely?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Source.zone: http://sourcezone.info/
Wine & Food Blog: http://www.divinocibo.it/
Re: [vote] Switching to refactored JXTG
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>
> <snip/>
>
>>> We have discussed configurable and unified environment (object model)
>>> handling: http://marc.theaimsgroup.com/?t=110963091600004&r=1&w=2,
>>> which would mean that you can decide what you want JXTG to depend on,
>>> e.g. if it should allow the use of Java packages in expressions or not.
>>>
>>> I started on a prototype:
>>>
>>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/components/accessor/
>>>
>>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/components/accessor/
>>
>>
>>
>> I missed that code though.
>
>
> It's not integrated in JXTG yet, what is missing is accessors for
> "java.*" and "Package.*" which wouldn't be that hard to add. One have to
> think a little bit about how to avoid creating a lot of new Rhino
> context. What is more complicated is how to handle sitemap parameters as
> they don't fit together with the rest of the environment handling that
> only uses the object model and the service manager.
>
>>> but there are other things that has higher priority for me, so if no
>>> one else jumps on it it will take some while before anything happens.
>>
>>
>> I have some doubts if we are able to make new JXTG official, create a
>> CTemplate and work on it without duplicating the code.
>
>
> I have no doubts that it is possible :) Most of the template code is, or
> should be framework code that is reusable, only the instructions,
> expression parsing and maybe some other parts need to differ. And all
> such parts is or should be made pluggable.
>
>> For example: I would like to start working on implementing a
>> jx:attribute. Apart from new tag I will have to create some kind of
>> enhanced ContentHandler that also takes attributes as events. This
>> means that official jxtg should not define jx:attribute and not use
>> that new ContentHandler.
>
>
> Is the new ContentHandler goin to introduce any incompability, or give
> some extra fetaures without the attrribute tag? Otherwise it can be part
> of both languages without any problem.
If jx:attribute is not used it should be transparent to the user. I do
not know if it's going to introduce performance issues.
>
> As long as you only add functionallity and only in trunk I think you can
> continue to work on the JXTG language. We can wait with splitting it
> until we need to make incompatible things.
Fine for me. I'll start with jx:attribute and jx:static-import (so it
does not conflict with former jx:import).
> Then we of course need to
> decide if the additions should be part of JXTG before we release 2.2.
> But we don't need to handle everything right now.
It is not that hard to turn some features off but I do not see a reason
for that right now.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> We have discussed configurable and unified environment (object model)
>> handling: http://marc.theaimsgroup.com/?t=110963091600004&r=1&w=2,
>> which would mean that you can decide what you want JXTG to depend on,
>> e.g. if it should allow the use of Java packages in expressions or not.
>>
>> I started on a prototype:
>>
>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/components/accessor/
>>
>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/components/accessor/
>
> I missed that code though.
It's not integrated in JXTG yet, what is missing is accessors for
"java.*" and "Package.*" which wouldn't be that hard to add. One have to
think a little bit about how to avoid creating a lot of new Rhino
context. What is more complicated is how to handle sitemap parameters as
they don't fit together with the rest of the environment handling that
only uses the object model and the service manager.
>> but there are other things that has higher priority for me, so if no
>> one else jumps on it it will take some while before anything happens.
>
> I have some doubts if we are able to make new JXTG official, create a
> CTemplate and work on it without duplicating the code.
I have no doubts that it is possible :) Most of the template code is, or
should be framework code that is reusable, only the instructions,
expression parsing and maybe some other parts need to differ. And all
such parts is or should be made pluggable.
> For example: I would like to start working on implementing a
> jx:attribute. Apart from new tag I will have to create some kind of
> enhanced ContentHandler that also takes attributes as events. This means
> that official jxtg should not define jx:attribute and not use that new
> ContentHandler.
Is the new ContentHandler goin to introduce any incompability, or give
some extra fetaures without the attrribute tag? Otherwise it can be part
of both languages without any problem.
As long as you only add functionallity and only in trunk I think you can
continue to work on the JXTG language. We can wait with splitting it
until we need to make incompatible things. Then we of course need to
decide if the additions should be part of JXTG before we release 2.2.
But we don't need to handle everything right now.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Gregor J. Rothfuss wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Please cast your votes:
>>>>
>>>> [X ] Let's switch to the refactored JXTG in trunk!
>>>> [ ] It can wait.
>>>>
>>>> [ X] Mark the Template block core.
>>>> [ ] I suggest ...
>>>
>>>
>>>
>>>
>>> i also just noticed that the old JXTemplateGenerator has a dependency
>>> on rhino (which means it does not work in a pure javaflow environment)
>>>
>> The new one also does. Rhino along with JEXL is used for this kind of
>> statements:
>>
>> <jx:set name="map" value="${java.util.HashMap()}"/>
>> or
>>
>> ${Packages.com.mycompany.formatter.MyJuicyFormatter.format(
>> bean.value, cocoon.consumer )}
>>
>> We haven't found a replacement yet.
I meant there is no replacement yet. I remember our discussion :)
>
>
> We have discussed configurable and unified environment (object model)
> handling: http://marc.theaimsgroup.com/?t=110963091600004&r=1&w=2, which
> would mean that you can decide what you want JXTG to depend on, e.g. if
> it should allow the use of Java packages in expressions or not.
>
> I started on a prototype:
>
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/components/accessor/
>
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/components/accessor/
I missed that code though.
> but there are other things that has higher priority for me, so if no one
> else jumps on it it will take some while before anything happens.
I have some doubts if we are able to make new JXTG official, create a
CTemplate and work on it without duplicating the code.
For example: I would like to start working on implementing a
jx:attribute. Apart from new tag I will have to create some kind of
enhanced ContentHandler that also takes attributes as events. This means
that official jxtg should not define jx:attribute and not use that new
ContentHandler.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Gregor J. Rothfuss wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Please cast your votes:
>>>
>>> [X ] Let's switch to the refactored JXTG in trunk!
>>> [ ] It can wait.
>>>
>>> [ X] Mark the Template block core.
>>> [ ] I suggest ...
>>
>>
>>
>> i also just noticed that the old JXTemplateGenerator has a dependency
>> on rhino (which means it does not work in a pure javaflow environment)
>>
> The new one also does. Rhino along with JEXL is used for this kind of
> statements:
>
> <jx:set name="map" value="${java.util.HashMap()}"/>
> or
>
> ${Packages.com.mycompany.formatter.MyJuicyFormatter.format( bean.value,
> cocoon.consumer )}
>
> We haven't found a replacement yet.
We have discussed configurable and unified environment (object model)
handling: http://marc.theaimsgroup.com/?t=110963091600004&r=1&w=2, which
would mean that you can decide what you want JXTG to depend on, e.g. if
it should allow the use of Java packages in expressions or not.
I started on a prototype:
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/components/accessor/
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/components/accessor/
but there are other things that has higher priority for me, so if no one
else jumps on it it will take some while before anything happens.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Gregor J. Rothfuss wrote:
> Daniel Fagerstrom wrote:
>
>> Please cast your votes:
>>
>> [X ] Let's switch to the refactored JXTG in trunk!
>> [ ] It can wait.
>>
>> [ X] Mark the Template block core.
>> [ ] I suggest ...
>
>
> i also just noticed that the old JXTemplateGenerator has a dependency on
> rhino (which means it does not work in a pure javaflow environment)
>
The new one also does. Rhino along with JEXL is used for this kind of
statements:
<jx:set name="map" value="${java.util.HashMap()}"/>
or
${Packages.com.mycompany.formatter.MyJuicyFormatter.format( bean.value,
cocoon.consumer )}
We haven't found a replacement yet.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Switching to refactored JXTG
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Daniel Fagerstrom wrote:
> Please cast your votes:
>
> [X ] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [ X] Mark the Template block core.
> [ ] I suggest ...
i also just noticed that the old JXTemplateGenerator has a dependency on
rhino (which means it does not work in a pure javaflow environment)
Re: [vote] Switching to refactored JXTG
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> [+1] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [+1] Mark the Template block core.
> [ ] I suggest ...
>
> [+1] Keep JXTG functionality as is and put template development efforts
> in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
I haven't tested cTemplate yet (I trust Leszek and you!) but making it the
default will certainly lead to a bigger user base - at least I will use it in my
current projects and this will increase the pressure to make it completly
backwards compatible if there are some open issues.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [vote] Switching to refactored JXTG
Posted by Leszek Gawron <lg...@apache.org>.
Daniel Fagerstrom wrote:
> Please cast your votes:
>
> [+1] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [+1] Mark the Template block core.
> [ ] I suggest ...
>
> [+1] Keep JXTG functionality as is and put template development efforts
> in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: [vote] Switching to refactored JXTG
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 13 avr. 05, à 16:47, Daniel Fagerstrom a écrit :
> [X ] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [ X] Mark the Template block core.
> [ ] I suggest ...
>
> [ X] Keep JXTG functionality as is and put template development
> efforts in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
-Bertrand
Re: [vote result] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> * I or maybe Leszek takes care of the switch to the refactored JXTG ASAP.
>
> got my hands on it now - expect commit soon.
Great!
/Daniel
Re: [vote result] Switching to refactored JXTG
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> We got the following results from the JXTG vote:
>
>> [ 7+1 ] Let's switch to the refactored JXTG in trunk!
>> [ ] It can wait.
>>
>> [ 7+1 ] Mark the Template block core.
>> [ ] I suggest ...
>>
>> [ 7 ] Keep JXTG functionality as is and put template development
>> efforts in CTemplate
>> [ ] Add new things to JXTG while keeping it back compatible
>> [ ] Add new things to JXTG and allow back in compatibilities
>
>
>
> * I or maybe Leszek takes care of the switch to the refactored JXTG ASAP.
got my hands on it now - expect commit soon.
> * Marking template as core is more a mental note for the moment, it will
> be part of block.xml IIUC.
> * We start with the split into JXTG and CTemplate, as soon as there is a
> need for it. That is when we need some back incompatible change or when
> we have introduced enough new stuff.
>
> /Daniel
>
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
[vote result] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
We got the following results from the JXTG vote:
> [ 7+1 ] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
>
> [ 7+1 ] Mark the Template block core.
> [ ] I suggest ...
>
> [ 7 ] Keep JXTG functionality as is and put template development
> efforts in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
* I or maybe Leszek takes care of the switch to the refactored JXTG ASAP.
* Marking template as core is more a mental note for the moment, it will
be part of block.xml IIUC.
* We start with the split into JXTG and CTemplate, as soon as there is a
need for it. That is when we need some back incompatible change or when
we have introduced enough new stuff.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> I propose that we (in trunk) remove the current JXTG and replace it
> with the refactored JXTG that is part of the Template block. The
> refactored JXTG is supposed to be back compatible with the original
> JXTG and also add the ability to use JXTG in the same way in a non
> flow context. The only change will be that one has to include the
> Template block to get JXTG it will not be part of core anymore. We
> change the class name of the refactored JXTG to that of the old one.
>
> There are certainly things left to do in the refactoring but
> everything is supposed to work as it is right now and having two
> versions of the same thing complicates support. If we have introduced
> any bugs and incompabilities during refactoring it is better to find
> and fix them as fast as possible.
>
> I also suggest that we mark the Template block as being core (rather
> than supported or contributed) as it together with CForms is core
> functionality of Cocoon and it has been part of core this far.
>
> Third, we have to decide how we should handle improvements and changes
> in JXTG. My suggestion is that we keep JXTG more or less as is and
> that we improve functionality and add new features in a new
> TemplateGenerator that we refer to as CTemplate. In this way we can
> remove things we don't like in JXTG without introduce problems for
> current users. Thanks to the pluggable architecture in Template this
> will not lead to much code duplications. Ideas about what we want in
> CTemplate can be found in
> http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2.
>
> Please cast your votes:
>
> [X] Let's switch to the refactored JXTG in trunk!
> [ ] It can wait.
Haven't tried it yet, but let's move on to something better than the
current JXTG. We'll solve back incompatibilities when they appear.
> [X] Mark the Template block core.
> [ ] I suggest ...
> [X] Keep JXTG functionality as is and put template development efforts
> in CTemplate
> [ ] Add new things to JXTG while keeping it back compatible
> [ ] Add new things to JXTG and allow back in compatibilities
Trying to keep compatibility is very likely to bring headaches. So let's
do something else. One of the strengths of Cocoon is its ability to
bring new features while still providing the old ones.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 14 avr. 05, à 08:24, Daniel Fagerstrom a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> ....Before voting, what worries me slightly is the "supposed to
>>> work" bit...
>>> I didn't look into the new stuff yet, are there tests (automated or
>>> not) to help make a more precise assessment?
>>
>>
>> Of course :)
>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/
>> trunk/test/org/apache/cocoon/
>>
>> I wouldn't dare trying to refactor such a complicated beast as JXTG
>> whithout automated testing...
>
>
> Thanks for the clarification - I should have looked before asking,
> this is much more reassuring than "supposed to work" ;-)
I should probably have choosen a somewhat more optimistic formulation.
But I have worked to long time with program development for being able
to feel comfortable in making any definite statements about program
correctness ;) My programming style nowdays is rather paranoid.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 avr. 05, à 08:24, Daniel Fagerstrom a écrit :
> Bertrand Delacretaz wrote:
>> ....Before voting, what worries me slightly is the "supposed to work"
>> bit...
>> I didn't look into the new stuff yet, are there tests (automated or
>> not) to help make a more precise assessment?
>
> Of course :)
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/
> trunk/test/org/apache/cocoon/
>
> I wouldn't dare trying to refactor such a complicated beast as JXTG
> whithout automated testing...
Thanks for the clarification - I should have looked before asking, this
is much more reassuring than "supposed to work" ;-)
-Bertrand
Re: [vote] Switching to refactored JXTG
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 13 avr. 05, à 16:47, Daniel Fagerstrom a écrit :
>
>> ...There are certainly things left to do in the refactoring but
>> everything is supposed to work as it is right now...
>
>
> Before voting, what worries me slightly is the "supposed to work" bit.
>
> I didn't look into the new stuff yet, are there tests (automated or not)
> to help make a more precise assessment?
Of course :)
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/
I wouldn't dare trying to refactor such a complicated beast as JXTG
whithout automated testing. Two of the testcases that use the expression
#{$cocoon/request/protocol} fails, but they fails for the original
JXTG as well, this has to do, IIRC, with Sylvain's and Carsten's
refactoring of environment handling in flow.
With supposed to work, I meant that its impossible to grant that we
didn't introduce bugs in functionality we didn't thought of testing.
Also its quite some while since I tested it outside the testing
framework, maybe Leszek has more recent experiences, of running it out
in the wild.
Although I love automatic testing and wouldn't develop any Java code
without it, it is still limited by ones creativity in thinking out test
cases. The only "certain" test method is to put it into real use whith
more users, which we ask for being allowed to do now.
We are of courses dedicated to fix or help fixing any problem that might
occur.
/Daniel
Re: [vote] Switching to refactored JXTG
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 13 avr. 05, à 16:47, Daniel Fagerstrom a écrit :
>
>> ...There are certainly things left to do in the refactoring but
>> everything is supposed to work as it is right now...
>
>
> Before voting, what worries me slightly is the "supposed to work" bit.
>
> I didn't look into the new stuff yet, are there tests (automated or not)
> to help make a more precise assessment?
Daniel already answered in detail on this. Additionally I want to remark that we
are talking about 2.2 (not 2.1!!!), which we don't consider being stable. In
spit of not being stable, some of us use 2.2 in projects, of course on their own
risk, but his will be the "real life test cases" that every new technology needs.
This is the reason for my 3 +1 and my confidence in Daniel and Leszek who are
very responsive and I'm sure they will fix incomptabilities and bugs very soon.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [vote] Switching to refactored JXTG
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 13 avr. 05, à 16:47, Daniel Fagerstrom a écrit :
> ...There are certainly things left to do in the refactoring but
> everything is supposed to work as it is right now...
Before voting, what worries me slightly is the "supposed to work" bit.
I didn't look into the new stuff yet, are there tests (automated or
not) to help make a more precise assessment?
-Bertrand