cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: SourceResolver in SSF
Date Wed, 19 Mar 2008 10:24:21 GMT
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.
> I propose to release 1.0.0 with a copy of jnet inside SSF; after the
> release of 1.0.0 we sort out where and how we want to have the code.
I'm not sure if this is the best option. I hoped to have final release
of 1.0.0 before Easter. Integration of JNet, which seems to be an easy
task will postpone the release for a few weeks because someone must do
this integration, then  we will need to test it and only then release.

I think everyone will agree that most users of SSF will be users of
Cocoon 2.2 as well, at least at the beginning. We don't have a good
documentation explaining how to use SSF outside Cocoon land and why it
would be useful to do so. Having said that, I don't expect many people
upset about dependency on CocoonSourceResolver. I think putting a bold
remark that there is a limitation in 1.0.0 release that will get
resolved ASAP is enough.

Therefore I propose:
1. Make a 1.0.0 of SSF as it's now so Cocoon users can consume it and we
will be able to release other artifacts in final version. (Remember: we
can't release Cocoon Core 2.2 final if we don't have final release of SSF)
2. Integrate JNet by copying the code, cut first milestone of 1.1.0.
This way we will deliver truly Cocoon-independent version of SSF for
early adapters and at the same time we will get some time to sort out
what to do with JNet code.
3. (Possibly) Create subproject 'JNet', fix bugs in SSF 1.1.0-M1 if any
4. Make final relase of JNet 1.0.0 and SSF 1.1.0.

Does it make sense?


View raw message