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
-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. 170 members) and the Tapestry Wiki (http://tapestry.sf.net/wiki). The Tapestry mailing list has an exceptionally good signal-to-noise ratio; discussions typically revolve around planning new extensions to the framework, creating new components and documentation, and diagnosing developer issues. Core
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.10content-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: 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: 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: 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: 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]
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]
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]
