Re: comments on a project
Dennis Kempin wrote: Hello Ortwin, * You mention problems with JSP. What are they? At first I tried to use JSP without any framework or taglib. As you are coming from PHP that approach seems somehow natural, but of course is totally wrong. In contrast to templates JSP doesn't help much on seperating logic and html code, That's why we need webapp frameworks. because you still need comparatively much code to iterate over Lists, or print out some text. This is where taglibs come into play. And I could not get used to the Model View Controller concept. You said earlier that in your framework All commponents have a template and a class file. Template = View, Class file = Controller. You also mentioned a persistence layer. You can not have a persistence layer when your model is not separated from the rest. All this implies you have implemented the MVC pattern in your framework. I don't see how you can not get used to it then. * Which frameworks do you mean and what's the problem with them? I tried many of these GUI-Like Frameworks at first, but well I wanted to create a small Discussion Forum, and these Frameworks have not matched this target. I also gave Tapestry a try. I really liked it, but I dont like this Action, Objects and Methods instead of Pages and URLs concept. The most other frameworks I tried implemented the MVC pattern Because it's a natural and proven design that has evolved over the years maybe? and used a lot of xml configuration, and looked to me very complicated. You got a point there. Many frameworks indeed rely on overly complicated XML configuration and often offer no way around. But sometimes it's worth diving into it because you get a lot in return - Spring's bean factory for example. * What does you framework make better? Well I dont know if it is a subjective opinion of mine, but my target is to make the development as easy as possible. Sounds good. I had this framework in a slightly different form nearly completly implemented, used it and tried to make it easier whereever it was possible. It was easy to implement a component that displays a paged dataset, and reuse it with just one or two lines in the template. Does it do anything else apart from being just easy? Then my laptop HDD crashed and my last backup was a few weeks ago, so I decided to reimplement it, and add a few new concepts. Sounds sad, but doesn't answer my question. I found it just -easy- to create pages with that framework, and when i look at other framework i dont think that i would like them as much as i liked my framework (well that is pretty much a subjective oppinion of mine, but I find it hard to explain without examples). * Why do you invent a proprietary XML scripting facility? JSTL is standard and there are numerous development tools readily available. I havent looked at JSTL that much, because it has gone to the trash in my brain just with jsp. I am afraid you completely missed the essence of JSP by this oversight. I just looked around and think that i really should try to use it instead of implementing my own template engine. That would be reasonable. well you dont disencourage me, but you make me think of special topic of the framework, and that really helped me. thanks. I hope that I get more comments on this greetings Dennis Please pardon me for my basic english. Your original request was that you would like to put your project into Jakarta. Well, that's not simple. It needs a bit more than just a good idea and intention. To make that happen the project technically needs to go through the Incubator: http://incubator.apache.org/incubation/Incubation_Policy.html As you can see you need a Champion and get Jakarta as a Sponsor. Given the reluctant feedback to your request I doubt that you will find sufficient support here. Maybe it's easier for you to put your project on Sourceforge which can be done in a matter of days. There you get the chance to build up a greater community and give people the chance to actually look at your project. If the project is successful you can always try Incubation. Many projects have been on Sourceforge before they came to the ASF. Kind regards Ortwin Glück -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta stats
Robert got me looking at various Jakarta stats in a recent email of his. Gave me something to do while I waited for a plane at 5am this morning :) So, here's a dump of stats. A committer is defined as somebody with svn access. 316 committers in Jakarta. 107 on PMC, 209 not on PMC. 8349 commits in 2005 from 121 committers. (5768 from 90 committers in 2004, 30 of whom did not commit in 2005) 30 committers only have access to jakarta-pmc or jakarta-site. Quick report of # people committing to N subprojects; not including site/pmc and merging commons and commons-sandbox into one. People - Components 30 - 0 176- 1 74 - 2 18 - 3 12 - 4 3 - 5 2 - 6 1 - 9 So 30 people are not really committers, 176 only commit on one subproject etc. Bear in mind that you have to apply a filter of 2/3rds to see the active ones. So assuming a perfect balance, only 2 of the most spread 6 committers are actually active. Next up. Cross-community activity. Ignoring the 206 who do not cross a community, and the 6 who are all over the place (and probably doing infra things, project setp), the top ten combinations are: 32 - turbine jcs 9 - commons-sandbox turbine jcs 9 - commons taglibs 7 - commons slide 4 - commons turbine jcs velocity 3 - commons-sandbox taglibs 3 - commons httpcomponents 3 - commons turbine jcs 2 - commons tapestry turbine jcs 2 - bcel commons-sandbox Turbine/JCS is a misnomer, we copied the Turbine SVN over when setting JCS up. Commons makes up the rest. Ignoring Turbine/JCS, and ignoring Commons as a whole, what cross community is there committer wise. The entire list is: 5 - turbine jcs velocity 3 - hivemind tapestry 2 - turbine jcs taglibs 2 - poi slide 2 - tapestry turbine jcs 1 - slide velocity 1 - jmeter turbine jcs 1 - cactus slide 1 - cactus turbine jcs 1 - poi tapestry 1 - slide taglibs 1 - ecs oro regexp taglibs 1 - cactus taglibs 1 - bcel taglibs 1 - hivemind slide tapestry 1 - bsf poi regexp taglibs Some are obvious, some are because taglibs is commons-like in its community (I think), some are unexpected. The major reason for looking at this was to have scripts to point out how many committers are not on the pmc. 2/3rds of Jakarta. Of course, 2/3rds of Jakarta are inactive too. So back to the data. Comparing the active committers of 2005, against the PMC list, we get two interesting factoids: 1) Inactive PMC members : 39 2) Active non-PMC committers : 53 To finish it off: 3) Active PMC members: 68 === Next up I guess. Building svn logs for each project instead of Jakarta as a whole, so we can see where activity is, and whether we have oversight problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
Henri Yandell wrote: As a second email in the Notice of intent series; here's what I think being a Jakarta component will be like in the future. * Jakarta is a collection of components. Hopefully all sitting at the same level. ie) a big bag of things. How are you defining component? Something reusable? Something you build applications with? Something like a commons component? If that is the case, then Jmeter, Cactus, Velocity et al would have to go TLP. Is that part of the plan? * Groups exist. These are categorically not subprojects, but a way to allow for slicing of the website etc. Some groups may have their own mail list; thus the importance of making sure they don't become subprojects. An important rule will probably be that they must do votes on the main list. Hopefully we can keep it at a point where the groups are really just there to refine the flow of mail, not to separate it. HttpComponents is an example of this (though not a good one as most of its components came from HttpClient). WebComponents (formerly hoped to be known as Silk) is another example. Commons would be groupalized out. Not sure I understand exactly what you mean here, but if it means breaking commons up - even the list - I think we should think very carefully about that. From what may be a selfish perspective - and which I will back off from if the rest of the community feels otherwise - I think getting feedback from the full group of commons committers and voluneers *really* helps those of us who work on commons components. I am afraid that if we break up the dev list and we don't all just agree to subscribe to all of the sublists (really defeating the purpose), we will both have a harder time building community around components and we will lose some valuable feedback. We will also have less collective energy to apply to things like the site, how we think about versioning and releases, etc. We are developing a pretty good body of collective experience developing small java components and I think that if we split up now we may be losing something. Hopefully. Groupings are not vague names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The idea with that being that boring grouping names are intentionally dull, no subcommunity identification. +1 - as we at least used to state in the commons charter ;-) * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. +1 * Improved Committer-PMC process. Chair's responsibility (I've failed at this so far) is to turn around the new committer process. A new committer of 6 months is effectively voted against going to the PMC, not for. Might not be able to make it exactly that way, but the idea being that joining the PMC is the exception, not the norm. Personally I'd like to see committership be removed if people repeatedly are not allowed onto the PMC. Not sure about this one. I am OK with kicking off the nomination more or less automatically, but would prefer that it be a postive vote. * Application of Commons thinking. Not entirely sure on this one as I think we've overcomplicated things in Commons a bit; but things like a common build system, common site system etc. * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the same rules as it has currently. Probably a separate mailing list. I agree with Martin's comment on this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
