> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > > Throwing away hard work and community development for a clean > > slate isn't very good either. > > Please, tell me: why are you becoming defensive? > > My question was: why can't we agree on working toward *ONE* > implementation of the framework that fits everybody's needs > (like we do > in Cocoon)? > > And the end of your reply was the above sentence.
You also seemed to miss everything else I said in the email. We are working and inching toward a common model. It's just that we are taking different paths to get there. > Let me be brutally honest with you: the perception I get from > Avalon is > that it has become a 'visibility contest'. > > There is *NOTHING* technical into that. I'm worried, the > projects that > depend on avalon are worried, the ASF board is worried. > > Can we please start doing something for this? Sure. Let's start focusing on the specification and container compliance test suite. Then we can make a brain-dead reference implementation to show how the contracts work like J2EE does. >From there we can move the three different implementations outside of Avalon. If necessary, we will move them outside Apache, but I would rather not. The thing is that not everyone's needs are the same. There is room for other implementations of the container. Some will only need a brain-dead container while others will need some complex or robust functionality. > There is one framework, there should be one implementation > in-house and > as many as you like outside this community. I'm fine with this. Yes. However consider the impact to the community if we suddenly remove Fortress, Merlin, and Phoenix and put them at different locations. Now we have our reference implementation, and everything that goes with it, but we have lost developers to new communities. Can we continue inching toward the common goal instead of what the revolutionary approach that you seem to be proposing? BTW, speaking of harming the community I want all private communications regarding whether members stay or not to stop. Removing threats from the public mailing list and placing them in private communications is no way to build a community. IMNSHO this is far more damaging than multiple containers. I am privy to one instance, and I do not want to hear of another. If I do, I will escalate that matter very quickly to the board. > So, let's start from the functionalities that all container > users want > and let's build a community from that. Code will come. Code will be > reused from what avalon already produced. What will be thrown away > hopefully is the "I'll do my own thing since we can't reach > consensus" > attitude. How about the experimentation question? > So, ask my simple question: would you (Berin and each one of > you) like > to work on a single avalon container that serves all of your needs? All our needs range from J2EE embedded applications like Cocoon (Servlets is a J2EE spec even if that is all you are using) to stand-alone apps. There might be need for a J2ME compliant Avalon as well. I think we need a tiered approach. I.e. an Avalon compliance level based on deployment issues. That means we would have to have at least two containers (J2ME compliance would be too restrictive for J2SE and J2EE applications). We can probably come up with something that would support both the J2SE and J2EE tiers though. > I'm not saying it's easy, I'm saying that it's the only way I > see we can > resume the health of this community. Speaking of, do you have any requirements that are not addressed by *any* of the existing containers for Cocoon? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
