Re: Notice of intent.... #2
On Wed, 11 Jan 2006, Will Glass-Husain wrote: Thanks, Henri. My feedback. Thanks, very useful stuff. * Generally positive with an aversion to anything involving significant work for the sake of a cleaner Jakarta. By this I mean that I like the idea of a flatter hierarchy and a clearer message to the public as to what Jakarta is about. As I noted on the Velocity list, 4 years ago I discovered Velocity after identifying Jakarta as a cool Java project resource and then browsing through every project looking for useful libraries. We should encourage that. Yep. I need to post on Idea #3: Jakarta as Java federation at some point :) Which mainly means having links and decriptions to other Java projects at Apache and making [EMAIL PROTECTED] more of a discussion list than Jakarta business list. * I'm skeptical about the common build and web site part of your plan. Agreed that technical issues may cloud this one. Having common structure allows for people to work on each component more easily; but more importantly it forces us into a single community. It also stops components becoming component trees. ie) I'll be pushing for velocity-tools to be a separate component from velocity. Guess an SVN reorg will probably be in the works at some point :) One part of common build is that each component produces only 1 deliverable. Not sure if that's worked perfectly in Commons, a few components have a couple of jars, though 1 is always the most important (much like velocity/velocity-tools). Producing 1 deliverable stops subcomponentizing. Seems like an awful lot of reorg work for little purpose. Many sites have a maven site build. Who is going to integrate all of the projects so that the individually desired features appear on each site. Same for building. Velocity has a mildly customized build script that compiles differently under JDK 1.3 and JDK 1.4/5. If we go to a master web site and build this will make it too difficult to introduce changes to the proces and will stifle innovation. Better to keep this at the subproject level. (Note: *goto jail, do not pass go* s/subproject/component/ No more subprojects :) Jakarta-wide style guidelines with common fonts, colors, logos would be a great idea though). Good point. Common general lf binds us together more. * Also, I'm against changing the project names. Velocity (for example) is a recognizable brand name. Calling it Jakarta Template Language or something similar would be foolish. It'd be Jakarta Velocity; but it might fall in the TemplateLanguage group. I think we'll need groupings for sanity's sake, but we have to avoid them gaining character. They're just vague tags and not actual subprojects. * On a positive note, establishing a standard template for web site format and build would speed up the introduction of new subprojects. We could migrate the common subprojects to a standard, and encourage new subprojects to use it. But if a group wants to modify this template for one piece of it - why not? (as long as they keep some common Jakarta fonts, colors, etc). Right. Individual character is important. Same with the build; as long as it's largely the same, individual bits to handle individual issues are fine. We just need to have the norm be to be similar. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
Almost completely +1. One thing first : http://java.apache.org, redirects to archive.apache.org, while I still know people that are think java stuff stuff on apache.org is happening there, so maybe a redirect to a more friendly page could take place there ? (though this could be something for infrastructure/board). Henri Yandell wrote: * 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. Just to make sure I get what you are saying : If you become a committer on jakarta, a vote will be helt automatically after 6 months (initiated by you/the Chair?), but not to accept the committer, but to not accept the committer becoming a member of the PMC ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 10 Jan 2006, Martin van den Bemt wrote: Almost completely +1. One thing first : http://java.apache.org, redirects to archive.apache.org, while I still know people that are think java stuff stuff on apache.org is happening there, so maybe a redirect to a more friendly page could take place there ? (though this could be something for infrastructure/board). Hmm. I'll mention it, there might be legal issues in active use of the name. Henri Yandell wrote: * 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. Just to make sure I get what you are saying : If you become a committer on jakarta, a vote will be helt automatically after 6 months (initiated by you/the Chair?), but not to accept the committer, but to not accept the committer becoming a member of the PMC ? That's effectively the level I'd like to take it to. Really drive home the 'everyone should be on the PMC' meme. It's not much different than what could exist today; ie) the chair calling votes based on time since committership; so it's not a biggy - the important part is making a smooth pipeline to the PMC. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On 1/10/06, Henri Yandell [EMAIL PROTECTED] 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. * 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. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. 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. 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. * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. * 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. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated 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. A separate mailing list for the sandbox would be a double-edged sword.Yes, it would keep the noise out of other mailing lists, but it also, at least, partially condemns sandbox components to death, by limiting their exposure much more than now. And if everyone has to subscribe to the sandbox list anyway, to know what's happening, then a separate list is of limited utility. -- Martin Cooper - Shout, scream, yell :) Hen On Mon, 12 Dec 2005, Henri Yandell wrote: dum de dum de dum. Just to be public so that it doesn't look like I'm sneaking around trying to manipulate things. -- I'm starting to open the question of TLP on many of the Jakarta dev mailing lists. It's with a general plan where we would see another half a dozen subprojects move to TLP and then really leave Commons as the main entity inside Jakarta along with some commons-like components that are currently subprojects. I've been talking unofficially with lots of people at ApacheCon, so I've had a fair bit of feedback on various bits. The important part is that the loose plan above finds a way to coalesce the Jakarta community into a much tighter, more TLP e like project. I've talked with a couple of board members to feel out things would be. One question being, is it a problem if we're pushing a TLP with just a few committers. The answer I had was that Excalibur is the example TLP, it's rather dormant and it's not a problem. I was also advised to be a bit more active in pushing forward. I think this makes sense, a lot of our cross-community activity is gone because people with high activity tend to move to TLP, so we need a bit more drive to get things done. Thus the change of tack that I'll be trying to pull off without getting hung :) Please discuss, argue, wibble; but what I'm looking for are active ways forward instead of maintaining the status quo. I don't think the status quo is good for Jakarta as an entity, it puts strain on our oversight because the number of subprojects stretches the chair's and community in general's ability to keeps things covered. *denies the blindfold and stands against the wall waiting* Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: comments on a project
At first I tried to use JSP without any framework or taglib. In contrast to templates JSP doesn't help much on seperating logic and html code Please see the JSP 2.0 Specification for Tag Files. Tags are your friends, and Tag Files make them easy to write. And I could not get used to the Model View Controller concept. Very simple concept. Documentation (and examples) often over complicates it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: comments on a project
Others may disagree, but personally, I always liked the Maverick MVC framework. It's very simple, has no excess baggage. I've found it a good approach to MVC for those new to the concept. You might take a quick look. http://mav.sourceforge.com As an aside, also check out the Velocity project for an alternative to JSP for web page design/templating. Again, very simple approach. http://jakarta.apache.org/velocity (disclaimer: I'm just a user of Maverick but am involved in the Velocity project). Cheers, WILL - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: Jakarta General List general@jakarta.apache.org Sent: Tuesday, January 10, 2006 12:11 PM Subject: RE: comments on a project At first I tried to use JSP without any framework or taglib. In contrast to templates JSP doesn't help much on seperating logic and html code Please see the JSP 2.0 Specification for Tag Files. Tags are your friends, and Tag Files make them easy to write. And I could not get used to the Model View Controller concept. Very simple concept. Documentation (and examples) often over complicates it. --- Noel - 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: Jakarta subproject-package system
On Wed, 2005-12-28 at 09:55 -0100, jan meskens wrote: Hello Henri, I was looking to these page : http://jakarta.apache.org/commons/charter.html Maybe that's the wrong page for these info... . not wrong probably just a little confusing the jakarta commons charter encapsulates the opinions of the jakarta pmc at that particular moment in time. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: On 1/10/06, Henri Yandell [EMAIL PROTECTED] 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. * 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. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. +1 gave up groups (topological or even finite simple) when i left uni ;) I also think we should allow the component:grouping relationship to be 1:N, since not all components will fit tidily into a single grouping. As a corollary, I don't believe groupings should have their own mailing lists. not sure i like the idea of fuzzy groupings with 1-N components need to be mapped 1-1 to dev mailing lists but 1-N would work fine on user lists. might be possible to factor 1-1 dev lists (for traffic purposes) whilst retaining fuzzy users lists. 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. 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. * No svn authentication beyond being in the jakarta group. Velocity coders have rw access to POI. * 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. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Notice of intent.... #2
On Tue, 10 Jan 2006, robert burrell donkin wrote: On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote: On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote: * 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. I prefer the term groupings (which, interestingly, you switch to below ;) over groups. +1 +1. You're right, groupings is much better. * 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. Well, except that the process is that the PMC has to vote in a new committer to the PMC and then notify the board of that vote. I'm definitely not in favour of magic notifications to the board when the six months are up, without an associated vote. i don't like the idea of magic notifications (to the board) but something needs to be done: ATM we're dysfunctional. just take a look at the nominations per nominator over the last year or two: nomination hasn't become ingrained in the culture. ATM we're slipping up but maybe statistics and reminders may be better for the moment than automatic nomination... +1 to reminder. The board list has a reminder to chairs to submit their report. We should have a similar thing, a reminder to [EMAIL PROTECTED] that the following people should be considered for the pmc. Easiest method is to have something that compares svn structure for jakarta (easier when we have only one auth) and the committee-info.txt file. Doesn't catch new committers who are not in svn yet, but a good 80/20. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
