Re: Jakarta at the center of the (ASF) universe
On Nov 18, 2007 1:14 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > On Nov 18, 2007 1:10 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote: > > > > > > But that's the fact - that most of JavaLand sprang from jakarta... > > > > > > > Jukka's graph shows committer cross-polination, not *codebase* > > cross-polination (as I understand it)... > > then you'd expect Harmony and Geronimo would connect with Velocity via Geir... > > i'm not sure what cross-pollination this graph refers to. Jukka, > could you clarify? ah. i RTFA. a connection requires 5 committers in common. i'd be curious to see the graph with the threshold set to 3 (as that is more of a magic number in Apache community stuff). :) > > > So yes, since most > > committers for most ASF java projects were in Jakarta (since > > those projects were *in* Jakarta, after all), I still think > > that the non-Jakarta page provides a more accurate representation > > of the "real" dynamics, by removing the artifical aspects of > > Jakarta. > > > > Of course, I could be wrong :) > > -- > > === > >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > > "Great is the guilt of an unnecessary war" ~ John Adams > > > > > > - > > 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 at the center of the (ASF) universe
On Nov 18, 2007 1:10 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote: > On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote: > > > > But that's the fact - that most of JavaLand sprang from jakarta... > > > > Jukka's graph shows committer cross-polination, not *codebase* > cross-polination (as I understand it)... then you'd expect Harmony and Geronimo would connect with Velocity via Geir... i'm not sure what cross-pollination this graph refers to. Jukka, could you clarify? > So yes, since most > committers for most ASF java projects were in Jakarta (since > those projects were *in* Jakarta, after all), I still think > that the non-Jakarta page provides a more accurate representation > of the "real" dynamics, by removing the artifical aspects of > Jakarta. > > Of course, I could be wrong :) > -- > === >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > "Great is the guilt of an unnecessary war" ~ John Adams > > > - > 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: Suggestion to use OpenGrok to index all Jakarta source code
On 9/1/07, Sriram Narayanan <[EMAIL PROTECTED]> wrote: > On 9/2/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Hmm. I'll put "learn how to set up OpenGrok on Velocity's Solaris > > zone" on my things-i-would-like-to-find-time-to-do-someday list. Of > > course, if someone more familiar with OpenGrok and/or installing > > services on a Solaris zone wanted to help me set it up for Velocity, > > then we'd have some example for other interested projects to work off > > of. ;) > > > > What help do you need exactly ? I can help. I'm not a committer, > though. I like Open Grok and gave a talk on it at the Javaone this > year. well, let's put it this way: i just heard about OpenGrok this morning and have never set up any application on our Solaris zone before. :) so, i don't even know what questions to ask at this point. right now, my weekend is pretty full. i think i can set aside an hour or two on Monday morning to educate myself a bit. Give me until then, and then i can probably answer your question better. > -- Sriram > > - > 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: Suggestion to use OpenGrok to index all Jakarta source code
Hmm. I'll put "learn how to set up OpenGrok on Velocity's Solaris zone" on my things-i-would-like-to-find-time-to-do-someday list. Of course, if someone more familiar with OpenGrok and/or installing services on a Solaris zone wanted to help me set it up for Velocity, then we'd have some example for other interested projects to work off of. ;) On 9/1/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > (off topic for Jakarta, I know) > > Velocity has it's own Solaris zone. We could set something up on an > experimental basis for Velocity, and if someone in Jakarta got excited about > it they could request a zone/set theirs up based on the Velocity config. > > WILL > > On 9/1/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > I would LOVE to have something like this for Apache projects. Looks > > much more useful than ViewVC. I particularly like that the source > > code view would be able to plug right into PMD reports to make those > > more useful too. > > > > On 9/1/07, Alf Høgemark <[EMAIL PROTECTED]> wrote: > > > Hi > > > > > > I have a number of times missed an an easy to use web interface for > > > searching through all Jakarta source code and subversion change logs, > > > and to also being > > > able to see line number and subversion change log history for a > > > particular file. > > > > > > The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ ) > > > seems to me to be very useful in that respect. > > > So I would like to suggest that OpenGrok is set up to search and index > > > the Subversion repository at http://svn.apache.org/repos/asf/ > > > OpenGrok seems to be a lot more useful than what is currently available > > > using a web browser to point to http://svn.apache.org/repos/asf/ > > > > > > I have set up a prototype test for running OpenGrok 0.5 on the JMeter > > > source, to see how it looks and works. > > > You can test the prototype at > > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/ > > > Here are some links you can test to see various views : > > > > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/search?q=&defs=&refs=&path=&hist=HttpSampler2 > > > > > > > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/search?q=&defs=&refs=&path=HttpSampler2&hist= > > > > > > > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/history/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java > > > > > > > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/xref/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java > > > > > > Note that the changelist numbers on my prototype are incorrect, the > > > reason is that I have used "svk" to mirror the JMeter part of the > > > subversion repository at http://svn.apache.org/repos/asf/ > > > > > > I think it would be most useful if OpenGrok index was available for all > > > the Jakarta projects. > > > For example if I am doing some testing of JMeter, get an exception with > > > a stack trace, and I want to look at a specific file, with line number > > > subversion changelog history, from the commons httpclient. > > > You can have a look at http://src.opensolaris.org/source/ to see how > > > OpenGrok looks when it has indexed many projects. > > > > > > > > > Do other people miss a searchable index of all the source code of > > > Jakarta, and an easy way to browse source code and subversion history, > > > both of their own and other's projects ? > > > > > > Any suggestions on how to proceed to get an OpenGrok index of the > > > Jakarta subversion repository available from the jakarta website ? > > > > > > > > > Some thoughts on how it could be set up : > > > OpenGrok needs a servlet container to run, and ideally local file access > > > to the subversion repository, to increase speed, and minimize load on > > > subversion server. > > > svnsync could be used to synchronize the repository to the machine where > > > OpenGrok is running. > > > I think it would be enough to update the index once or twice per day. > > > > > > Comments appreciated > > > > > > Regards > > > Alf Hoegemark > > > JMeter committer > > > > > > > > > > > > - > > > 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] > > > > > > > -- > Forio Business Simulations > > Will Glass-Husain > [EMAIL PROTECTED] > www.forio.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion to use OpenGrok to index all Jakarta source code
I would LOVE to have something like this for Apache projects. Looks much more useful than ViewVC. I particularly like that the source code view would be able to plug right into PMD reports to make those more useful too. On 9/1/07, Alf Høgemark <[EMAIL PROTECTED]> wrote: > Hi > > I have a number of times missed an an easy to use web interface for > searching through all Jakarta source code and subversion change logs, > and to also being > able to see line number and subversion change log history for a > particular file. > > The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ ) > seems to me to be very useful in that respect. > So I would like to suggest that OpenGrok is set up to search and index > the Subversion repository at http://svn.apache.org/repos/asf/ > OpenGrok seems to be a lot more useful than what is currently available > using a web browser to point to http://svn.apache.org/repos/asf/ > > I have set up a prototype test for running OpenGrok 0.5 on the JMeter > source, to see how it looks and works. > You can test the prototype at > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/ > Here are some links you can test to see various views : > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/search?q=&defs=&refs=&path=&hist=HttpSampler2 > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/search?q=&defs=&refs=&path=HttpSampler2&hist= > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/history/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java > > http://www.kanonbra.com/opensource/jakarta/jmeter/searchable_src/xref/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampler2.java > > Note that the changelist numbers on my prototype are incorrect, the > reason is that I have used "svk" to mirror the JMeter part of the > subversion repository at http://svn.apache.org/repos/asf/ > > I think it would be most useful if OpenGrok index was available for all > the Jakarta projects. > For example if I am doing some testing of JMeter, get an exception with > a stack trace, and I want to look at a specific file, with line number > subversion changelog history, from the commons httpclient. > You can have a look at http://src.opensolaris.org/source/ to see how > OpenGrok looks when it has indexed many projects. > > > Do other people miss a searchable index of all the source code of > Jakarta, and an easy way to browse source code and subversion history, > both of their own and other's projects ? > > Any suggestions on how to proceed to get an OpenGrok index of the > Jakarta subversion repository available from the jakarta website ? > > > Some thoughts on how it could be set up : > OpenGrok needs a servlet container to run, and ideally local file access > to the subversion repository, to increase speed, and minimize load on > subversion server. > svnsync could be used to synchronize the repository to the machine where > OpenGrok is running. > I think it would be enough to update the index once or twice per day. > > Comments appreciated > > Regards > Alf Hoegemark > JMeter committer > > > > - > 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: [VOTE] Move Turbine to TLP
+1 On 4/28/07, Scott Eade <[EMAIL PROTECTED]> wrote: The Turbine project has been discussing a proposal to the board that the Turbine projects leave the Jakarta umbrella and become their own top level project. We are now at the point in the process that calls for a vote to take place. The proposal is available at: http://wiki.apache.org/jakarta-turbine/TLPTurbine For the interested, most of the discussion took place in the following thread: http://www.nabble.com/-DISCUSS--TLP--tf3574436.html Here are the vote options: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Thanks, Scott - 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: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. lack of legal protection can be pretty detrimental to a software development community. i'd say it's an essential, non-secondary part of the ASF's fostering of dev communities. Vadim - 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: [VOTE] Release Regexp 1.5
On 3/19/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Ok so I'm a liar...I did want to point out that from my experience even the most formal voting process won't get the desired results - that everyone on the project certifies and checks that the binaries going out are good. More than likely 90% of the time everyone just votes yes or no and trusts that the person managing the release knows what they are doing. .but these are small points. ah, you say the glass is 90% empty, others might say it is 10% full. :) at least, release-then-vote provides the opportunity for oversight of the actual binaries to be released. Still, they do point to the voting process being meaningless other than all of the PMC's putting their names on it if it should go poorly. (though in a true team sort of mindset you'd think that this would always be the case with / without votes / other processes...) meaning can be quite relative. as this process is in large part due to legal, "CYA" necessities, "meaningless" things such as the mere opportunity for oversight of those bits and any actual (and perhaps even perceived) PMC oversight are important to the foundation. our best bet here is to automate the oversight as much as possible to ease the burden of the process. i will definitely be giving this ARAT tool a look. Automation is good. Esp. if it lets us opt to always trust committer X managing a release once and let a diligent little script do everything else for else without any intervention. That would be great and would bring me back to where I already was. ;) On 3/19/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > the actual bits that are distributed as an officially endorsed release > do not have the luxury of diffs sent to the development lists, nor are > they easily controlled from a central location. the releases are > extensively mirrored by servers all over the place. releases are nigh > impossible to recall. thus, with the broader audience, the > consequences for problems are greatly magnified and are not easily > remedied. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - 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: [VOTE] Release Regexp 1.5
On 3/19/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote: > Sure, of course it's ok for the ASF to dictate policies - I just hope > it's ok for me to question them / point out their flaws. > > So the real problem as far as I can tell is making sure a release is > legitimately licensed. There are other things like software quality, > but I guess it's assumed (by me at least) that we're all trying to > release as high a caliber of software as we are able given our > resources / time. > > Somehow this still doesn't feel like a legitimate problem, or at least > it is not consistent with the rest of our daily practices. ..Like > committing a change to subversion. As far as I can tell there is no > legal difference between subversion repositories and released software > - is there? Isn't the end goal to prevent any naughty code coming out > of apache period? Non conforming code sitting in subversion would > appear to be just as guilty as anything else...So given your current > logic shouldn't we all be required to have a PMC vote for each commit > made into the repo? > > It just feels like we're being treated a little bit like incompetents > in some way. Like maybe someone accidentally made a bad release once > or twice and so we must all suffer the same solution that they have. > > Ehh...Obviously I'm alone in my opinion so I'll shut up now, just > wanted to make sure I got my two cents in. > Jesse, You are certainly not alone. I have always been of an option that the content of the SVN repository is what truly represents the source code of ASF software, with packaged releases merely being versioned snapshots officially endorsed by the project committers and the respective PMC and recommended for use by the end users. I am not a legal expect by any stretch of imagination but I think ASF may be equally liable for any given revision in its official SVN repository as for its packaged releases. sure. and the SVN repo has protections that releases do not: commits are sent to a mailing list for oversight and archival. they are kept in a central place that is easy to control and not distributed widely. the consequences for problems are small and easily remedied. the actual bits that are distributed as an officially endorsed release do not have the luxury of diffs sent to the development lists, nor are they easily controlled from a central location. the releases are extensively mirrored by servers all over the place. releases are nigh impossible to recall. thus, with the broader audience, the consequences for problems are greatly magnified and are not easily remedied. i can understand complaints about the process, but let's not pretend that releases do not need an extra measure of protection that the repositories do not. that said, i would love to see some more automation of signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe Henk Penning does have some automated signature checking set up, but that's all i know of, and it only happens after the release is out. anyone frustrated with the process is quite welcome to step up and hack up something to ease the frustration. :) In Commons HttpClient / HttpComponents land we historically voted on SVN revisions and published release packages based on a lazy consensus if no one raised complaints about the content of the release packages. Oleg > On 3/19/07, J Aaron Farr <[EMAIL PROTECTED]> wrote: > > "Jesse Kuhnert" <[EMAIL PROTECTED]> writes: > > > > > You have to be kidding me.. > > > > > > The only problem I see is that people are all caught up in policies / > > > processes but I've yet to hear what the actual root "problem" is. I'm > > > sure it's intended to somehow prevent something nasty that has > > > happened in the past but these policies don't have any logic that I'm > > > able to follow. Why does the ASF need to dictate how we vote on > > > releases? > > > > > > Maybe I'm just having a bad morning, but for some reason this really > > > rubs me the wrong way and feels extremely inefficient. > > > > The problem is that Vote-Then-Release leaves opportunities for the > > small details to get missed and you end up with a sloppy release. > > Examples include non-signed distributables, incomplete legal notices, > > missing or incorrect hashes. The worst is someone slipping in some > > malicious code in between the time the vote is cast and the release is > > made. > > > > When a PMC votes on a release they should be approving the exact bits > > that hit the mirrors. That vote binds the ASF to be _legally_ > > responsible. The only way to have sufficient and appropriate > > oversight is to give the PMC a chance to check that these final steps > > of a release have been properly handled. Otherwise the PMC risks > > releasing a half baked product. > > > > It is completely appropriate for the ASF to set guidelines on release > > procedures. > > > > -- > > jaaron (who is not on
Re: Looking for an incubation champion
On 3/9/07, Matt Benson <[EMAIL PROTECTED]> wrote: --- Nathan Bubna <[EMAIL PROTECTED]> wrote: > On 3/9/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > Apologies for the top post. This puts us back to > > square one, with noone, at least from Jakarta, > > apparently interested in being champion, rendering > the > > whole discussion moot. ;) Is there an > appropriate > > next step other than simply forgetting about > > incubating? > > No need to forget it if you don't find a champion > soon. Patience and > continued development of the project and the > community around it can > pay off. More interest may come in time. For > instance, i've no time > to take up the cause of a project that i'm not using > at work, but > you've piqued my curiousity about the project. When > next i need > conversion support such as it provides, i'll be sure > to investigate > Morph more deeply as an alternative to just > BeanUtils. Then, schedule > permitting, i might be willing to help with > incubation, as it would be > more in my interest. I wouldn't be surprised if > others are thinking > much as i am here. > Thanks for chiming in with that. :) I do intend in any case to continue to help Morph develop to the point of being the serious contender that it deserves to be; I just would rather do it in the setting of the ASF. Yeah, i don't blame you. :) br, Matt [SNIP] Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - 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: Looking for an incubation champion
On 3/9/07, Matt Benson <[EMAIL PROTECTED]> wrote: Apologies for the top post. This puts us back to square one, with noone, at least from Jakarta, apparently interested in being champion, rendering the whole discussion moot. ;) Is there an appropriate next step other than simply forgetting about incubating? No need to forget it if you don't find a champion soon. Patience and continued development of the project and the community around it can pay off. More interest may come in time. For instance, i've no time to take up the cause of a project that i'm not using at work, but you've piqued my curiousity about the project. When next i need conversion support such as it provides, i'll be sure to investigate Morph more deeply as an alternative to just BeanUtils. Then, schedule permitting, i might be willing to help with incubation, as it would be more in my interest. I wouldn't be surprised if others are thinking much as i am here. -Matt --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> > wrote: > > > > Niall Pemberton wrote: > > > On 3/9/07, Martin van den Bemt <[EMAIL PROTECTED]> > wrote: > > >> > > >> Matt Benson wrote: > > >> > --- Niall Pemberton > <[EMAIL PROTECTED]> wrote: > > >> > [SNIP] > > >> >> I didn't know whether this had been done > before in > > >> >> Commons - but seems > > >> >> that it has for the Commons CSV component > back in > > >> >> December 2005: > > >> >> > > >> >> > > >> > > http://incubator.apache.org/ip-clearance/jakarta-commons-csv.html > > >> > > > >> > Actually I knew about this but thought I > remembered > > >> > someone (Henri?) saying later that having > gotten the > > >> > code in this way might not have been the best > choice > > >> > in retrospect. Does that ring any bells with > anyone? > > >> > > >> Yep that rings a bell and going down that route > again, is not > > >> something that has my support for > > >> *new* components (which this is). If the code > is destined for an > > >> existing codebase, we could do the > > >> IP route, else I would like to see some level > of incubation (besides > > >> handling ip). See the > > >> discussion on not-yet-commons ssl. > > > > > > I'm wondering why? Seems to me that this is a > slightly different > > > situation to either CSV or the SSL situations > since one of the > > > developers is an existing ASF and Commons > committer. > > > > There are new committers involved. With CSV Henri > is a committer (not talking karma here) (and me > > too, although we are both not very active). I > think when new people are involved incubation > (besides > > legal) should occur (even though the community > import isn't that big, compared to similar situation > > like activemq, servicemix, etc, where the core > developers are actually ASF Members) > > > > In case of this scenario (and ssl) I "envision" > this for incubation : > > > > - Get the people on board as a committer on the > initial proposal > > - Have them *show* that they are here to stay for > an x amount of time > > - Ideally have the normal exit criteria, although > I can imagine for commons a slightly weaker exit > > strategy may be adapted (don't think the incubator > thinks that eg 3 committers on a project is a > > vibrant community, although within commons it > definitely will be!). > > - Get a release out. > > > > If someone starts hacking on code in the sandbox I > am ok with that, but rather not see new code > > again hitting the sandbox, since we "don't" accept > new committers on sandbox components and it > > doesn't have the ability to have a release > (disclaimer : I became committer in Jakarta because > of a > > sandbox component, ahum). > > > > I highly prefer that incubating commons components > to use the commons-dev and commons-user list, > > since to do development however, since it would be > quite a cultural shock when moving from incubator > > specific lists to the commons ones. > > > > Disclaimer : this is just a brain dump and I would > love to see some new projects at Jakarta, but I > > think we also need to figure out how we should > handle that in a constructive way and prevent > > feedparser and csv situations. > > OK, good explanation - sounds reasonable to me. > You're right going the > incubator route would bring Matt Sgarlata in with > the code which would > be more desirable. > > Niall > > > Mvgr, > > Martin > > > > > - > > 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] > > Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/sh
[ANNOUNCE] VelocityTools 1.3 released
I'm pleased to announce the release of VelocityTools 1.3. There have been many improvements made since the 1.2 release. A key focus in this version has been ease of use. We've simplified developing your own tools by eliminating the ViewTool and Configurable interfaces, and we've simplified the syntax for using many of our existing tools within Velocity templates to both save keystrokes and reduce visual clutter. The distribution also comes with a new "showcase" example webapp that demonstrates many of the uses of the various tools as well as allowing you to interactively play with them. Just download the binary distribution, and deploy the "showcase.war" example to your servlet container to try it out. Also included are the usual slate of bug fixes, dependency upgrades, entirely new tools, and new functions for existing tools. For a full listing of changes, see the change log. http://velocity.apache.org/tools/devel/changes.html VelocityTools 1.3 is available in either source or binary form at: http://velocity.apache.org/download.cgi#tools For more information about VelocityTools go to: http://velocity.apache.org/tools/devel/index.html Nathan Bubna, on behalf of the Velocity development community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Move Velocity to TLP
Ok, Geir's +1/-1 has been resolved to just a +1. So the vote now stand as: +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Geir Magnusson Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- On 9/15/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Velocity to TLP
On 9/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nathan Bubna wrote: > On 9/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> Nathan Bubna wrote: >> > On 9/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> >> I'm +1 and -1. >> >> >> >> I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not >> >> necessary, but not unreasonable. >> >> >> >> I'm -1 because I'm worried that this is a new kind of umbrella that's >> >> planned. Making it a catchall for things that are and use Velocity is >> >> going the wrong direction. >> > >> > Nothing new about it. Velocity became just such an umbrella under >> > your leading, or am i mistaken about your part in forming DVSL and >> > VelocityTools? :) >> >> Tools was created because we wanted to offer support for struts users, >> and struts didn't want it. We didn't create a replacement for struts. >> And yeah, it grew in scope. >> >> DVSL was similar. Maybe it could have gone into commons, but again, it >> was home grown. >> >> And "Billy did it too!" isn't really a good reason to do it :) > > Agreed. And neither do i think "Johnny couldn't do it" is really a > good reason not too do it. :) I don't understand that argument. You are trying to say "no, we're not an umbrella" while saying "yes, we are, but you did it too". I'm having trouble resolving these two confusing messages. I wrote a fairly long post on velocity-dev some weeks back in response to Martin vdb's concerns (which were similar to yours) that addressed this confusion. I'll try to summarize briefly... I don't think the word "umbrella" fits Jakarta. Jakarta is more of a tarp or at best a canopy of sorts. It's a sack full of projects with no center. But because the word "umbrella" has been attached to Jakarta (and Logging and Db and Xml), all of their problems (and few of their successes) are now unfortunately associated with it around here. Velocity, on the other hand, has already been what is in my mind a functional and successful "umbrella". It has a center pole around which its the sub-projects have and will continue to revolve. So, to point: i'm torn between trying to redefine "umbrella" or just eschew the word altogether due to its illegitimate (IMHO) baggage. But more specific to the conversation above, i was simply rebutting your argument that Velocity being an umbrella is something new. My statement that it was under your leading was tangential. I'm not pushing this move to TLP on the merits of what other projects or even Velocity in the past have done or have failed to do well. And rather than take the time to repeat the reasons, i'll just refer you to my past posts on the subject. >> > And the idea is not that all Velocity using projects are welcome, but >> > that we are free to invite projects that are explicitly built upon or >> > for Velocity. There are big differences between being free to invite >> > projects and being a "catchall" and between being a project that uses >> > or supports Velocity and one that is explicitly built for or upon >> > Velocity. >> >> How do you draw the line? > > That's the real question here. I'd love to hear good thoughts and > suggestions on this. I wrote/modified the proposal as well as i > could, but i would very much appreciate more specific feedback on the > wording of the charter-ish stuff in there. Of course, i'm probably > explaining my thoughts on this question more clearly in these > discussions than i did in that document... So, to summarize, the > "line" should be drawn: > > - On a case by case basis. > - Carefully by the participating members of the Velocity PMC > - To the exclusion of projects which simply use or support Velocity, > without being explicitly and primarily built for use with the Velocity > template engine and/or firmly upon the core Velocity codebase. Sure - there could be a rule that "it only works with velocity" - IOW, w/o velocity, it doesn't function. Yeah, that sounds like a great way to simplify this criterion! Velosurf seems to be a good example of this. > - To the exclusion of projects whose developer communities have no > lasting interest and investment in the health and development of the > core Velocity codebase. That's hard to measure. If that's known as a criterion, people will just say the right things. True. Let me try a rephrase of it: - To the exclusion of projects whose
[RESULT] Move Velocity to TLP
On 9/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nathan Bubna wrote: > On 9/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> I'm +1 and -1. >> >> I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not >> necessary, but not unreasonable. >> >> I'm -1 because I'm worried that this is a new kind of umbrella that's >> planned. Making it a catchall for things that are and use Velocity is >> going the wrong direction. > > Nothing new about it. Velocity became just such an umbrella under > your leading, or am i mistaken about your part in forming DVSL and > VelocityTools? :) Tools was created because we wanted to offer support for struts users, and struts didn't want it. We didn't create a replacement for struts. And yeah, it grew in scope. DVSL was similar. Maybe it could have gone into commons, but again, it was home grown. And "Billy did it too!" isn't really a good reason to do it :) Agreed. And neither do i think "Johnny couldn't do it" is really a good reason not too do it. :) > And the idea is not that all Velocity using projects are welcome, but > that we are free to invite projects that are explicitly built upon or > for Velocity. There are big differences between being free to invite > projects and being a "catchall" and between being a project that uses > or supports Velocity and one that is explicitly built for or upon > Velocity. How do you draw the line? That's the real question here. I'd love to hear good thoughts and suggestions on this. I wrote/modified the proposal as well as i could, but i would very much appreciate more specific feedback on the wording of the charter-ish stuff in there. Of course, i'm probably explaining my thoughts on this question more clearly in these discussions than i did in that document... So, to summarize, the "line" should be drawn: - On a case by case basis. - Carefully by the participating members of the Velocity PMC - To the exclusion of projects which simply use or support Velocity, without being explicitly and primarily built for use with the Velocity template engine and/or firmly upon the core Velocity codebase. - To the exclusion of projects whose developer communities have no lasting interest and investment in the health and development of the core Velocity codebase. How's that sound? >> If there are projects that aren't template engines that want to come to >> Apache, the door is open and they are welcome. > > And template engines are welcome too, right? The question is whether > being here would be just about them having the foundation and > infrastructure support or if there is a community aspect too. If > community matters, then it matters where they fit in Apache > organizationally. So rather than a blanket statement that any > Velocity-related projects are welcome or not welcome, i prefer having > the freedom to individually vet the merits and fit of project > interested in joining the Velocity TLP. And you, as a Velocity PMC > member, would be very, very welcome to join in those discussions and > decisions. Sure - I think thought that the project charter should be clearer. I would love it to be. Please help! >> But putting anything that uses Velocity into a TLP is like using things >> that use log4j into the same TLP (which would re-create Jakarta... :) > > Yep, good thing that's not the plan! :) That's not obvious to me. Hopefully you mean that "wasn't" obvious to you. I've gone to some pains to explain this... :) geir > >> geir >> >> >> Nathan Bubna wrote: >> > Looks like the Velocity community is ready to head out on its own... >> > >> > +1 votes: >> > Nathan Bubna >> > Martin van den Bemt >> > James Mitchell >> > Henri Yandell >> > Jorg Schaible >> > Henning P. Schmiedehausen >> > Will Glass-Husain >> > Torsten Curdt >> > Rony G. Flatscher >> > Jesse Kuhnert >> > Dion Gillard >> > Daniel Rall >> > Matthijs Lambooy >> > Niall Pemberton >> > Claude Brisson >> > Malcolm Edgar >> > Christoph Reck >> > >> > +0 votes: >> > -none- >> > >> > -1 votes: >> > -none- >> > >> > I'm not sure who's on the PMC or not, but i'm fairly sure most of >> > those votes are binding. :) >> > >> > thanks, everyone! >> > >> > On 9/15/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: >> >> The Velocity project has for some time now been making plans f
Re: [RESULT] Move Velocity to TLP
On 9/22/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: This vote closed sooner than expected. I was traveling and there was no stated deadline. Aw, c'mon. It's been in discussion on velocity-dev for over a month, and i gave the vote a full week! Still, further votes and discussion are fine with me... :) I'm +1 and -1. I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not necessary, but not unreasonable. I'm -1 because I'm worried that this is a new kind of umbrella that's planned. Making it a catchall for things that are and use Velocity is going the wrong direction. Nothing new about it. Velocity became just such an umbrella under your leading, or am i mistaken about your part in forming DVSL and VelocityTools? :) And the idea is not that all Velocity using projects are welcome, but that we are free to invite projects that are explicitly built upon or for Velocity. There are big differences between being free to invite projects and being a "catchall" and between being a project that uses or supports Velocity and one that is explicitly built for or upon Velocity. If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. And template engines are welcome too, right? The question is whether being here would be just about them having the foundation and infrastructure support or if there is a community aspect too. If community matters, then it matters where they fit in Apache organizationally. So rather than a blanket statement that any Velocity-related projects are welcome or not welcome, i prefer having the freedom to individually vet the merits and fit of project interested in joining the Velocity TLP. And you, as a Velocity PMC member, would be very, very welcome to join in those discussions and decisions. But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) Yep, good thing that's not the plan! :) geir Nathan Bubna wrote: > Looks like the Velocity community is ready to head out on its own... > > +1 votes: > Nathan Bubna > Martin van den Bemt > James Mitchell > Henri Yandell > Jorg Schaible > Henning P. Schmiedehausen > Will Glass-Husain > Torsten Curdt > Rony G. Flatscher > Jesse Kuhnert > Dion Gillard > Daniel Rall > Matthijs Lambooy > Niall Pemberton > Claude Brisson > Malcolm Edgar > Christoph Reck > > +0 votes: > -none- > > -1 votes: > -none- > > I'm not sure who's on the PMC or not, but i'm fairly sure most of > those votes are binding. :) > > thanks, everyone! > > On 9/15/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: >> The Velocity project has for some time now been making plans for a >> proposal to the board that the Velocity projects leave the Jakarta >> umbrella and become their own top level project. Martin has asked us >> to hold a vote on the proposal here before he passes it along to the >> board. So... >> >> The proposal is available for your perusal at: >> http://wiki.apache.org/jakarta/TLPVelocity >> >> For the interested, most of the discussion took place on the following >> thread: >> http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 >> >> And the vote happens here: >> [ ] +1 I support the proposal >> [ ] +0 I don't care >> [ ] -1 I'm opposed to the proposal because... >> >> Thanks! >> > > - > 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]
[RESULT] Move Velocity to TLP
Looks like the Velocity community is ready to head out on its own... +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- I'm not sure who's on the PMC or not, but i'm fairly sure most of those votes are binding. :) thanks, everyone! On 9/15/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Velocity to TLP
Here's my +1 On 9/15/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Move Velocity to TLP
The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Opening up the PMC
On 8/14/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On Mon, 14 Aug 2006, Torsten Curdt wrote: > I am not really sure how to solve this. I am just ranting. For a few > projects I think they should go toplevel. For the ones I am involved > in at least jakarta commons surely deserves it (not looking into the > naming problem for now). Having a few more toplevel projects could > help to strip down the "general" jakarta PMC a bit ...and maybe then > the committer == PMC idea is more suitable ...maybe let's get a > smaller umbrella ;-) The problem with moving Commons up is that when you look at where Jakarta needs to go, and when you look at where Commons generally is now; they are the same places - and it's hard to distinguish between the focuses. Jakarta needs a way to blend community oversight with small numbers of active committers per component. That's pretty much Commons. For a start, I would merge BCEL, BSF, ECS, JCS, ORO and Regexp dev lists into either [EMAIL PROTECTED] or [EMAIL PROTECTED] Alexandria dies. POI should go to TLP - if it's not too inactive. That leaves Cactus, JMeter, Slide, Turbine, Velocity, HttpComponents, Taglibs. The latter three should follow Commons into flattening into Jakarta. One bit that will be interesting there is parent-poms in m2 - a flat Jakarta would not have Commons, HttpComponents, Velocity parent pom files. Velocity seems like it can flatten, but I might be lacking enough knowledge there. Unsure on the first 4 in the list above - keep them separate for the moment until ideas grow. Slide seems too inactive to go anywhere, we could put together a Testing space within Jakarta as a prototype for the testing.apache.org if people wanted to explore that, Turbine I've no clue on how well it can flatten. 1) BCEL, BSF, ECS, JCS, ORO and Regexp dev lists merging 2) Alexandria dies 3) POI to TLP 4) Consider merging user lists from 1) 5) Flatten HttpComponents, Velocity, Taglibs. FYI, i (and a few other committers) are actually starting to push Velocity the other direction: toward TLP. we're still talking about it, and i'm not sure the community is fully behind it yet. still, we're feeling like it would be better for the Velocity community to keep our little umbrella. I still believe the core Velocity library would fit just dandy in a flat component-ish Jakarta, but not so much for VelocityTools. Further, there's another Velocity-based framework-ish project out there that is interested in forging closer ties and perhaps joining the ASF. we feel it'd be most beneficial to them and us in that case to be able to bring them in as a Velocity project, and that they'd be unlikely to be accepted in Jakarta these days. anyway, just an FYI, we're not quite ready to take action on this yet. Some mad ideas :) Hen - 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] Tiles as the seed for Jakarta Web Components
This sounds great, Martin. But if i may be forgiven a little semantic nitpicking, my understanding of previous discussions is that JWC would be a "grouping" rather than a "sub-project". So Tiles would be directly a Jakarta sub-project, rather than a sub-sub-project (i.e. becoming "Jakarta Tiles", not "Jakarta Web Components Tiles"). I do also like Andrew's term "sub-community" as that describes the true intent of having these "groupings". As far as a formal scope to be attached to the Jakarta Web Components group goes, i would propose that members of the JWC should be java components developed primarily for use in the development of web applications. On 4/24/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > There has been considerable discussion, on this list and others, about the > creation of a Jakarta Web Components sub-project (also previously known as > Jakarta Silk). I believe the concensus has been in favour of creating it. > However, we seemed to get bogged down, several times, in discussions of the > name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., > should move to the new sub-project. > > Meanwhile, over at Struts, we have had a number of discussions about the > future of Tiles[1], currently a Struts sub-project. We have been working > hard to make Tiles independent of Struts, and are close to achieving that > goal. With Tiles no longer depending on Struts, it makes little sense for it > to remain a part of the Struts project. In fact, it is much more likely to > flourish outside of Struts. > > The proposal, then, is to create the Jakarta Web Components sub-project, and > make Tiles the first citizen of that sub-project. This simultaneously > achieves several objectives: > > 1) We actually get started with the Jakarta Web Components sub-project. > 2) We can defer discussion of which other parts of Jakarta move there. > 3) We create a logical home for the now-Struts-independent Tiles. > > While Tiles is a powerful templating framework, it is actually a fairly > small code base, making it a good candidate for an independent web > component. It is still being developed, so we would not be seeding Jakarta > Web Components with a dormant component. Several of the Struts committers > (many of whom are already Jakarta committers) would come here to continue > working on Tiles, and to help build the Jakarta Web Components sub-project. > > Once Jakarta Web Components is up and running, it would, of course, be up to > the various communities surrounding Commons and Taglibs components, and > potentially other Jakarta sub-projects, as to whether or not they choose to > join the new sub-project. The goal of this proposal is simply to seed the > sub-project and get the ball rolling. > > Comments? > > -- > Martin Cooper > > [1] http://struts.apache.org/struts-action/struts-tiles/ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Jakarta Sandbox
On 4/8/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > Henri Yandell wrote: > > > > > > On Sat, 8 Apr 2006, Andrew C. Oliver wrote: > > > >> -1 on these points > >> > >> 1. There should not be an escape from the pain of the incubator. All > >> new projects must go through the incubator and endure. Commons > >> sandbox was created prior to the incubator. > > > > Nope, all new communities must go through the incubator, not all new > > projects (well, components). > > So basically if I call my project a component I don't have to go through > the incubator just YOUR > incubator. > > Basically "misery loves company" so I think if the same sin buys me > purgatory, I'd like to see you there. Even if you call your project a > component. So, if i have an idea for a new "group of code" (avoiding component vs project terminology for the moment) that would reasonably fit within the jakarta mission (whatever you think that might be), you think i should have to go through the incubator to start developing it? sounds like a great plan to shut down innovation from within the jakarta community or else force it to go underground and hide out within existing "groups of code". maybe i'm wrong on this, but i always understood the incubation process to be for bringing in outside groups-of-code/communities-of-developers into the ASF.If some Jakarta developers want to try and start a new group-of-code that would fit in Jakarta, a sandbox seems like a great place to play around with it and develop interest. If, on the other hand, i've been developing some group-of-code over at sourceforge, with oversight and community happening there, and at some later point i want to bring that into Jakarta, then incubation makes perfect sense to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
+1 On 3/26/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Vote to remove the SVN barriers within Jakarta such that all jakarta-* > groups are merged into the one jakarta group with the exception of > jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under > the assumption that they are moving to having their own PMCs. Tapestry is > already within its own auth group. > > [ ] +1 > [ ] -1 > > If your -1 is only for a particular subproject (ie: you don't care what > the rest of Jakarta does, feel free to say so). > > - > 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] Cleanup pmc members
On 3/16/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > Nah, we're into a realm where legitimacy is defined by whatever we decide > to do. Technically our charter says we need a 75% of the PMC vote to > remove someone - we're not going to get that and it's not a rule that > scopes. > > We probably should just drop that from the charter - it's unnecessary > bureaucracy. Or change it to something simpler. One question is whether > we'd want to do that first - before removing the inactive PMC members from > the PMC. no, we should just change it to a 75% majority needed to remove an *active* PMC member. though i wasn't there when it was written, i'd put good money down that that was the original intent. i'm sure the 75% rule is for removing abusers, not for dropping inactive members from the roles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Other Jakarta Components
On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Definitely in favour of turning things like Velocity, POI, Turbine into > groupings if at all possible. Less likely with POI I suspect. I'd hope > that this would mean: > > SVN Auth - everyone in Jakarta has write permissions > SVN structure - jakarta/dvsl, jakarta/velocity/, jakarta/anakia (not sure > how much tools differs from engine) jakarta/tools is (and will always be) very different from engine. > Mailing lists - Encouraged to use general@ for the more administrative > issues > Website - Existence of a velocity grouping > > One option would be to discuss a Jakarta Scripting Components or something > group, but that seems like it'd be going too far. definitely too far. Velocity is about "templates", not scripts. trust me, there is a difference. :) i'd be ok with a Jakarta Template Components group. > Hen > > On Tue, 7 Mar 2006, Will Glass-Husain wrote: > > >> From the Velocity perspective, this sounds a little like our subproject. > > We've discussed this and aren't ready to move to TLP status. (we're not a > > framework!). But there are a couple of different efforts under the Velocity > > umbrella, specifically "Velocity Engine", "Velocity Tools", "DVSL". Maybe > > Anakia as well (though it's current distributed with the Velocity jar). If > > we flatten out Jakarta, I'd definitely like to see a "Velocity group". > > > > Best, > > WILL > > > > On 3/7/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > >> > >> On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >>> DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would > >>> point back to Jakarta for a dependency on [pool], but that helps to > >> foster > >>> intra-project involvement. > >>> > >>> Betwixt, Digester and JXPath strike me as a bit more to swallow and XML > >>> might not want to taking such bites. You want to go ahead and ask them? > >> > >> Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO > >> would fit nicely. > >> And obviously the component developers should agree first whether they > >> think this is a good idea. And if they are interested, I can ask the > >> DB PMC if they agree, as well. > >> However, I have no direct connections to XML PMC, and since I'm not an > >> comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me > >> (though I would if you want me to). > >> > >> Tom > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > ___ > > Forio Business Simulations > > > > Will Glass-Husain > > phone (415) 440-7500 x89 > > mobile (415) 235-4293 > > [EMAIL PROTECTED] > > www.forio.com > > > > - > 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] Jakarta Language Components
On 3/7/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > Stephen Colebourne wrote: > > Reposted (edited) from original commons proposal. > > Currently this proposal has general, though not unanimous, support. > > A vote thread may follow this thread if the mood remains positive. > > > > > ... > > > > Jakarta Language Components will: > > - develop multiple independent components > > I will vote -1 based soley on item 1 of the list for the reasons I've > already explained. I think that having ANOTHER jak-commons is a > fundementally bad idea. If these are truly enahancements to JavaSE, > they are one community, and share a mailinglist...then make them one > distribution and version them together. please correct me if i am off here, but my understanding is that this is not really "ANOTHER" commons. this is a proposal to pull out and group a subset of existing commons subprojects with the intent of simplifying and clarifying the current jumble that is commons. if anything, this looks to me like a step in the direction you are advocating. once like commons components are gathered together there may be potential to package them into one release. impeding it because it does not immediately go as far as you want it to seems picky. or do you really think these ought to be left alongside things like Jelly and ultimately packaged with them?? > > - each component will have no dependencies > > - each component will have no configuration > > - each component provides an extension to the JavaSE > > - code judged by would it be out of place in the JavaSE > > - a component typically has a broad API (many callable methods) > > - each method typically does relatively little processing > > - have mailing lists (language-user/language-dev) > > - not have a sandbox > > - use [EMAIL PROTECTED] ML (new) for cross group issues > > > > Stephen > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -Andy > > > - > 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: Representing project inactivity on the site
On 3/6/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Active Development > > Maintenance Mode > > Unsupported > > My preference would be: > > Active Development: not really named though, the implied default > Hibernating: not active but will wake up as needed > Dormant: no future activity is expected i'm not sure that "Hibernating" works as well as "Maintenance Mode", largely because i think the community is more important than the code in these situations. If the -dev list is quiet but the -user list is continually active, i don't think it fits to describe the project as "hibernating". i like the Active Development, Maintenance Mode, and Unmaintained options. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: > > On 3/6/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > > > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > > > > > (feel free to keep discussing names etc, but for the moment I'm going to > > > > go ahead with the one above) > > > > > > > > > > > > > But do it within a reasonable time frame (atleast post any objections > > > to JWC in a week -- I think thats reasonable, unless anyone wants more > > > time?). I have been meaning to add some initial components to JWC and > > > begin work there, and while I agree that the name is important, this > > > name game is now getting old ;-) > > > > > > Recap - We had 3 votes for JWC in the initial vote thread, and there > > > seems to have been more added informally on parallel conversations on > > > commons-dev. Seems the J*C "trend" is catching on (see Stephen talk > > > about JLC in another thread). > > > > > > > > > > Would anyone like to start putting together a list of constituent parts > > > > for JWC? Please include a proposal for what will happen to any > > > subprojects > > > > left dead by the creation of JWC (ie: Taglibs). > > > > > > > > > > > > > Allow me to informally assemble the beginnings of a roster, hopefully > > > others can add/remove. > > > > > > From Commons: > > > > > > * EL (dormant?) > > > > > > * FileUpload (active, martinc should confirm interest in moving to JWC) > > > > > > I'm not so sure about this. FileUpload has already cloned some code from > > HttpClient, and could undoubtedly make use of more. Its purpose is to parse > > HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP > > Components, assuming that HttpClient eventually morphs into that. (I thought > > it had already, but I can't seem to find a JHC anywhere.) > > > > Hello, Martin et al > > There's already plenty of code to look at in SVN. We are gradually > moving toward releasing our first official ALPHA. The preview of the HJC > web site can be found here: > > http://people.apache.org/~olegk/httpcomponents/ > > May I, however, express my (humble) opinion that some of the Commons > [FileUpload] code may find a better home in Commons [Codec]. To me, all > the mime/multipart parsing logic clearly belongs to [Codec]. There are > plans to factor out all multipart encoding code from Commons > [HttpClient] and move it to Commons [Codec] > > This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? > Cheers, > > Oleg > > > > * Latka (dormant) > > > > > > * FeedParser (possibly? dormant) > > > > > > From Taglibs: > > > > > > * Reusable Dialog Components (RDC) (JSP 2.0, active) > > > > > > * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, > > > been on 2.0 for a while now) > > > > > > I used to work on the Mailer taglib, but abandoned it when someone else > > decided to reinvent that as a Mailer2 taglib. That now appears to have been > > abandoned as well, and never made it out of the Taglibs sandbox. So I'm not > > sure which, if either, would go to JWC. > > > > -- > > Martin Cooper > > > > > > Then there is the question of sandbox. There has been talk about a > > > Jakarta sandbox, that probably deserves its own thread. > > > > > > -Rahul > > > > > > > > > > Hen > > > > > > > > > > - > > > 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: Representing project inactivity on the site
On 3/5/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 3/5/06, Yoav Shapira <[EMAIL PROTECTED]> wrote: > > > > Hola, > > Martin, I agree with almost everything you've said, except this: > > > > > But why? If I'm a user looking for something to help me out in my > > > development, I don't really care that much if it's active or not. What I > > > > I do care, a lot, as a user. Active means bugs are getting fixed, the > > mailing lists are a reasonable source for help, and if new standards > > become relevant or new features are requested by numerous, there's a > > good chance the product will evolve to comply with them. As a user > > who doesn't have Apache commit privilges and who doesn't want to fork > > a product just to use it, activity versus dormancy is a HUGE factor in > > choosing a product. > > > You snipped out the part that explains what you quoted. ;-) > > "What I care about is if it does the job. If there are problems with it, > then I might care about whether it's active or not" > > If you are saying that you wouldn't even try out a component that's marked > as 'inactive', to see if it does what you need, then I think it would be a > *huge* disservice to flag components as inactive right on the front page, > because then people might not even look at them, even if they're "done" and > would completely fit their needs. Marking a component as 'inactive' would > then be the final nail in its coffin. i quite agree! > -- > Martin Cooper > > > Yoav > > > > -- > > Yoav Shapira > > Senior Architect > > Nimalex LLC > > 1 Mifflin Place, Suite 310 > > Cambridge, MA, USA > > [EMAIL PROTECTED] / www.yoavshapira.com > > > > - > > 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: Representing project inactivity on the site
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Sun, 5 Mar 2006, Rainer Klute wrote: > > > Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: > >> Might be worth distinguishing the Mature/Stable projects - e.g. ORO. > >> [We're happily using that in JMeter] > > > > Yes, I second that. "Inactive", "dormant" etc. sound negative while > > "mature" or "stable" leave a good impression. And it is indeed a big > > difference if a project isn't developed any further because it is all a > > pile of junk or because it is complete, optimized and couldn't be > > improved. > > That's one of the problems, we have many different messages: > > Alexandria - Dead. Unreleased. No future. Delete. > BCEL - In need of a bugfix release, design-wise ASM is preferrable. > BSF - Would have been in the inactive category, now active again. > ECS - Tiny user base. No interest in a 2.0. Unfashionable designwise. > JCS - Seems very inactive. Unsure on userbase. Keeps getting forked. >(ehcache, jcache/fkache). > Regexp - Tiny user base. Dead development. > ORO - JDK 1.2 engine of choice. Inactive development - there is no reason >to start development up again currently. > Slide - Too inactive to complete its TLP move. > Turbine - Umbrella of its own. Hard to know what the activity is in each, >but the mailing list isn't that active. > Commons - Active, but definite areas of inactivity. > Taglibs - Inactive, RDC Taglib is about it for activity there. > Velocity - At least DVSL is dead - unsure about tools. VelocityTools is very much alive. > POI - Seems to be fighting inactivity. > > Finding a label to match the above messages is tricky; "inactive > development" seems to be the only one that fits. > > Hen > > - > 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] Two community proposals
On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > I started to write a long email on the problems in Jakarta, on umbrellas, > on the lack of a Jakarta community and existence only of subcommunities > and on how it should be "there is no Jakarta Xxxx, you are members of > Jakarta - not a subproject"; but you've heard it all before. > > So, proposal: > > - > Given that we are one project and that we should be acting as one > community - I propose that we: > > 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in > Jakarta, with the exception of the Commons-Sandbox as it allows Apache > committers in general to commit. i think this is fine. it brings our practice more in line with the legal realities of the organization. it adds potential for greater cross-pollination and lower barriers to resuscitating dormant projects. it's true that most of us committers are myopic and do nothing with the greater freedom, but the potential is there for some to more easily serve the community and their own needs through this. > 2) All vote threads to occur on the general@ mailing list; or the pmc@ > mailing list if deemed private. if you want all non-private vote threads to be CC'ed to general@, that's fine, but they must happen on the dev lists as well. i believe there are many narrow, non-committer participants who give good feedback and non-binding support who do not subscribe to [EMAIL PROTECTED] i am extremely reluctant to give that up. > - > > Comments? > > The only negative I have for 1) is that I like to use the commit lists to > see who is on which subproject (for 3 PMC member oversight checking), but > that is a flawed idea anyway. The real way is to see who is voting on > issues (especially releases) for that project. If it's an inactive > project, the real way is to ask the -dev mailing list for 3 PMC replies > else the subproject gets mothballed. > > Hen > > - > 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 struts binary
Struts is no longer under the jakarta umbrella. you'll find what you need at http://struts.apache.org FYI, it's usually quicker to try asking Google about such things first. :) http://www.google.com/search?q=struts oh, and since java is platform and operating system independent, there is only one binary for all, rather than being windows or mac or *nix specific. On 2/8/06, John Armstrong <[EMAIL PROTECTED]> wrote: > > I'm trying to learn java struts and an old Jakarta Struts book is telling > me to go to jakarta.apache.org for the jakarta struts binary. When I go > there there's no mention of such under downloads. There's just "Struts" > under Ex-Jakarta, and when I go there, there's numerous downloads besides > Jakarta Struts Binary. > > How can I get the Jakarta Struts binary for Windows? > > > - > 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: [site] Kill the vendor support page
+1 if the vendors wanna be on our Wiki, i say we let 'em do it. On 2/8/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: > What we did with Lucene was to move the hard-coded committer > maintained list of projects and products that use Lucene to the wiki. > > Let the community self-maintain this sort of thing. > > +1 to moving it to the Jakarta wiki. > > Erik > > > On Feb 7, 2006, at 8:17 PM, Henri Yandell wrote: > > > > > As per the previous email, I'd like to raise the question of > > killing the vendor support page. With Tomcat moving to TLP, there's > > even less Jakarta support here than before. Mainly it's Ant, > > Struts, Log4j, Tomcat and HTTP Server. > > > > Alternatively, we could attempt to make it a Java support page for > > Apache products, or even talk to someone - probably the board, > > maybe prc - about having an Apache version of this. However, I > > think that doing it ourselves is probably outside our scope and I > > suspect there won't be a huge amount of interest Apache-wide to > > having such a database of vendors. > > > > Any thoughts? > > > > Hen > > > > - > > 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: [RESULT] Tapestry TLP
On 2/7/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Tue, 2006-02-07 at 09:43 -0800, Howard Lewis Ship wrote: > > Below is the result of the recent Tapestry committers vote to move > > Tapestry to an Apache top level project. Pending the approval of the > > Jakarta PMC, we'll be submitting the request to the Apache board. > > is another VOTE needed for approval or can we just go with the VOTE held > on the tapestry thread? let's vote on it! +1's from me all around. :) > - robert > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQBD6Ogd1TNOdbExPeIRAvPmAJ9ZLCx/+BOAQWzKCyWTU1QmVQreNgCg3oDX > 6md02peVDloWkBYLqiMkATY= > =d4ev > -END PGP SIGNATURE- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Velocity Tools 1.0 released
The Velocity team is happy to announce the release of Velocity Tools 1.0. Velocity Tools is a collection of Velocity subprojects offering servlets and tools for rapid, clean web development with Velocity, tools for using Velocity with Struts, and a set of generic tools to help with any Velocity project. Both source (http://jakarta.apache.org/site/sourceindex.cgi) and binary (http://jakarta.apache.org/site/binindex.cgi) distributions are available through the the usual Apache mirror sites. Please remember to verify the signatures of the distribution using the keys found on the main Apache web site (http://www.apache.org/dist/jakarta/velocity-tools/KEYS) when downloading from a mirror. Please see the Velocity Tools website (http://jakarta.apache.org/velocity/tools/index.html) for more information. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: karma anyone?
Geir Magnusson Jr. said: ... > On Friday, July 4, 2003, at 12:03 AM, Nathan Bubna wrote: ... > > 2. Getting the documentation up on > > http://jakarta.apache.org/velocity/tools/. > > i have no karma for logging onto that machine to create the directory > > and > > update/upload the files. Do i need that? Can i get it? Am i just > > way off > > here? ... > you should have access to jakarta.apache.org. If not, we need to ask > infrastructure@, and then you can do it i can only log into cvs.apache.org. jakarta.apache.org knows me not. is the "we" that should ask infrastructure@ me or you or ya'll? :) > Or once it's in CVS, I can do it. well, if that's what it takes, ok, but i'd prefer not to be too dependent if possible. i presume you'd want the *.html all checked into a docs folder? > > 3. In terms of actually putting the release out there, the commons' > > guide(http://jakarta.apache.org/commons/releases.html) also speaks of > > logging > > into jakarta.apache.org. Anyone with karma wanna lend a hand? > > Same for docs - you'd put the release tgz, zip and md5 sigs out there. oh yeah, md5 sigs. heh. guess i need to figure out how to do that stuff too. oh joy! :-) > > 4. i'd also like to update the main jakarta site pages with > > appropriate > > notice of this release (if/when i figure out how to make it happen). > > So, can > > i get karma for jakarta-site2 as well? > > done. thanks! :) Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
karma anyone?
hi folks, i'm trying to get a 1.0 Velocity Tools release going on, but i lack much karma and know-how. Here's my hang-ups: 1. There's no good place to report bugs. We really need a "Tools" component in Bugzilla under the Velocity project. i have no idea how to get this done, and i'm sure i lack the karma. 2. Getting the documentation up on http://jakarta.apache.org/velocity/tools/. i have no karma for logging onto that machine to create the directory and update/upload the files. Do i need that? Can i get it? Am i just way off here? The website maintenance doc (http://jakarta.apache.org/site/jakarta-site2.html) speaks of doing this, but i'm just a lowly jakarta-velocity-tools committer sitting on the streetcorner holding a "no karma. please help!" sign. 3. In terms of actually putting the release out there, the commons' guide(http://jakarta.apache.org/commons/releases.html) also speaks of logging into jakarta.apache.org. Anyone with karma wanna lend a hand? 4. i'd also like to update the main jakarta site pages with appropriate notice of this release (if/when i figure out how to make it happen). So, can i get karma for jakarta-site2 as well? All apologies for any ignorant, misguided, or OT questions. Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
