So could someone clarify that for me... We're here to promote community software development....as long as they don't overlap? sorry I totally misunderstood the apache way. (especially with all the overlapping projects to the contrary)
-Andy On Sat, 2002-10-19 at 14:29, John McNally wrote: > On Sat, 2002-10-19 at 06:33, Sam Ruby wrote: > > John McNally wrote: > > > -1. > > > Jakarta already has two webapp frameworks and I do not see any reason to > > > add another. > > > > It is a non-goal of Jakarta to have only one webapp framework, or to > > limit itself to two. > > > > - Sam Ruby > > > > If a project is proposed that overlaps a (or a few) current project, I > just think the bar needs to be a bit higher for approval. If someone > proposed another java regex package, I think many people would want to > see distinguishing features and even if a few existed, it should be > clear that it would be extremely difficult to add the functionality to > one of the current projects or an attempt has been made to work with one > of the current projects and the communities are incompatible. > > With database connection pools, I think there were 4 implementations > floating around the jakarta projects. When I started to look at > upgrading turbine's version or dropping it for one with the features I > was after, I was unable to find a replacement. This included a survey > outside jakarta where I investigated PoolMan. Unfortunately I did not > look into avalon's pool which may have met my requirements, but > misconceptions led me to overlook it. So I set about to create the cp > that implemented the current api's as specified by jdbc. I still did > not want to do this within turbine, so I engaged the connection pool > project in the commons. Now it turns out the developer of PoolMan > wanted to stop development and it was proposed that it be brought to > apache. > > I would have said the same thing: jakarta already has a couple database > connection pools, why do we need this one. And in addition the ones > that are here already implement the latest specifications, while this > proposed one does not. But PoolMan has name recognition, so it is able > to overcome my resistance to add YetAnotherDBCP. And it has a member of > Apache who is pushing its adoption, which helps to alay my concerns > about lack of a developer community, though not completely. > > I think one of the goals of jakarta is to create high quality > implementations of recognized standards and another is to try to create > standards where they do not formally exist by developing a high quality > technology that is able to become a defacto standard. > > As much as I hate it, JSP is the recognized standard for webapp > development. Jakarta's development of a general purpose java templating > technology, Velocity, is a valid alternative and is not even in direct > conflict with JSP. But it is a simple, powerful alternative to JSP as > well. Does tapestry give us another alternate template system that is > only usable within the framework? > > Granted I could try to investigate Tapestry in depth to answer all my > reservations, but I'm busy and on the surface the project seems to > overlap several existing projects. My -1 is not a statement that > Turbine (or Struts, Velocity, Avalon) should not have any competitors > within Jakarta. I would prefer that Tapestry make the case that it > offers something that these projects do not and I don't think the > original proposal makes the case forcefully enough. > > john mcnally > > > > -- > To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org> > -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>
