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 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 found. 4. Make final relase of JNet 1.0.0 and SSF 1.1.0. Does it make sense? -- Grzegorz
