Re: Axion / Derby status?
And since they are slated to go to the DB project after incubation, you could watch for news there. John McNally Martin Cooper wrote: You'd likely get better answers on these if you ask the folks in the incubator, since that is the path into the ASF for both of the projects you're asking about. See: http://incubator.apache.org/ My understanding is that the Axion folks wanted to wait until they're done with their 1.0 release at Tigris before moving the code over. I don't know about Derby. -- Martin Cooper On Thu, 30 Sep 2004 13:11:48 +1000, Mark Livingstone <[EMAIL PROTECTED]> wrote: Hi Guys, Could someone in the know :-) please tell me what the hold up seems to be with Axion moving into the incubator from it's current Tigris site? From an outsiders perspective nothing seems to be happening. Likewise (as appropriate) for Derby? TIA MarkL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tapestry joins Jakarta
On Sat, 2002-10-19 at 17:53, Andrew C. Oliver wrote: > Being the big moron I am, I don't see any of these issues to be as > important as: 1. Do they develop in "the apache way", 2. Is it a > vibrant robust community, 3. Is there any point at all. . . > The point is apache had a project with similar ideas and it died. Was it ahead of its time? Or are there fundamental problems with the approach that still exist? I am willing to accept that it was just too large an undertaking at the time - about 4 years ago, for the developers involved. But I would be happier, if Howard pointed out why Tapestry is setup for success when a precedent exists that proves developing a community around such an idea is difficult. john mcnally -- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>
Re: [PROPOSAL] Tapestry joins Jakarta
I have taken a closer look at Tapestry and it does provide a quite a different strategy for web application development than Turbine and probably also Struts. It's very well documented and the code looks well written also. I would be willing to drop my -1; I would like to hear a comparison with the failed spfc project though. <http://cvs.apache.org/viewcvs.cgi/java-spfc/docs/index.html?rev=1.10&content-type=text/vnd.viewcvs-markup> It seems like a similar idea, or am I wrong? I liked the idea of spfc. Though the change in perspective needed to think of a webapp in terms of event driven components was considered too great a stretch, I guess. Is such an approach gaining more acceptance, or have I missed the point of Tapestry? john mcnally On Sat, 2002-10-19 at 16:22, Pier Fumagalli wrote: > On 19/10/02 19:49, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote: > > > So could someone clarify that for me... We're here to promote community > > software developmentas long as they don't overlap? sorry I totally > > misunderstood the apache way. (especially with all the overlapping > > projects to the contrary) > > I want to start a new project for a new Servlet Container that is not > Tomcat! :-) Let's see how many fans I'm going to get! :-) > > Pier > > > -- > To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>
Re: [PROPOSAL] Tapestry joins Jakarta
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>
Re: [PROPOSAL] Tapestry joins Jakarta
-1. Jakarta already has two webapp frameworks and I do not see any reason to add another. It is great that Tapestry uses several jakarta technologies; I would like to see some evidence of the Tapestry community being involved in the jakarta projects of which it makes use. One other warning sign I see is that the second sentence on the homepage: Tapestry is a powerful, open-source, all-Java framework for creating leading edge web applications in Java. Tapestry has been developed by Howard Lewis Ship. Even though the project has other developers, such a statement so boldly displayed, is a red flag. Not that other essentially one man projects have not attracted developers at jakarta, but, again, jakarta already has 2 webapp framework projects. john mcnally On Fri, 2002-10-18 at 07:29, Ship, Howard wrote: > Background > > Tapestry, currently housed at the SourceForge (http://tapestry.sf.net), is >component-based web application framework. Tapestry falls generally into the >pull-MVC model of development. > > Tapestry is designed specifically around the creation of completely re-usable >components. Components can easily be packaged into libraries and distributed as Jar >files, even when they contain assets such as image files and stylesheets. > > Tapestry is organized around an abstraction that isolates application-specific logic >from the details of the servlet API, such as HttpSession, request, response, URLs and >query parameters. > > Tapestry is highly pluggable, allowing any and all behavior to be customized by >subclassing appropriate base classes. > > Tapestry is specifically not a JSP taglib, though future enhancements (scheduled for >the next release) will allow it to partially act as one. Tapestry uses its own >method for instrumenting HTML that is extremely non-obtrusive (it still previews >properly in a WYSIWYG editor). Tapestry has well specified, separate roles for HTML >producers and Java developers, and allows them to work together without interfering >with each other. > > The goal of Tapestry is to shift much of the burden of developing web applications >onto the framework, and free the developer to work cleanly and effectively without >concern for the many small details of web application development. The primary >function of Tapestry is the automatic creation of URLs by the framework, facilitating >a fine-grained dispatch model. The bird's-eye view is that, in Tapestry, actions >(such as clicking a link, or submitting a form) are associated with a particular >component and, through a simple delegation system, a particular bit of user code. >There is no global registry of actions, as in Struts, and it's easy to create >reusable components that define their own behaviors (in terms of links or forms), >independent of the containing page. > > Tapestry applications can be extremely sophisticated with surprising little code. > > Tapestry includes a significant amount of documentation describing its strengths and >features in great detail, available at http://tapestry.sf.net. Live demos, a great >collection of user quotes, extensive documentation (HTML and PDF) and a recent code >coverage report are all online. > > Tapestry has been an open-source project on SourceForge since June 2000. Milestone >releases (such as 2.1 in July, or the just-released 2.2) result in 6K - 7K downloads >(increasing by over 1K downloads with each successive release). Tapestry has >averaged over 3000 downloads a month during 2002, with peaks above 8K/month. > > Tapestry would benefit from Jakarta in terms of greater exposure and acceptance, but >also in terms of better infrastructure, such as Bugzilla and Maven. > > Tapestry is currently in the Java package net.sf.tapestry; this could easily be >changed to org.apache.tapestry. > > Tapestry is currently licensed under the LGPL, but relicensing under the Apache >license is completely acceptible. The main criteria used when selecting a license >three years ago was that Tapestry be open source and reusable even in proprietary >software, and both licenses ensure that. > > In order to spur discussions, I've worked through the list of criteria and warning >signs (as per http://jakarta.apache.org/site/newproject.html). Pardon the use of >third person in reference to myself (it seemed appropriate for prose that will likely >be cut and pasted frequently). > > Criteria > > Meritocracy: Tapestry is currently a benign dictatorship, but it has been Howard >Lewis Ship's intention, even prior to considering a move to Jakarta, to organize >around more democratic principals. > > Community: Tapestry has a modest, but very active community, centered around a >mailing list (approx. 17
Re: Differences between Structs and Turbine ???
This is not really the correct place, but a short answer is struts is jsp-centric while turbine attempts to be neutral on the actual templating mechanism. Given that most jsp developers gravitate to struts means you get the best support if using velocity within turbine. Struts most certainly has more users, but the turbine developer community is healthy. I'm pretty sure both will survive. john mcnally On Sat, 2002-10-05 at 11:08, Dominic Gagne wrote: > I hope I'm asking the right mailing list ... I'd like to know the > differences between Struts and Turbine project. I'm currently using Turbine > framework to build a web application and I see that Struts could offer me > the same kind of solution, am I right ? I would also like to know which > project in moving faster and has more chance the stay alive ? > > Thanks, > Dominic > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Issue tracking
Thank you. Now is there a mysql client on this box? john mcnally On Thu, 2002-09-26 at 17:31, Pier Fumagalli wrote: > On 26/9/02 22:54, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote: > > > Emacs? I don¹t see the reason for a 25 megs editor on a server machine > > Err... Correction, just compiled version 21.2 and it's actually 121 Mb... > It's as big as my entire home server operating system (NetBSD 1.6)... DOH! > > Oh, good old beloved "vi" (220 Kb) > > Pier > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Issue tracking
I made a request for access to nagoya so that I could take over maintenance of the scarab installation there. I never heard back from you; I would/should have followed up, but Jason made the offer of the werken.com box so I took him up on it. I don't see a reason to keep two instances of scarab going. No one is maintaining the one on nagoya. And if the decision is going to be that it has to be on nagoya or else... I will work towards that as I see no reason to fight over it. I like the werken.com setup of linux and a working up-to-date emacs installation, but hopefully nagoya at least has the later? john mcnally On Thu, 2002-09-26 at 03:10, Pier Fumagalli wrote: > "Scott Eade" <[EMAIL PROTECTED]> wrote: > > >> From: Pier Fumagalli <[EMAIL PROTECTED]> > >>> On 26/9/02 3:04, "Scott Eade" <[EMAIL PROTECTED]> wrote: > >> > >>> This instance was set up > >>> as it apparently proved difficult to gain the necessary access to maintain > >>> the Scarab instance at issues.apache.org/scarab. > >> > >> We already have a setup of Scarab on nagoya.apache.org, which of course is > >> _already_ has an alias as issues.apache.org > >> > >> If you want to use scarab, use nagoya and update that installation, let's > >> not redo the whole thing again and again and again... > > > > As stated in the original message, it was deemed to difficult to obtain the > > necessary access to maintain the instance on nagoya. As things currently > > stand we have the nagoya instance that is un-maintained with only one > > project using it and we have the up-to-date werken instance with one project > > actively using it (and four more that have agreed to) and two people > > committed to maintaining it. The newer instance is hosted at a very ASF > > friendly location who are happy to provide their resources and the access > > necessary to maintain it. Why not follow the path of least resistance? > > Sorry, if you had troubles accessing Nagoya, it has been most definitely my > fault. The original idea to set up Scarab on Nagoya was that once some > projects had the confidence of the install, all other projects would have > moved as well, so, I still think that installing it on a central location is > a good idea... > > If you, Jason and Bob want to maintain that instance, just let me know and > I'll grant appropriate karma, otherwise, I believe that at the end we'll > have 3 bug tracking systems: two on nagoya, and one wherever you guys want > to put it... :-/ > > Pier > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Objectbridge and JDO: Licensing issue
On Sat, 2002-05-25 at 11:00, Florian Bruckner wrote: ... > > My understanding of this paragraph is, that we'd only be able the JDO part > > of OJB under these conditions and only for research. This implies that > we'll > > not be able to release a "production quality" version of OJB-JDO. What we > > jave to go for is a "clean-room" implementation, the requirements for this > > are stipulated in the license of the JDO specification: > You state that this is a problem of moving to ASL. Is this not a problem regardless of license? Note that Apache has negotiated the ability to implement JSR's. From the press release http://jakarta.apache.org/site/jspa-agreement.html "This is the result of extended dialog over the past year. Sun has pledged to use licenses that enable open source independent implementations for all its Java specifications and Test Compatibility Kits. Sun has pledged this for all future Sun-led Java specifications as well as key specifications already released." Whether JDO is one of the "key" specs is unknown by me, is there somewhere where this list is available? I also remember Jason van Zyl making a comment several months ago that we had won the right to implement the JDO spec. But I only say that so that you may ask him where his info came from, or if I am recalling correctly. Do not take it to mean anything else than that. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Criteria for commit access
On Fri, 2002-05-24 at 17:06, John McNally wrote: > The site docs say it can happen after 6 months of inactivity. Though I > can't seem to find the location atm. http://jakarta.apache.org/site/roles.html My question is how does it happen? > > john mcnally > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Criteria for commit access
The site docs say it can happen after 6 months of inactivity. Though I can't seem to find the location atm. My question is how does it happen? john mcnally On Fri, 2002-05-24 at 16:39, Pier Fumagalli wrote: > Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > > >> > >> * Perhaps a more fruitful topic for us to explore is when to retire > >> committer status due to inactivity. Pier is one of the few to do this > >> explicitly. I have done it a bit more implicitly - including submitting > >> patches to projects that I am officially a committer to. > >> > > > > yes. I recommend whatever the general guideline be that it recognize > > historic contributions. Something like "Honored fellow" so that the > > person is still on the "contributers" page but listed as inactive > > without any insulting connotation. > > Members have the concept of being "emeritus" (emeriti, my Latin's getting so > bad). The idea that any emeritus could get back to full status whenever he > wants. The only thing is how we want to decide when someone becomes an > "emeritus"... > > Pier > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Bugzilla usage
On Tue, 2002-05-21 at 07:14, Pier Fumagalli wrote: > Great, Andy, you're recruited... We need to get Scarab 1.0b7 up on Nagoya. > > The only "issue" I have with it (but Jon promised to "fix" it before going > 1.0 final) is that we can't associate a particular issue with one given > "user-attribute" default... So, issues will never be Cced to the appropriate > mailing list. We can have all mail generated by scarab copied to a single > address (and then filter on -for example- the subject line), but I want to > dig into it a little bit more... The latest cvs does allow you to specify the email that gets CC'ed on a per module basis. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Database Subproject Discussion : creation of DBCommons ?
I think ojb can do things like map a set of related objects to xml as well. Its not completely database centered. (I know very little about ojb, so feel free to dispute that. Just thought I would bring it up in case those that know better, are tuned out.) john mcnally On Thu, 2002-05-02 at 15:33, Peter Donald wrote: > Hi, > > OJB deserves to be a peer to other projects alongside ant, avalon, struts etc > > A somewhat better idea IMO would be to use OJB + Torque as a trampoline for a > new top-level project "db.apache.org" (or insert something more snappy if you > want). So much like xml.apache.org deals with XML, db.apache.org will deal > with databases (maybe even collaborate with xml.apache.org/xindice in > future). > > While this new db project is gestating we can cross link it extensively from > the jakarta website. After they get off the feet we talk to it the same way > we talk to xml.apache.org ? > > On Fri, 3 May 2002 07:33, Geir Magnusson Jr. wrote: > > I hate to interrupt all the good fun over standards, bike sheds, and > > general good community feelings, but I would like to solicit community > > opinion on something unrelated to DVSL or Jon Stevens (both of which I > > like, btw...) > > > > Recently, it was proposed that ObjectBridge be brought to Jakarta as a > > subproject. > > > > Costin suggested, and I supported, that a subproject of wider scope be > > created to allow the collection of similar technologies into one larger > > subcommunity (that isn't an exact quote, but I think he'll agree in general > > with that.) > > > > The idea would be to bring in ObjectBridge, but create a Commons-like > > environment in which other projects can be brought. Call it DB-Commons as > > a working name. > > > > There are some good reasons, including community alignment, inter-project > > synergy (there, I used the word in an Apache-related post), and ease of > > discovery for new users and developers. > > > > Off the top of my head, in Jakarta we have lots of db related tools already > > (Torque, commons-dbcp, and I am sure others...), and having a db-focused > > subproject in which they can be brought to with a lower barrier than > > 'fullsubproject' might be very benficial. > > > > We already have the successful Commons model to use as a starting point. > > > > Anyone have any comments? > > -- > Cheers, > > Peter Donald > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: jakarta subproject scope (was Re: Quick! convert allyour projects to maven!)
On Tue, 2002-04-30 at 20:38, Geir Magnusson Jr. wrote: > On 4/30/02 11:31 PM, "John McNally" <[EMAIL PROTECTED]> wrote: > > > I do not know where to locate Turbine's original charter and I think it > > is a good idea to try to follow it. Are these published somewhere or > > should Turbine maintain it in its own documentation? However the scope > > of a subproject is likely to grow/evolve over time. Velocity does > > provide at least one servlet that allows it to be used to develop a > > webapp independent of any other framework. > > I think that's stretching 'webapp' I guess tomcat does the same thing as it > supplies servlets... :) Well I would not be bothered if tomcat had developed a build system that it packaged as an independent entity with the idea that it might be more generally useful. Tomcat is a large project and they certainly could have had the itch. And if they promoted it occasionally what's the big deal. > > > Struts is adding support for > > Velocity even though one of its primary reasons for being proposed with > > Turbine already existing was to limit the view to jsp exclusively. > > I think you are mistaken - we are building a toolkit to use Velocity as the > view layer in Struts Struts isn't adding any support AFAIK. > Okay, I guess I could argue that developing a taglib (or something more elaborate) is outside the scope of a project around a template engine. Except that I am arguing against such strict definition of scope. And from what I saw I thought it was pretty cool. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
jakarta subproject scope (was Re: Quick! convert all your projectsto maven!)
On Tue, 2002-04-30 at 19:09, Andrew C. Oliver wrote: > In truth I think thats a good idea. So since Maven is under Turbine and > really is a bit out of scope, how about moving it over to Krysalis and > combine it. How is a build system out of scope of Turbine. Isn't it up to a subproject to decide what is out of scope? Turbine is a webapp framework and webapps require build systems. It also contains several subsubprojects (ssprojects) that offer some variation so it is a good candidate for developing a general build system. It may not be the best way to market the code for more general use, but if and when the ssproject generates some interest outside Turbine it can be proposed as a true subproject or moved to the commons depending on size/scope. I do not see why other projects cannot use something just because it lives in Turbine. Turbine has had a history of using other projects. I do not know where to locate Turbine's original charter and I think it is a good idea to try to follow it. Are these published somewhere or should Turbine maintain it in its own documentation? However the scope of a subproject is likely to grow/evolve over time. Velocity does provide at least one servlet that allows it to be used to develop a webapp independent of any other framework. Struts is adding support for Velocity even though one of its primary reasons for being proposed with Turbine already existing was to limit the view to jsp exclusively. I'm sure some example of feature creep will be found in many subprojects. John McNally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
