I have no problem with merging the PMCs. I am not in favor of merging
the source code.
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I'm not sure what JNet actually is, but the part I was referring to
was where Carsten was talking about Excalibur being dead and pullin
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I'm not sure what JNet actually is, but the part I was referring to
was where Carsten was talking about Excalibur being dead and pulling
out the few pieces we use.
Maybe it's better that Carsten explains what he meant.
:) Yepp
I meant we could
Ralph Goers pisze:
I'm not sure what JNet actually is, but the part I was referring to was
where Carsten was talking about Excalibur being dead and pulling out the
few pieces we use.
Maybe it's better that Carsten explains what he meant. Anyway, my understanding is to bring JNet
which is smal
I'm not sure what JNet actually is, but the part I was referring to was
where Carsten was talking about Excalibur being dead and pulling out the
few pieces we use.
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
As a user of sourceresolve independent of Cocoon I would be -1 on
moving it into C
Ralph Goers pisze:
As a user of sourceresolve independent of Cocoon I would be -1 on moving
it into Cocoon. If it goes anywhere I'd prefer commons.
Ralph, I'm not sure if you have followed the whole thread. We don't want to tie JNet code with
Cocoon but only to establish a subproject of Cocoon
As a user of sourceresolve independent of Cocoon I would be -1 on moving
it into Cocoon. If it goes anywhere I'd prefer commons.
Carsten Ziegeler wrote:
Now, I think that this will be over time the best solution *if* we can
keep the excalibur package names - but I think that should be possibl
Grzegorz Kossakowski wrote:
Carsten Ziegeler wrote:
Yes, in the long run. But to get out SSF asap I would just copy the
classes. This is internal stuff, so this shouldn't cause problems if
the packages, classes or methods change after the SSF release.
+1
I propose to release 1.0.0 with a copy
Carsten Ziegeler wrote:
> No :) Just use SourceFactoriesManager.pushFactories when the request
> starts and popFactories at the end of the request. This can then also
> be used for different factories depending on the block that is
> currently executed.
> So it's like switching the block context.
Carsten Ziegeler wrote:
> Yes, in the long run. But to get out SSF asap I would just copy the
> classes. This is internal stuff, so this shouldn't cause problems if
> the packages, classes or methods change after the SSF release.
+1
> I propose to release 1.0.0 with a copy of jnet inside SSF; after
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy
the jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject "jnet"?
Yes, in the long run. But t
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy
the jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject "jnet"?
Yes, in the long run. But to get out SSF asap I woul
Carsten Ziegeler wrote:
The problematic part is the time frame. I would suggest to just copy the
jnet classes to SSF to be able to release SSF in a short time frame.
Shouldn't we rather create another subproject "jnet"?
We can then sort out the details after Easter.
Just to be clear: Do you
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
First we have to discuss, which project does the release? Do we want
to pull it into Cocoon? TBH, I'd
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
First we have to discuss, which project does the release? Do we want
to pull it into Cocoon? TBH, I'd rather get rid of Excal
I think I'm wrong, we could also change the dep from jnet to
sourceresolve to use the avalon version as a start.
Carsten
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare
an official release. :-)
Fi
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare an
official release. :-)
First we have to discuss, which project does the release? Do we want to
pull it into Cocoon? TBH, I'd rather get rid of Excalibur dependencies
that c
Grzegorz Kossakowski wrote:
Carsten, I've taken a look at your code and it looks very nice. I have
2. All we need to do in SSF is:
a) implement our own SourceFactoriesManager (by extending your
abstrac class)
No :) Just use SourceFactoriesManager.pushFactories when the request
starts and pop
Grzegorz Kossakowski wrote:
1. If you want other projects to use your stuff you need to prepare an
official release. :-)
First we have to discuss, which project does the release? Do we want to pull it
into Cocoon? TBH, I'd rather get rid of Excalibur dependencies that creating
another one.
Carsten Ziegeler pisze:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Yes, that is the reason why I started jnet :) (unfortunately I never
had time to finish this)
What's left? Only polishing or more?
Polishing and trying to convince the projects to use it :)
Carsten, I've taken a loo
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Yes, that is the reason why I started jnet :) (unfortunately I never
had time to finish this)
What's left? Only polishing or more?
Polishing and trying to convince the projects to use it :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Carsten Ziegeler wrote:
Yes, that is the reason why I started jnet :) (unfortunately I never had
time to finish this)
What's left? Only polishing or more?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here.
What you described sounds great and it's very tempting to have
sources properly working with just standard URL class.
A
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here.
What you described sounds great and it's very tempting to have
sources properly working with just standard URL class.
Anyway, I'm little bit w
Grzegorz Kossakowski wrote:
Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here. What
you described sounds great and it's very tempting to have sources
properly working with just standard URL class.
Anyway, I'm little bit worried that whole things
Carsten Ziegeler pisze:
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
My plan is to register default Excalibur's SourceResolver
implementation as a Spring-bean and use it by default. Then, Cocoon
Core would replace
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
My plan is to register default Excalibur's SourceResolver
implementation as a Spring-bean and use it by default. Then, Cocoon
Core would replace it with CocoonSourceResol
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
My plan is to register default Excalibur's SourceResolver
implementation as a Spring-bean and use it by default. Then, Cocoon
Core would replace it with CocoonSourceResolver using Spring
configurato
27 matches
Mail list logo