Re: Finding a name for OSGi based Cocoon
mmh, ok i didn't understood all the differences for what a OSGi-based cocoon is useful yet. But i think it would be a pity not to call it cocoon. In the end is there only the OSGi-based version of cocoon? Or are there two different versions? In the first case cocoon 3 sounds reasonable, and all 2.x versions are more or less maintenance-releases which could be released also after a 3.0 version. In the latter case a new name would be better. cocoon 1 and cocoon 2 are two quite different things too, but both called cocoon. I use cocoon since years in the meanwhile and i loved it from all the beginning. I'am one of the guys who is writing more xml than java. Boris Carsten Ziegeler wrote: Reinhard Poetz schrieb: Since the GT in Amsterdam, when Daniel used "Cocoon 3.0" for his proposal of an OSGi based Cocoon, we have been talking about Cocoon 3.0 in different ways. For example in the meantime Sylvain used "Cocoon 3.0" as the subject of the discussion that he started in December. While working with Daniel in April we used "Cocoon 3.0" as a name for our vision of an OSGi-based Cocoon. The point is that the vision has become reality in the meantime[1] and the number of open tasks (see JIRA http://tinyurl.com/rubss) is manageable. What I want is that we agree on a name for OSGi based Cocoon within the Cocoon community, either "Cocoon 3.0" or a code name. We also have to take into account that trunk might also be released as Cocoon 2.3. WDOT, should we use "Cocoon 3.0" for OSGi based Cocoon or find a code name and tag it with a release number when we are close to our first milestone/alpha release? I don't know if "3.0" is a good "name" or not, but I would really appreciate it if we try to release a 2.2/2.3 before a 3.0! Carsten
Re: Finding a name for OSGi based Cocoon
* Sylvain Wallez: > Reinhard Poetz wrote: > > > Sylvain Wallez wrote: > > > >> My ideas, which are progressing slowly because of the lack of > >> time, are really diverging from the current code base. So, if > >> they one day come to life, I doubt they will deserve the name > >> "Cocoon". > > > > I'm looking forward to hearing from your ideas. I think that > > the architectural changes of Cocoon 3.0 will make it much > > easier to experiment again in a "safe" way. > > I'm currently going more on the "full-Java" side of things > rather than the declarative way with XML files. [...] For > complex forms, Wicket [2] uses the same kind of component model > as CForms, but in a pure Java way, and is very powerful. And also worth to mention that Wicket consists of only *one* jar (1 Mb), and is your-favorite-component-container friendly for managing your web applications. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Finding a name for OSGi based Cocoon
Reinhard Poetz schrieb: > > Since the GT in Amsterdam, when Daniel used "Cocoon 3.0" for his proposal of > an > OSGi based Cocoon, we have been talking about Cocoon 3.0 in different ways. > For > example in the meantime Sylvain used "Cocoon 3.0" as the subject of the > discussion that he started in December. > > While working with Daniel in April we used "Cocoon 3.0" as a name for our > vision of an OSGi-based Cocoon. The point is that the vision has become > reality > in the meantime[1] and the number of open tasks (see JIRA > http://tinyurl.com/rubss) is manageable. > > What I want is that we agree on a name for OSGi based Cocoon within the > Cocoon community, either "Cocoon 3.0" or a code name. We also have to take > into > account that trunk might also be released as Cocoon 2.3. > > WDOT, should we use "Cocoon 3.0" for OSGi based Cocoon or find a code name and > tag it with a release number when we are close to our first milestone/alpha > release? > > I don't know if "3.0" is a good "name" or not, but I would really appreciate it if we try to release a 2.2/2.3 before a 3.0! Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Finding a name for OSGi based Cocoon
On 5/8/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: ...WDOT, should we use "Cocoon 3.0" for OSGi based Cocoon or find a code name... I'd go for "Cocoon 3" as the official name, Cocoon 3.0 as the first release. It's still Cocoon, with many of the same things, yet fairly different inside, so a change of major revision number makes sense. -Bertrand
Re: Finding a name for OSGi based Cocoon
Reinhard Poetz wrote: > Sylvain Wallez wrote: > >> My ideas, which are progressing slowly because of the lack of time, >> are really diverging from the current code base. So, if they one day >> come to life, I doubt they will deserve the name "Cocoon". > > I'm looking forward to hearing from your ideas. I think that the > architectural changes of Cocoon 3.0 will make it much easier to > experiment again in a "safe" way. I'm currently going more on the "full-Java" side of things rather than the declarative way with XML files. The use of JDK 1.5 annotations allows for very clean and powerful things examplified by Stripes [1]. For complex forms, Wicket [2] uses the same kind of component model as CForms, but in a pure Java way, and is very powerful. All this goes in a direction that's very different from Cocoon, which is about declarative programming and allows people that don't master Java to do great things. My current project has *no* XML configuration file: I wrote a small library to do sitemap-like URL matching and request dispatching, we use PicoContainer, pure servlets, Velocity and Wicket. There's no need for complex or multi-format presentation and therefore no need for pipelines yet. I guess the no-XML approach is a kind of overreaction to the all-XML that I've used for years, and that truth lies somewhere in the middle. It does work well, though... That being said, I'm more than happy to see the architecture of Cocoon evolving towards a less monolithic way based on servlets. This is one of the key changes that can allow Cocoon (or parts of it) to be integrated into other environments. Keep up the good work! Sylvain [1] http://stripes.mc4j.org/confluence/display/stripes/Home [2] http://wicket.sourceforge.net/ -- Sylvain Wallez - http://bluxte.net
Re: Finding a name for OSGi based Cocoon
Sylvain Wallez wrote:
My ideas, which are progressing slowly because of the lack of time, are
really diverging from the current code base. So, if they one day come to
life, I doubt they will deserve the name "Cocoon".
I'm looking forward to hearing from your ideas. I think that the architectural
changes of Cocoon 3.0 will make it much easier to experiment again in a "safe" way.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Finding a name for OSGi based Cocoon
Reinhard Poetz wrote: > I slightly prefer "Cocoon 3.0" as we/I have been using it for a long > time for OSGi based Cocoon and Daniel and I are sure that OSGi-based > Cocoon can be the platform to implement many ideas that were raised in > Sylvain's Cocoon 3.0 thread. My ideas, which are progressing slowly because of the lack of time, are really diverging from the current code base. So, if they one day come to life, I doubt they will deserve the name "Cocoon". So +1 for Cocoon 3.0. Sylvain -- Sylvain Wallez - http://bluxte.net
