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
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
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.
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
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
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. :-)
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
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:
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 would
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:
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 to
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.
Yep,
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
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
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
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
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
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 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
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.
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
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 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
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
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
26 matches
Mail list logo
