> name="org.apache.avalon.excalibur.datasource.DataSourceComponent/personnel"
>
> class="org.apache.cocoon.databases.bridge.spring.avalon.SpringToAvalonDataSourceWrapper">
>
> name="org.apache.avalon.excalibur.datasource.DataSourceComponent/personnel"
> class="org.sp
Grzegorz Kossakowski wrote:
>
> Carsten, can you give your configuration (plug-ins included) that makes your
> Eclipse supporting
> refactoring of Spring configuration files? It does not work on my Eclipse
> 3.3, now.
>
I have installed the full-blown Europa 3.3 installation with the usual
susp
[
https://issues.apache.org/jira/browse/COCOON-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528185
]
Grzegorz Kossakowski commented on COCOON-2106:
--
I come to conclusion that registering wrappers automati
[
https://issues.apache.org/jira/browse/COCOON-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek reopened COCOON-2048:
---
There is a bug around line 243 after that patch: the creation of the
BufferedIm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>> I'm almost sure that if you change scope of OM to request it's going to
>> work. Just make sure that
>> old junk is not sitting somewhere in the classpath. If it's not the case, I
>> must
Grzegorz Kossakowski wrote:
Cartsen, can you give your configuration (plug-ins included) that makes your
Eclipse supporting
refactoring of Spring configuration files? It does not work on my Eclipse 3.3,
now.
SpringIDE supports some degree of refactoring (see 'New Features' in the
2.0 relea
Daniel Fagerstrom pisze:
> Giacomo Pati skrev:
>> Daniel Fagerstrom wrote:
>>
>>
>> I think we should vote on this, shouldn't we?
> Probably. I think we should start to use lazy votes for this kind of
> stuff. While we are Springifying and refactoring Cocoon there will
> probably continue to be l
Grzegorz Kossakowski pisze:
>
> I'm almost sure that if you change scope of OM to request it's going to work.
> Just make sure that
> old junk is not sitting somewhere in the classpath. If it's not the case, I
> must get working example
> of problematic behaviour in order to help anyhow.
Giacom
Carsten Ziegeler pisze:
> Vadim Gritsenko wrote:
>> You can try IDEA. As a committer on apache project you can get license
>> for free for your open source work. It will refactor configuration files
>> simultaneously with java files.
Vadim, it's not the first time you encourage me to try IDEA and
Giacomo Pati pisze:
>
> I think we should vote on this, shouldn't we? I absolutely dislike having the
> LifecycleHelper (and
> thus Avalon classes) staying in the CForms code.
>
> What do otehrs think about it?
+1 for removing this stuff as long as it's released as 1.1.0 AND migration
document
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Again, how should deprecation be implemented:
a) use deprecation logger but keep current implementation
b) throw an exception and remove current implementat
Giacomo Pati wrote:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Again, how should deprecation be implemented:
a) use deprecation logger but keep current implementation
b) throw an exception and remove current implementation
a) is probably t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Fagerstrom wrote:
> Giacomo Pati skrev:
>> Daniel Fagerstrom wrote:
>>
>>> Giacomo Pati skrev:
>> Again, how should deprecation be implemented:
>>
>> a) use deprecation logger but keep current implementation
>> b) throw an exception and remo
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Giacomo Pati wrote:
Hi all
If there is nobody working on the subject I'll spend a few hours on
doing that.
My general tactic would be to first rewrite the xconf/rules into a
spring config so that adding new
Wid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Fagerstrom wrote:
> Giacomo Pati skrev:
>> Giacomo Pati wrote:
>>
>>> Hi all
>>>
>>> If there is nobody working on the subject I'll spend a few hours on
>>> doing that.
>>>
>>> My general tactic would be to first rewrite the xconf/rules into
Giacomo Pati skrev:
Giacomo Pati wrote:
Hi all
If there is nobody working on the subject I'll spend a few hours on doing that.
My general tactic would be to first rewrite the xconf/rules into a spring
config so that adding new
Widgets/Converters/Datatypes will than be easily manageable (us
Giacomo Pati wrote:
>
>
> Vadim Gritsenko wrote:
>> Giacomo Pati wrote:
>>> Now that I'm trying to do it I have some qustions about how we can
>>> manage LifecycleHelper stuff in
>>> a Spring context.
>>>
>>> In CForm definition files there are constructs that accepted a class
>>> attribute to de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vadim Gritsenko wrote:
> Giacomo Pati wrote:
>> Now that I'm trying to do it I have some qustions about how we can
>> manage LifecycleHelper stuff in
>> a Spring context.
>>
>> In CForm definition files there are constructs that accepted a class
>> a
Grzegorz Kossakowski wrote:
> More seriously, Sylvain, are you going to attend CocoonGT this year? I would
> love to meet you there!
>
No, unfortunately I won't make it. I would have loved to meet all of you
young and old cocooners, but my (lack of) involvement hardly justifies
the expense and
On 17.09.2007 3:53 Uhr, Carsten Ziegeler wrote:
Too many files confuse users, so I would go to put everything in a
single file and only if it makes sense to split it, start a new file.
+1
Joerg
Giacomo Pati wrote:
Now that I'm trying to do it I have some qustions about how we can manage
LifecycleHelper stuff in
a Spring context.
In CForm definition files there are constructs that accepted a class attribute
to denote a Java
class being instantiated and managed as it where a Avalon Com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giacomo Pati wrote:
> Hi all
>
> If there is nobody working on the subject I'll spend a few hours on doing
> that.
>
> My general tactic would be to first rewrite the xconf/rules into a spring
> config so that adding new
> Widgets/Converters/Data
Vadim Gritsenko wrote:
> Grzegorz Kossakowski wrote:
>> What annoys me the most is lack of support for refactoring of beans
>> configs in Eclipse. Currently my
>> workflow is following:
>> 1. Refactor java classes using Eclipse tools
>
> You can try IDEA. As a committer on apache project you can g
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Grzegorz Kossakowski skrev:
>>> I see. Last question is about multiple bean declarations in one xml
>>> file. Do we think it's good or
>>> bad practise?
>>
>> No strong opinion about that. If a couple of beans works togther or
>> are of the same "
24 matches
Mail list logo
