Re: [POLL] General Consensus, Round 2 - J2EEUnit
- Original Message - From: "Sam Ruby" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 25, 2001 1:33 PM Subject: Re: [POLL] General Consensus, Round 2 - J2EEUnit > I had J2EEUnit clean compiling with gump, then another external dependency Geeze you're fast ... I am writing a new build-test-all.xml Ant file that starts all the tests for all servlet engine. I'll have it in CVS in about 2-3 hours I guess. I'll make some other modifications to the batch files to support this. > was added. Vincent, t is not clear to me that you have permision to > distribute Resin code, and this will have to be resolved before any > proposal to donate J2EEUnit to the ASF could be considered. (I won't begin > to comment on intermixing GPL and Caucho Developer Source Licenced code). > Do you mean for the resinBootstrap.jar ? I have added this yesterday because there is way to stop Resin. So I wrote some java code that start Resin (using an internal class : RunResin) create a server socket listener and stops the Resin when someone connects to this socket. However, I wanted to be able to compile this little piece of java code without needing the Resin server to be installed (that's why I put 2 resin classes in this bootstrap jar). It is only used when you run the Resin tests, for which you need Resin. What I can do, is move the compilation of this code as a dependency of the Resin tests (which it is). This will remove the resinBoostrap.jar file. Ok, I'll do that right now. Ready in about 2-3 hours in CVS ... > The normal way to handle this is to make such dependencies optional. > Following are the patches required to your build definition to make this > happen. > Thanks. > - Sam Ruby > Vincent.
Re: [POLL] General Consensus, Round 2 - J2EEUnit
I had J2EEUnit clean compiling with gump, then another external dependency was added. Vincent, t is not clear to me that you have permision to distribute Resin code, and this will have to be resolved before any proposal to donate J2EEUnit to the ASF could be considered. (I won't begin to comment on intermixing GPL and Caucho Developer Source Licenced code). The normal way to handle this is to make such dependencies optional. Following are the patches required to your build definition to make this happen. - Sam Ruby Index: build.xml === RCS file: /cvsroot/j2eeunit/j2eeunit/build/build.xml,v retrieving revision 1.20 diff -u -r1.20 build.xml --- build.xml 2001/02/24 22:52:59 1.20 +++ build.xml 2001/02/25 11:42:10 @@ -88,6 +88,9 @@ + + + @@ -251,6 +254,9 @@ + + +
Re: [POLL] General Consensus, Round 2 - J2EEUnit
At 03:25 24/2/01 +0100, Vincent Massol wrote: >Hi, > >I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it >already uses Ant build scripts, the Jakarta look and feel for it's web site, >it has test suites for Tomcat, ... :) kewl ;) >However, when I registered it on SourceForge, I chose the first license in >the list (I didn't know which one to choose ... :)) which happened to be the >GPL one. Would that be a problem ? Is it possible to change a license ? GPL is incompatable with APL but if you are sole copyright owner (or if all contributors agree) there is no problem changing license. Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-*
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Vincent Massol wrote: > However, when I registered it on SourceForge, I chose the first license in > the list (I didn't know which one to choose ... :)) which happened to be the > GPL one. Would that be a problem ? Is it possible to change a license ? You still own the code, Vincent. SourgeForge is just help you distribute it. The only person who could take issue with you changing the license under a later release, is you ;-) Welcome aboard! -T.
Re: [POLL] General Consensus, Round 2 - J2EEUnit
Hi, I would be very happy to donate J2EEUnit to the Apache project ! ... hey, it already uses Ant build scripts, the Jakarta look and feel for it's web site, it has test suites for Tomcat, ... :) However, when I registered it on SourceForge, I chose the first license in the list (I didn't know which one to choose ... :)) which happened to be the GPL one. Would that be a problem ? Is it possible to change a license ? Thanks. Vincent. > > NEW BUSINESS > > The first packages on the library agenda will be: > > JDBC connection pool > > and > > Testing Framework > > Work on these packages will coincide with work on the library subproject > infrastructure. > > Additional codebases to consider for the Testing Framework include > > http://sourceforge.net/projects/j2eeunit - Vincent Massol > http://sourceforge.net/projects/arrowhead/ - Kevin Burton > > --- >
Re: [POLL] General Consensus, Round 2
> I think this item kinda hits the nail on the head as far as most of the > disagreement going on right now. So perhaps nailing down what the specific > "Goal" or perhaps "Range of goals" are could clarify this? Here is my > somewhat vague understanding of the goals of this project: > > "To create high quality components or tools that are commonly used by or > alongside other products of the jakarta project as a whole." My understanding of the goal is: "To help jakarta projects to share code and development of commonly used components, leading to a high quality component repository" It's probably the same thing - but from a different perspective. I think essential to the repository success is getting the existing communities to share and cooperate. From your form I get the message that creating the components and the code is essential. > It seems that the discussion is quickly becoming a battle of the specific > visions of how to reuse. I don't see how that moves us any closer to what > I understand the goal to be, but that could just be me misunderstanding > the goal. Any thoughts? Or it may be my understanding - or the goal can be somewhere in the middle. Costin
Re: [POLL] General Consensus, Round 2
On Thu, 22 Feb 2001 [EMAIL PROTECTED] wrote: > > I was assuming the goal of the project is to have jakarta projects share > code - not to take common code without it's community and create another > project out of it. > > Costin > > I think this item kinda hits the nail on the head as far as most of the disagreement going on right now. So perhaps nailing down what the specific "Goal" or perhaps "Range of goals" are could clarify this? Here is my somewhat vague understanding of the goals of this project: "To create high quality components or tools that are commonly used by or alongside other products of the jakarta project as a whole." Now, in this case create is fairly open. This can mean: * Having someone from a jakarta project donating the code as a starting point and the interested committers from within jakarta get together and get the code molded into the vision of a well-specified tool that fits a general need, with wrappers to fit that generalized tool back into the other products in jakarta OR * Having the interested parties specify an API for the 'ideal' shared tool and looking through the existing code in jakarta... OR ...insert many other options. It seems that the discussion is quickly becoming a battle of the specific visions of how to reuse. I don't see how that moves us any closer to what I understand the goal to be, but that could just be me misunderstanding the goal. Any thoughts? David
Re: [POLL] General Consensus, Round 2
On another almost related note, I sent off a reply to Round 1 and received it locally, did it make it through to the list? David
Re: [POLL] General Consensus, Round 2
+1 on these items as a whole. Sorry for the delay, just getting caught up with the list now. David Weinrich On Thu, 22 Feb 2001, Ted Husted wrote: > (1) > > OLD BUSINESS > > To finalize the first round, I'd like to get a majority vote on these > revised points of consensus. I believe these points represent the > consensus opinion. In the interest of unity, if possible, please provide > a single vote on the points as a block. > > This poll will expire in 5 days, or when the committers on the active > roster (below) have responded. > > + The primary unit of reuse and release is the package. > > + The package library is not a framework but a repository of codebases > designed to be shared. > > + Each package must have a clearly defined purpose, scope, and API -- Do > one thing well, and keep your contracts. > > + Each library package is treated as a product in its own right. > > - - Each package has its own status file, release schedule, version > number, QA tests, documentation, mailing list, and bug category. > > - - Each package must clearly specify any external dependencies, > including any other library packages, and the earliest JDK version > required. > > - - - External dependencies on optional and third-party codebases should > be minimized. > > + Each package maintains a list of its active committers in its status > file. > > + The packages should use a standard scheme for versioning, QA tests, > and directory layouts, and a common format for documentation and Ant > build files. > > + The packages should fit within a unified package hierarchy. > > + In general, packages should define an abstract interface, and provide > one or more implementations of that interface. > > + The packages should have boring functional names. Implementations may > choose more "exciting" designations. > > + Packages are encouraged to either use JavaBeans as core objects, a > JavaBean-style API, or to provide an optional JavaBean wrapper. > > + External configuration files are discouraged, but if required, XML > format files are preferred for configuration options. > > + The package library subproject shall be proposed as a Jakarta > subproject. > > + Each package will be hosted on its own page on the subproject Web > site, and will also be indexed in a master catalog. > > + The subproject catalog will also provide a distribution mechanism. > > + The subproject will also host top-level "general" and "announcement" > mailing lists. > > + The subproject will also provide a single JAR of all stable package > releases. It may also provide a second JAR with a subset of only JDK 1.1 > compatible releases. A gump of nightly builds will also be provided. > > + Committers join the library subproject in the same way they are > entered to any Jakarta subproject. Being a committer in another Jakarta > subproject is not a prerequisite, nor does it provide free entry to the > library subproject. > > + Each committer has karma for all the library packages, but is expected > to add their name to a package's status file before their first commit > to that package. > > + The library committers shall elect a committee of three committers to > provide general oversight, in the style of the Jakarta PMC. > > + New packages may be proposed to the library general list, and voted on > by all committers. To be accepted, a package proposal must receive a > positive 3/4's vote of the library committers. Packages proposed are > expected to be used by one or more ASF products. > > (2) > > NEW BUSINESS > > The first packages on the library agenda will be: > > JDBC connection pool > > and > > Testing Framework > > Work on these packages will coincide with work on the library subproject > infrastructure. > > Additional codebases to consider for the Testing Framework include > > http://sourceforge.net/projects/j2eeunit - Vincent Massol > http://sourceforge.net/projects/arrowhead/ - Kevin Burton > > --- > > Roll of Active Committers (those responding to the last poll) > > Costin < [EMAIL PROTECTED] > > Rodney Waldhoff < [EMAIL PROTECTED] > > Ignacio J. Ortega < [EMAIL PROTECTED] > > Bhamidi Krishna < [EMAIL PROTECTED] > > Geir Magnusson Jr. < [EMAIL PROTECTED] > > Ted Husted < [EMAIL PROTECTED] > > Federico Barbieri < [EMAIL PROTECTED] > > Peter Donald < [EMAIL PROTECTED] > > Ceki < [EMAIL PROTECTED] > > Morgan Delagrange < [EMAIL PROTECTED] > > > -Ted. >
RE: [POLL] General Consensus, Round 2
(1) -0 ( i'm not very interested on this kind of Library project, look at my last message to know why ) (2) +0 ( this will converted to a +1 if the proposal for Library management changes ) in addtion from (1) > + The subproject will also host top-level "general" and "announcement" > mailing lists. > -1 too much lists, I expect a large population of subprojects, too confuse for everybody, more upper layer management needs, many opportunities for low signal/noise ratio on maillists.. > (2) > > NEW BUSINESS > I will be glad if the General XML Config mechanism is included in whichever final Library proposal we come in .. Saludos , Ignacio J. Ortega
RE: [POLL] General Consensus, Round 2
I've took the message below as a proposal by itself, and it has +1 I agreed completely with the points and concerns expressed by Costin.. Saludos , Ignacio J. Ortega > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Enviado el: viernes 23 de febrero de 2001 4:12 > Para: [EMAIL PROTECTED] > Asunto: Re: [POLL] General Consensus, Round 2 > > > > Why not add a third (3) Repository, lead by Costin, in the model of > > all-inclusive, everyone gets a vote, add code and you're a > committer, > > aka 'JakartaForge'. That fits into the model, as a > subproject, like a > > regular Jakarta project, has reasonable control over it's > destiny and > > rules, so if anything goes, anything goes. It will > certainly be a good > > test to see how that community model works compared to the Jakarta > > community model. > > That's not what I'm proposing - if a project wants to share a > component ( > or develop a new component that is not specific to that > project, but of > general interest ) it can use the common "repository" as long as it > accepts the rules: > > 1. follow the general guidelines ( we all agreed on ) > > 2. Share the development with other projects, if other projects are > interested in using that component. That rules is supposed to > encourage > other projects to use the component, knowing they have an > official vote. > > If a project doesn't want to share a component with other > projects ( I'm > talking about control and development ) - then it shoulnd't use the > repository, but keep it private to that project. > > ( there are different degrees on the level of control sharing ) > > > > > And why not letting the original authors of a component decide for > > > themself what to do with a component ? And why not let > turbine decide if > > > they want to share the component and how to do it ? > > > > They do - they released the code under APL, sharing with > everyone. But > > they are currently choosing to keep it integrated in Turbine, > > subordinate to the needs of turbine, and not documented as > a separable > > unit. That is the choice *they* are making *today*. > > And you want to fork the code and create your own version ? That's not > very nice. Maybe other project have a pool and they want to share. And > maybe turbine will see the benefits of sharing and decide to > participate > in the library. > > A lot of people claim the community is more important than > the code - if > you can't get the community behind a FooPool, the code is not that > important. > > > > What makes you think that whatever DBPool you choose will > be better ? And > > > what makes you think that a project will be happy to > replace some code > > > they developed and serve their purpose with something > they have no control > > > over ? > > > > Why do you think that projects will be *required* to > replace their code > > with the so-called 'library' code? > > I was assuming the goal of the project is to have jakarta > projects share > code - not to take common code without it's community and > create another > project out of it. > > Costin > >
Re: [POLL] General Consensus, Round 2
Ted Husted wrote: > (1) +1 > (2) +1
Re: [POLL] General Consensus, Round 2
> Why not add a third (3) Repository, lead by Costin, in the model of > all-inclusive, everyone gets a vote, add code and you're a committer, > aka 'JakartaForge'. That fits into the model, as a subproject, like a > regular Jakarta project, has reasonable control over it's destiny and > rules, so if anything goes, anything goes. It will certainly be a good > test to see how that community model works compared to the Jakarta > community model. That's not what I'm proposing - if a project wants to share a component ( or develop a new component that is not specific to that project, but of general interest ) it can use the common "repository" as long as it accepts the rules: 1. follow the general guidelines ( we all agreed on ) 2. Share the development with other projects, if other projects are interested in using that component. That rules is supposed to encourage other projects to use the component, knowing they have an official vote. If a project doesn't want to share a component with other projects ( I'm talking about control and development ) - then it shoulnd't use the repository, but keep it private to that project. ( there are different degrees on the level of control sharing ) > > And why not letting the original authors of a component decide for > > themself what to do with a component ? And why not let turbine decide if > > they want to share the component and how to do it ? > > They do - they released the code under APL, sharing with everyone. But > they are currently choosing to keep it integrated in Turbine, > subordinate to the needs of turbine, and not documented as a separable > unit. That is the choice *they* are making *today*. And you want to fork the code and create your own version ? That's not very nice. Maybe other project have a pool and they want to share. And maybe turbine will see the benefits of sharing and decide to participate in the library. A lot of people claim the community is more important than the code - if you can't get the community behind a FooPool, the code is not that important. > > What makes you think that whatever DBPool you choose will be better ? And > > what makes you think that a project will be happy to replace some code > > they developed and serve their purpose with something they have no control > > over ? > > Why do you think that projects will be *required* to replace their code > with the so-called 'library' code? I was assuming the goal of the project is to have jakarta projects share code - not to take common code without it's community and create another project out of it. Costin
Re: [POLL] General Consensus, Round 2
> That's right. But then with your model of user-gets-auto-veto, would it > be right that Velocity, which for example would just use the code and > not participate in the development, can basically interfere with the > development evolution of the component that Tomcat is dependent upon? Yes. Sharing a component and using a shared component means you agree to let others have a say in that component. If both velocity and tomcat are using a component, both project should be able to vote on it's evolution. BTW, I don't agree with this "user" stuff - we are talking about projects using a shared component - it's more than just an user, and it probably involves active development ( at least on the project side ). If the component is too good or too boring - probably it will not matter. But that's a secondary issue - the important question is if a project can vote on sharing a component and place it in the library without aproval from the existing components in the library, even if a similar component exists already. > > 1. We either let each project decide on it's own to share / use, and make > > it as easy as possible to do so. > > All projects now have the ability to share in a way thats accessable to > others. Some choose not to, and there are good reasons. There is > defacto sharing, as the code is open to all. I don't think we have real sharing - some projects may choose to write component-like code and other can use it, but I don't think that's enough. And the current model doens't seem to work - as you can see there is a lot of duplication and very little reuse. Why ? Because there are a lot of bariers in working with the code developed in other project, and the components are not designed and perceived as shared. > The problem is that *right now* no one wants to own and care for some of > the smaller pieces, like a DB connection pool. It seems the reverse is true - each project is duplicating the smaller pieces ( by creating its own implementation ). > Why is that? IMHO - because we don't have a library and a mechanism for projects to "outsource" general purpose code that is not essential to their functionality. By placing a component in the library a project will get more eyes and ideas, but in order for that to work it needs to do something that is benefical for other projects. And will be able to stay focused to it's main goal. But that can't happen if they are not willing to share control with other projects involved. That's my theory - and I spent enough time arguing on this, I have too much work to do - I'll vote when the final proposal is made, and if this is the project I need I'll start fighting to get tomcat share and use common code. If not - I'll wait for the right project. Costin
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > > > >What makes you think that whatever DBPool you choose will be better ? And > > >what makes you think that a project will be happy to replace some code > > >they developed and serve their purpose with something they have no control > > >over ? > > > > I assumed there was some turbine developers on this list ;) If not is there > > some struts developers ? It may be good for people to say where they will > > be able to help migrate in code. I am involved with both Aalon and Ant and > > will be happy to do what is appropriate to facilitate sharing between these > > two and this library project. > > My point was that the decision should come from a project that wants to > share a piece of code ( or use a shared component ) - and they shouldn't > have to be "aproved" by a library comitee. I don't understand the model you have. No one is forced to do anything. > I'm a tomcat commiter, but I can't decide on my own to take a piece of > tomcat, change it, put it in the library and then change > tomcat to use the library. It should be a decision on tomcat-dev, and the > people who vote +1 on it and are doing the work of refactoring the > component for inclusion should be able to maintain in the new repository. That's right. But then with your model of user-gets-auto-veto, would it be right that Velocity, which for example would just use the code and not participate in the development, can basically interfere with the development evolution of the component that Tomcat is dependent upon? I agree that only tomcat-dev can decide on how to change tomcat to use components in the library. And if there is a piece of tomcat that would be a good candidate, then by all means someone should organize a bit and propose adding a new component (which I assume would be waved right in if it was a new addition), or explaining why the existing one doesn't work [and then working with the existing group to decide if you add another, or work on the first to fit...] [SNIP] > It's very simple: > > 1. We either let each project decide on it's own to share / use, and make > it as easy as possible to do so. All projects now have the ability to share in a way thats accessable to others. Some choose not to, and there are good reasons. There is defacto sharing, as the code is open to all. The problem is that *right now* no one wants to own and care for some of the smaller pieces, like a DB connection pool. Why is that? > or > > 2. Grab code from projects (selecting by vote which component) or create > new components, with the goal of creating server-side components for > projects. > I don't see any reason (2) can't be done in avalon - after all the goal of > avalon is exactly that. > > I also think there is a need for (1), and if the project we are discussing > now (the library ) is not doing that, probably we need another project. > > Costin > > -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > I am interested in a component repository for the existing code in > projects - where the projects can share the code if they choose to. > > It looks like in the current form, the library is duplicating Avalon - > it's goal is to create productized server-side components, and I don't see > any reason you'll need another project doing the same thing. Well, if Avalon really is doing that, I am happy to shut up and go over there... But if not - So far, the proposal was to start two subprojects, (1) DBCP and (2) Testing, I think. Why not add a third (3) Repository, lead by Costin, in the model of all-inclusive, everyone gets a vote, add code and you're a committer, aka 'JakartaForge'. That fits into the model, as a subproject, like a regular Jakarta project, has reasonable control over it's destiny and rules, so if anything goes, anything goes. It will certainly be a good test to see how that community model works compared to the Jakarta community model. > All you have to do is contribute code to avalon, like any user, become a > commiter - and then propose new components. I don't see any significant > diference to require a new jakarta project. After all, the project goal > is the same, and everything else is implementation detail ( i.e. how do > you organize the code ) - and if you can propose it to avalon and be voted > by existing avalon commiters. Well, for a while there, Avalon was working under it's "cover charter", claiming to be a 'framework' - when it's reborn here in Jakarta (isn't that what is happening?), I guess we can see. > > >From what I gathered our plan of attack was (1). ie Our first module would > > be the DBPool. We would extract it from somewhere (say turbine) refactor > > it. Then push it back into turbine with a wrapper that integrates it into > > the turbine framework. We would then try to integrate it into struts and > > anyone else that uses DB pools. Then we would pick another component and do > > the same. Have I got this correct/wrong? > > And why not letting the original authors of a component decide for > themself what to do with a component ? And why not let turbine decide if > they want to share the component and how to do it ? They do - they released the code under APL, sharing with everyone. But they are currently choosing to keep it integrated in Turbine, subordinate to the needs of turbine, and not documented as a separable unit. That is the choice *they* are making *today*. > What makes you think that whatever DBPool you choose will be better ? And > what makes you think that a project will be happy to replace some code > they developed and serve their purpose with something they have no control > over ? Why do you think that projects will be *required* to replace their code with the so-called 'library' code? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
At 10:42 22/2/01 -0500, Geir Magnusson Jr. wrote: >Peter Donald wrote: > >> A few days ago I indicated the 4 paths I saw were >> >> 1. component repository (ie ToolForge+CJAN) >> 2. vetted/tested/approved components (ie Avalon+CJAN) >> 3. base util (Something similar to AUT - Apache Utility Toolkit). >> 4. gathering >> >> (3) is easily doable within current apache model. I believe Costin wants to >> work in (1) and Avalon covers enough of (2) that I don't see it worth >> creating a new project for. So what am I saying? ;) I am +1 for all but (2) >> which I am -1 on at the moment. > >Except that Avalon doesn't appear to be a 'catalog' of separate, >independant components that are individually documented, buildable, >etc... you can always enhance the Avalon project in such a manner ;) Done well enough it could be a great precursor to CJAN ;) Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-*
Re: [POLL] General Consensus, Round 2
> >What makes you think that whatever DBPool you choose will be better ? And > >what makes you think that a project will be happy to replace some code > >they developed and serve their purpose with something they have no control > >over ? > > I assumed there was some turbine developers on this list ;) If not is there > some struts developers ? It may be good for people to say where they will > be able to help migrate in code. I am involved with both Aalon and Ant and > will be happy to do what is appropriate to facilitate sharing between these > two and this library project. My point was that the decision should come from a project that wants to share a piece of code ( or use a shared component ) - and they shouldn't have to be "aproved" by a library comitee. I'm a tomcat commiter, but I can't decide on my own to take a piece of tomcat, change it, put it in the library and then change tomcat to use the library. It should be a decision on tomcat-dev, and the people who vote +1 on it and are doing the work of refactoring the component for inclusion should be able to maintain in the new repository. If DBPool from turbine is to be included I hope it'll be a vote on turbine-dev, some turbine developers ( who know the component the best ) will volunteer to help and do the needed refactoring ( I don't think that someone from outside can do a better job than the original maintainers of the code ). It's very simple: 1. We either let each project decide on it's own to share / use, and make it as easy as possible to do so. or 2. Grab code from projects (selecting by vote which component) or create new components, with the goal of creating server-side components for projects. I don't see any reason (2) can't be done in avalon - after all the goal of avalon is exactly that. I also think there is a need for (1), and if the project we are discussing now (the library ) is not doing that, probably we need another project. Costin
Re: [POLL] General Consensus, Round 2
Peter Donald wrote: > A few days ago I indicated the 4 paths I saw were > > 1. component repository (ie ToolForge+CJAN) > 2. vetted/tested/approved components (ie Avalon+CJAN) > 3. base util (Something similar to AUT - Apache Utility Toolkit). > 4. gathering > > (3) is easily doable within current apache model. I believe Costin wants to > work in (1) and Avalon covers enough of (2) that I don't see it worth > creating a new project for. So what am I saying? ;) I am +1 for all but (2) > which I am -1 on at the moment. Except that Avalon doesn't appear to be a 'catalog' of separate, independant components that are individually documented, buildable, etc... That's what I have in mind for (2), which I am +1 on. I am also +0 on (1) [as time is precious these days, and I want to get a *great* DBCP developed and componentized - there is movement afoot in Turbine-land for a JDBC compliant component, and Struts is pretty much there...], +0 on (3) [same reason - no time - but a good idea], and I don't know what (4) is... Can we change the name of this list to 'catalog-dev' ? :) > >From what I gathered our plan of attack was (1). ie Our first module would > be the DBPool. We would extract it from somewhere (say turbine) refactor > it. Then push it back into turbine with a wrapper that integrates it into > the turbine framework. We would then try to integrate it into struts and > anyone else that uses DB pools. Then we would pick another component and do > the same. Have I got this correct/wrong? It might be easier to start with what Struts has is you are in the mood for JDBC compliant interfaces, but there is lots of discussion going on in Turbine-land about this. It's a great time to do this... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
At 06:14 22/2/01 -0800, [EMAIL PROTECTED] wrote: >And why not letting the original authors of a component decide for >themself what to do with a component ? And why not let turbine decide if >they want to share the component and how to do it ? > >What makes you think that whatever DBPool you choose will be better ? And >what makes you think that a project will be happy to replace some code >they developed and serve their purpose with something they have no control >over ? I assumed there was some turbine developers on this list ;) If not is there some struts developers ? It may be good for people to say where they will be able to help migrate in code. I am involved with both Aalon and Ant and will be happy to do what is appropriate to facilitate sharing between these two and this library project. Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-*
Re: [POLL] General Consensus, Round 2
> [EMAIL PROTECTED] wrote: > > In any case - I hope Ted will include the 2 proposals in the final vote, > > and I'll let the majority decide what will be the goal and rules for this > > project. > > As near as I can figure we have already covered that ground, and the > current proposal already reflects what the majority of people > contributing to this list have decided. I haven't seen a final vote, only 2 rounds of polling, and on each round there were proposals to refine the polling and reword some of the questions. > I am making my best effort, but if you feel differently, then you might > like to submit a proposal of your own. Sure, but why not reuse the existing one, and add one more choice to the poll ? :-) Costin
Re: [POLL] General Consensus, Round 2
> >> In any case - I hope Ted will include the 2 proposals in the final vote, > >> and I'll let the majority decide what will be the goal and rules for this > >> project. > > > >As near as I can figure we have already covered that ground, and the > >current proposal already reflects what the majority of people > >contributing to this list have decided. > > I am kinda confused ;) > > A few days ago I indicated the 4 paths I saw were > > 1. component repository (ie ToolForge+CJAN) > 2. vetted/tested/approved components (ie Avalon+CJAN) > 3. base util (Something similar to AUT - Apache Utility Toolkit). > 4. gathering > > (3) is easily doable within current apache model. I believe Costin wants to > work in (1) and Avalon covers enough of (2) that I don't see it worth > creating a new project for. So what am I saying? ;) I am +1 for all but (2) > which I am -1 on at the moment. I agree with this. I am interested in a component repository for the existing code in projects - where the projects can share the code if they choose to. It looks like in the current form, the library is duplicating Avalon - it's goal is to create productized server-side components, and I don't see any reason you'll need another project doing the same thing. All you have to do is contribute code to avalon, like any user, become a commiter - and then propose new components. I don't see any significant diference to require a new jakarta project. After all, the project goal is the same, and everything else is implementation detail ( i.e. how do you organize the code ) - and if you can propose it to avalon and be voted by existing avalon commiters. > >From what I gathered our plan of attack was (1). ie Our first module would > be the DBPool. We would extract it from somewhere (say turbine) refactor > it. Then push it back into turbine with a wrapper that integrates it into > the turbine framework. We would then try to integrate it into struts and > anyone else that uses DB pools. Then we would pick another component and do > the same. Have I got this correct/wrong? And why not letting the original authors of a component decide for themself what to do with a component ? And why not let turbine decide if they want to share the component and how to do it ? What makes you think that whatever DBPool you choose will be better ? And what makes you think that a project will be happy to replace some code they developed and serve their purpose with something they have no control over ? Costin
Re: [POLL] General Consensus, Round 2
At 08:40 22/2/01 -0500, Ted Husted wrote: >[EMAIL PROTECTED] wrote: >> In any case - I hope Ted will include the 2 proposals in the final vote, >> and I'll let the majority decide what will be the goal and rules for this >> project. > >As near as I can figure we have already covered that ground, and the >current proposal already reflects what the majority of people >contributing to this list have decided. I am kinda confused ;) A few days ago I indicated the 4 paths I saw were 1. component repository (ie ToolForge+CJAN) 2. vetted/tested/approved components (ie Avalon+CJAN) 3. base util (Something similar to AUT - Apache Utility Toolkit). 4. gathering (3) is easily doable within current apache model. I believe Costin wants to work in (1) and Avalon covers enough of (2) that I don't see it worth creating a new project for. So what am I saying? ;) I am +1 for all but (2) which I am -1 on at the moment. >From what I gathered our plan of attack was (1). ie Our first module would be the DBPool. We would extract it from somewhere (say turbine) refactor it. Then push it back into turbine with a wrapper that integrates it into the turbine framework. We would then try to integrate it into struts and anyone else that uses DB pools. Then we would pick another component and do the same. Have I got this correct/wrong? Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-*
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > In any case - I hope Ted will include the 2 proposals in the final vote, > and I'll let the majority decide what will be the goal and rules for this > project. As near as I can figure we have already covered that ground, and the current proposal already reflects what the majority of people contributing to this list have decided. I am making my best effort, but if you feel differently, then you might like to submit a proposal of your own. We're all equal here; anyone with an email account can submit a proposal to this list, the Jakarta PMC, or the ASF board, whenever they like. -T.
Re: [POLL] General Consensus, Round 2
> > 1. A project should be able to share some code/components. I don't see > > myself using or participating in a library that is not open to all > > jakarta projects. And please don't call it library if the books are going > > to be selected by "library commiters". > > 1) I never called it a *library*. That got stuck on by Ted et al. I > wanted to call it 'Rupert', as there should be no preconcieved notions > with that name. Apologies to anyone named 'Rupert' by the way. I would > use 'Geir', but no one can pronounce it... :) This list is named "library-dev", and the I was mislead into believing the goal is to help projects to share code. That is something I am interested in. It seems you want to create (another) project that creates shared code ( avalon has exactly the same goal - if I read it corectly ). > 2) Why wouldn't you use it? If the stuff is good, and the APIs stable, > you would ignore it because, for example, Velocity (whose core has There is a lot of good stuff around , and plenty of choices for any component - I'll not "ignore", but I'll still look around for a real library to contribute to. > I guess, to follow the library analogy, a library still contains > individual books, that have been edited, published, and then selected by > the library. It's not like the general public stocks the shelves > themselves I don't think so - the library collects books written, edited and published by different people. I don't see how it can be called "open" if a group of authors are voting to allow other authors to add books to the library. In any case - I hope Ted will include the 2 proposals in the final vote, and I'll let the majority decide what will be the goal and rules for this project. I think it is very important to have a common place where projects can share code - but it doesn't have to be this project. It's up to the majority of each project to decide - and up to each individual to contribute and use whatever project he feel is right. I'll keep looking for a library :-) Costin
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > There are 2 issues: > 1. A project should be able to share some code/components. I don't see > myself using or participating in a library that is not open to all > jakarta projects. >> Committers join the library subproject in the same way they are entered to any >Jakarta subproject. This is what most people want, and so this is what will happen. Everyone has heard the arguments, and made their decision. We voted, and it's time to move on. If this is a showstopper for you, then so be it. No one wants you to do anything you don't want to do. > 2. > If a project is preparing for a release - it should be sure that it have > stable components to use ( even if he's not involved in writing the > components ). >> Each package has its own status file, release schedule, version number, QA tests, >documentation, mailing list, and bug category. Personally, I would build against the latest stable release of the package, unless a feature I needed had been added to a nightly build. If a later nightly build breaks my code, I can always roll back to the latest one that didn't. -T.
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > > > > I would also like to ask for something like: if a project is using a > > > component, and none of the project commiters are commiters for the > > > component - the project as a whole should count as a commiter ( > > > i.e. should be able to request a temporary freeze, a tag, etc - so a > > > "stable"/"predictible" version of the component can be included ). > > > ( it that's not too much ) > > There are 2 issues: > > 1. A project should be able to share some code/components. I don't see > myself using or participating in a library that is not open to all > jakarta projects. And please don't call it library if the books are going > to be selected by "library commiters". 1) I never called it a *library*. That got stuck on by Ted et al. I wanted to call it 'Rupert', as there should be no preconcieved notions with that name. Apologies to anyone named 'Rupert' by the way. I would use 'Geir', but no one can pronounce it... :) 2) Why wouldn't you use it? If the stuff is good, and the APIs stable, you would ignore it because, for example, Velocity (whose core has *nothing* to do with databases...) as a project doesn't have the right to veto a move by the DB Connection Pool group to do ? > Yes, you may have duplication - but > that's far better than having any group of people deciding what is the > "right" way. I don't care how "expert" or good is the group that makes > the selection - the library should be open to all jakarta projects > that want to share something, and the users should decide for themself > what to read. Ok. This is true if it's a library in the classical sense. That's not what I was looking for. And why? Every other project with a scope and focus has a group deciding the 'right way'. Tomcat has a group deciding the 'right way'. I guess, to follow the library analogy, a library still contains individual books, that have been edited, published, and then selected by the library. It's not like the general public stocks the shelves themselves > > 2. If a component is going to be shared, and more than a jakarta project > is going to use it - I would like all projects that are using the > component to have at least the right to tag the workspace and veto/fork if > a change is braking their code. Personally, I will not use a component in > tomcat if that component is going to change without any control from > tomcat - I would rather rewrite the component than risk the stability of > the project and the release. You can do that - if things really change, and you as a big user aren't getting listened to, and your needs aren't being met - then take the code and run. Why is this so different than the normal way of life? > If a project is preparing for a release - it should be sure that it have > stable components to use ( even if he's not involved in writing the > components ). Sure - just like I assume that tomcat is written to the released (stable) servlet spec, the released (stable) JDK, etc. - so if Tomcat uses the Jakarta Flargh component, specify the release version. A project should make available release versions for users. > Those are different items. I have no intention to participate in a > "closed" library ( neither as writer nor reader ). > > I think (2) would do a lot in encouraging projects to use the library, but > it's not that important for me ( well, as a tomcat commiter I would -1 > using a component that may change in the middle of a release without any > way to control that from tomcat side - but other projects may want to take > the risk ). Again, why? Why not just specify the version of the released component that you are using, and you are no longer at risk as long as that version is still offered as a complete jar (or source jar, or whatever...) which could be required of the projects. > > * This could result in a groady mess - if any 'regular Jakarta project' > > can at any time for any reason start another 'library sub-project', then > > there is *nothing* that compels people to work together. > > Any regular jakarta project can create code that is reusable - the library > commiters don't have any monopoly on reusable code. Right - true - but what I was looking for is a place for that resuable code could be presented as such. I know that Turbine has a DBCP. But it's not really clear. It's not clear how to use it. There are no "Here's how you use the Turbine connection pool..." docs. There are no usage examples of the Turbine connection pool, other than Turbine - and if I am a casual user looking for a componet, why dig out of a framework that offers no promises? > And if a projects wants to share this code - I think the library is the > right place, and the library commiters don't have a monopoly on "the right > way to do a component" - only users can decide if they want to use a piece > of code or not. Of course only users decide. How could you even imagine forcing that? And if a project wa
Re: [POLL] General Consensus, Round 2
> > I would also like to ask for something like: if a project is using a > > component, and none of the project commiters are commiters for the > > component - the project as a whole should count as a commiter ( > > i.e. should be able to request a temporary freeze, a tag, etc - so a > > "stable"/"predictible" version of the component can be included ). > > ( it that's not too much ) There are 2 issues: 1. A project should be able to share some code/components. I don't see myself using or participating in a library that is not open to all jakarta projects. And please don't call it library if the books are going to be selected by "library commiters". Yes, you may have duplication - but that's far better than having any group of people deciding what is the "right" way. I don't care how "expert" or good is the group that makes the selection - the library should be open to all jakarta projects that want to share something, and the users should decide for themself what to read. 2. If a component is going to be shared, and more than a jakarta project is going to use it - I would like all projects that are using the component to have at least the right to tag the workspace and veto/fork if a change is braking their code. Personally, I will not use a component in tomcat if that component is going to change without any control from tomcat - I would rather rewrite the component than risk the stability of the project and the release. If a project is preparing for a release - it should be sure that it have stable components to use ( even if he's not involved in writing the components ). Those are different items. I have no intention to participate in a "closed" library ( neither as writer nor reader ). I think (2) would do a lot in encouraging projects to use the library, but it's not that important for me ( well, as a tomcat commiter I would -1 using a component that may change in the middle of a release without any way to control that from tomcat side - but other projects may want to take the risk ). > * This could result in a groady mess - if any 'regular Jakarta project' > can at any time for any reason start another 'library sub-project', then > there is *nothing* that compels people to work together. Any regular jakarta project can create code that is reusable - the library commiters don't have any monopoly on reusable code. And if a projects wants to share this code - I think the library is the right place, and the library commiters don't have a monopoly on "the right way to do a component" - only users can decide if they want to use a piece of code or not. > * This last suggestion promotes a project using a component from the > role of user to a 'default committer status' with veto power, without > any required investment in the project itself ? Yes - that's exactly what I'm sugesting. I don't think any project will ( or should ) use a component if it doesn't have at least some control over the component. > * This dilutes the potential for 'productizing' some of the things > present here in Jakarta into packaged, usable compoenents, since nothing > prevents 7 connection pools from being in existance I fear > duplication of effort again... Nothing should prevent 7 connection pools. If you want to prevent duplication you should make sure that every project feels it's better ( for the project goals ) to use the existing connection pool instead of writing another one. Costin
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > > > [EMAIL PROTECTED] wrote: > > > In other words: I'll vote +1 if the final proposal will explicitely allow > > > projects to componentize and share their code, as Peter proposed (with > > > the maintainers of the shared component becoming library commiters ). > > > > You mean something like: > > > > + Packages extracted from stable ASF products, and refactored by their > > committers to current library standards, will also be accepted, along > > with the original committers to the package. > > Yes. > > I would also like to ask for something like: if a project is using a > component, and none of the project commiters are commiters for the > component - the project as a whole should count as a commiter ( > i.e. should be able to request a temporary freeze, a tag, etc - so a > "stable"/"predictible" version of the component can be included ). > ( it that's not too much ) I'm sorry. I don't mean to be a stick in the mud, but I *just* don't get it. I will try to be succinct. * This breaks the conventional Jakarta model for no reason that has been explicitly stated. * This could result in a groady mess - if any 'regular Jakarta project' can at any time for any reason start another 'library sub-project', then there is *nothing* that compels people to work together. * This last suggestion promotes a project using a component from the role of user to a 'default committer status' with veto power, without any required investment in the project itself ? * This dilutes the potential for 'productizing' some of the things present here in Jakarta into packaged, usable compoenents, since nothing prevents 7 connection pools from being in existance I fear duplication of effort again... yadda, yadda, yadda... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
--- [EMAIL PROTECTED] wrote: > > [EMAIL PROTECTED] wrote: > > > In other words: I'll vote +1 if the final > proposal will explicitely allow > > > projects to componentize and share their code, > as Peter proposed (with > > > the maintainers of the shared component becoming > library commiters ). > > > > You mean something like: > > > > + Packages extracted from stable ASF products, and > refactored by their > > committers to current library standards, will also > be accepted, along > > with the original committers to the package. > > Yes. > > I would also like to ask for something like: if a > project is using a > component, and none of the project commiters are > commiters for the > component - the project as a whole should count as a > commiter ( > i.e. should be able to request a temporary freeze, a > tag, etc - so a > "stable"/"predictible" version of the component can > be included ). > ( it that's not too much ) > > Costin That sounds like a real maintenance nightmare to me. It also breaks with the standard Jakarta paradigm for subprojects. Subprojects can organize themselves however they want, but they are not beholden to non-committers. If every Jakarta subproject used one or another component of the lib project (and that's the idea), it would be anarchy. = Morgan Delagrange Britannica.com __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
> [EMAIL PROTECTED] wrote: > > In other words: I'll vote +1 if the final proposal will explicitely allow > > projects to componentize and share their code, as Peter proposed (with > > the maintainers of the shared component becoming library commiters ). > > You mean something like: > > + Packages extracted from stable ASF products, and refactored by their > committers to current library standards, will also be accepted, along > with the original committers to the package. Yes. I would also like to ask for something like: if a project is using a component, and none of the project commiters are commiters for the component - the project as a whole should count as a commiter ( i.e. should be able to request a temporary freeze, a tag, etc - so a "stable"/"predictible" version of the component can be included ). ( it that's not too much ) Costin
Re: [POLL] General Consensus, Round 2
[EMAIL PROTECTED] wrote: > In other words: I'll vote +1 if the final proposal will explicitely allow > projects to componentize and share their code, as Peter proposed (with > the maintainers of the shared component becoming library commiters ). You mean something like: + Packages extracted from stable ASF products, and refactored by their committers to current library standards, will also be accepted, along with the original committers to the package. -T.
Re: [POLL] General Consensus, Round 2
On Fri, 23 Feb 2001, Peter Donald wrote: > At 07:41 22/2/01 -0500, Ted Husted wrote: > > >+ Committers join the library subproject in the same way they are > >entered to any Jakarta subproject. Being a committer in another Jakarta > >subproject is not a prerequisite, nor does it provide free entry to the > >library subproject. > > unless they are moving code from the other project and are willing to act > as caregiver and guardian ;) Peter, I think this would be a reasonable middle ground. I'll change my vote to a +1 if we agree on this issue: 1. A new package can be added by a majority vote of the commiters OR by a vote in a jakarta project that decides that a piece of the code is general and there are people willing to move the code and maintain it. 2. The maintainers of the piece that is going to be shared will become commiters on the library. If this is going to be a library, any "author" should be allowed in, even if it duplicates existing books or we don't agree with it's ideas - that should be fundamental in a library. Existing jakarta projects should be able to move existing code that is going to be shared in the library - and the vote should be in the source project ( since it'll be affected in quite a few ways - a piece that was under their control will be shared with other projects and some people will have to spend extra time making the code reusable and change the project to use the reusable component ). I don't think the library should be able to reject any particular project ( as long as the code follows the library standards ). Regarding commiters - you can have your way, I'm too tired and I have other things to do then argue. In other words: I'll vote +1 if the final proposal will explicitely allow projects to componentize and share thier code, as Peter proposed (with the maintainers of the shared component becoming library commiters ). Costin
Re: [POLL] General Consensus, Round 2
"Geir Magnusson Jr." wrote: > The Taglibs model is a singleton example of something very different : there is a >common thread (JSP taglib repository). At first gloss it may seem that way, but if you look at what the tags actually do, they seem as diverse as any packages we might propose: JDBC, BSF, JNDI, SQL, XSL -- a person qualified to work on one of these tags would not be automatically qualified to work on another. The tag part is a wrapper, the meat is the same as we would see in any library package. -T.
Re: [POLL] General Consensus, Round 2
I don't want to get too distracted with this thread, but I think I was misunderstood. More inline. Ted Husted wrote: > > "Geir Magnusson Jr." wrote: > > Obviously you think it does enough, Ted, or you wouldn't have written > > it. > > Not really. If Costin's model had gotten the majority vote, I would have > written that up instead. I'm perfectly capable of writing a proposal > that I might -1 myself, if it meant many others would +1 it instead. I > really am trying to find the model which is going to get the most > support, regardless of whether I would support it myself. I don't get this - I don't care personally what you are capable of doing - you are very capable of organizing w/o your personal views interfering. My point overall was that structure is a departure from the jakarta model, not simply a riff on what is already done. The Taglibs model is a singleton example of something very different : there is a common thread (JSP taglib repository). All the developers work in the same space - JSP tags - and it functions as a repository of closely related things. 'Library' is different - there is no common technology thread, other than Java, which is kinda weak. > > Does this model work for Jakarta? I mean, you would be a 'Jakarta > > player', etc, etc > > It works for Taglibs, so we're just following suit and not creating > anything new. It's a different kind of project. I don't think they map. > > If not, why not, and more importantly, where is the boundary? I imagine > > some of what we propose could be just as 'project-like' as log4j, oro, > > regex, etc.. and they appear to function just fine as is. > > I'm not sure if that's true. Log4j is fine, but I believe people have > questioned the wisdom of having packages like RegEx, Oro, and others > just floating around unattached. I am not familiar with that discussion , but I would imagine that its centered around the issue of organization of projects, rather than a need to change the committer & governance model. Again, I am unfamiliar with that discussion. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
+1. Why quibble? :) --- Ted Husted <[EMAIL PROTECTED]> wrote: > (1) > > OLD BUSINESS > > To finalize the first round, I'd like to get a > majority vote on these > revised points of consensus. I believe these points > represent the > consensus opinion. In the interest of unity, if > possible, please provide > a single vote on the points as a block. > > This poll will expire in 5 days, or when the > committers on the active > roster (below) have responded. > > + The primary unit of reuse and release is the > package. > > + The package library is not a framework but a > repository of codebases > designed to be shared. > > + Each package must have a clearly defined purpose, > scope, and API -- Do > one thing well, and keep your contracts. > > + Each library package is treated as a product in > its own right. > > - - Each package has its own status file, release > schedule, version > number, QA tests, documentation, mailing list, and > bug category. > > - - Each package must clearly specify any external > dependencies, > including any other library packages, and the > earliest JDK version > required. > > - - - External dependencies on optional and > third-party codebases should > be minimized. > > + Each package maintains a list of its active > committers in its status > file. > > + The packages should use a standard scheme for > versioning, QA tests, > and directory layouts, and a common format for > documentation and Ant > build files. > > + The packages should fit within a unified package > hierarchy. > > + In general, packages should define an abstract > interface, and provide > one or more implementations of that interface. > > + The packages should have boring functional names. > Implementations may > choose more "exciting" designations. > > + Packages are encouraged to either use JavaBeans as > core objects, a > JavaBean-style API, or to provide an optional > JavaBean wrapper. > > + External configuration files are discouraged, but > if required, XML > format files are preferred for configuration > options. > > + The package library subproject shall be proposed > as a Jakarta > subproject. > > + Each package will be hosted on its own page on the > subproject Web > site, and will also be indexed in a master catalog. > > + The subproject catalog will also provide a > distribution mechanism. > > + The subproject will also host top-level "general" > and "announcement" > mailing lists. > > + The subproject will also provide a single JAR of > all stable package > releases. It may also provide a second JAR with a > subset of only JDK 1.1 > compatible releases. A gump of nightly builds will > also be provided. > > + Committers join the library subproject in the same > way they are > entered to any Jakarta subproject. Being a committer > in another Jakarta > subproject is not a prerequisite, nor does it > provide free entry to the > library subproject. > > + Each committer has karma for all the library > packages, but is expected > to add their name to a package's status file before > their first commit > to that package. > > + The library committers shall elect a committee of > three committers to > provide general oversight, in the style of the > Jakarta PMC. > > + New packages may be proposed to the library > general list, and voted on > by all committers. To be accepted, a package > proposal must receive a > positive 3/4's vote of the library committers. > Packages proposed are > expected to be used by one or more ASF products. > > (2) > > NEW BUSINESS > > The first packages on the library agenda will be: > > JDBC connection pool > > and > > Testing Framework > > Work on these packages will coincide with work on > the library subproject > infrastructure. > > Additional codebases to consider for the Testing > Framework include > > http://sourceforge.net/projects/j2eeunit - Vincent > Massol > http://sourceforge.net/projects/arrowhead/ - Kevin > Burton > > --- > > Roll of Active Committers (those responding to the > last poll) > > Costin < [EMAIL PROTECTED] > > Rodney Waldhoff < [EMAIL PROTECTED] > > Ignacio J. Ortega < [EMAIL PROTECTED] > > Bhamidi Krishna < [EMAIL PROTECTED] > > Geir Magnusson Jr. < [EMAIL PROTECTED] > > Ted Husted < [EMAIL PROTECTED] > > Federico Barbieri < [EMAIL PROTECTED] > > Peter Donald < [EMAIL PROTECTED] > > Ceki < [EMAIL PROTECTED] > > Morgan Delagrange < [EMAIL PROTECTED] > > > -Ted. = Morgan Delagrange Britannica.com __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [POLL] General Consensus, Round 2
"Geir Magnusson Jr." wrote: > Obviously you think it does enough, Ted, or you wouldn't have written > it. Not really. If Costin's model had gotten the majority vote, I would have written that up instead. I'm perfectly capable of writing a proposal that I might -1 myself, if it meant many others would +1 it instead. I really am trying to find the model which is going to get the most support, regardless of whether I would support it myself. > Does this model work for Jakarta? I mean, you would be a 'Jakarta > player', etc, etc It works for Taglibs, so we're just following suit and not creating anything new. > If not, why not, and more importantly, where is the boundary? I imagine > some of what we propose could be just as 'project-like' as log4j, oro, > regex, etc.. and they appear to function just fine as is. I'm not sure if that's true. Log4j is fine, but I believe people have questioned the wisdom of having packages like RegEx, Oro, and others just floating around unattached. > (Although doing it to avoid bothering Brian B is a good reason in itself > :) +1
Re: [POLL] General Consensus, Round 2
Ted Husted wrote: > > "Geir Magnusson Jr." wrote: > > I am not sure adding to a file does much. > > I think it does enough, Geir. Remember, to add their name to that file > they would have already been voted in as a committer to some other > package. So, we already know that they are a "package player". Obviously you think it does enough, Ted, or you wouldn't have written it. Does this model work for Jakarta? I mean, you would be a 'Jakarta player', etc, etc If so, that sounds like it would make Costin happy, and cement the Jakarta community idea. If not, why not, and more importantly, where is the boundary? I imagine some of what we propose could be just as 'project-like' as log4j, oro, regex, etc.. and they appear to function just fine as is. Not trying to stir mud here, but this has been a fundamental point of debate for almost the life of this discussion. From my limited exposure to it, the Jakarta model does work, and I don't understand why we need to improvise. If it doesn't work, then this may be a great venue to try and improve it (and I am all for that), but I think we should identify specific problems and target them. (Although doing it to avoid bothering Brian B is a good reason in itself :) geir > Worst case, the other committers veto an ill-considered change and > rollback the CVS. > > -T. -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
"Geir Magnusson Jr." wrote: > I am not sure adding to a file does much. I think it does enough, Geir. Remember, to add their name to that file they would have already been voted in as a committer to some other package. So, we already know that they are a "package player". Worst case, the other committers veto an ill-considered change and rollback the CVS. -T.
Re: [POLL] General Consensus, Round 2
Ted Husted wrote: > > "Geir Magnusson Jr." wrote: > > Why? Why not let packages be the 'project' and let them run themselves? > > Looking over the responses to the round 1, > > < http://husted.com/about/jakarta/lib002.htm > > > it was my feeling that the consensus leaned toward the "Taglibs" model. > Committers have access in fact, but practice discourages people form > running in and hacking a codebase you haven't worked on. And, after all, > we do have the CVS to help protect us from ourselves ;-). Hm. Ok. I'll take a look. I didn't get that as the consensus at all (as I saw a pretty much even split between library-as-mini-jakarta and library-as-community-oriented-sourceforge, with the taglibs model there as well a little. I will review the results so far... > We are modifying the Tabligs model slightly, in that we are asking the > active committers to a package list themselves in the status file. > Again, reinforcing that working on a package is a commitment, and not a > casual hack, and that each package is an entity unto itself. I am not sure adding to a file does much. > This also eliminates the overhead of a person with sufficient clearance > (like Brian B) being bothered every time we need to upgrade someone's > access. Heh. Shouldn't we try to get *that* fixed? -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/
Re: [POLL] General Consensus, Round 2
"Geir Magnusson Jr." wrote: > Why? Why not let packages be the 'project' and let them run themselves? Looking over the responses to the round 1, < http://husted.com/about/jakarta/lib002.htm > it was my feeling that the consensus leaned toward the "Taglibs" model. Committers have access in fact, but practice discourages people form running in and hacking a codebase you haven't worked on. And, after all, we do have the CVS to help protect us from ourselves ;-). We are modifying the Tabligs model slightly, in that we are asking the active committers to a package list themselves in the status file. Again, reinforcing that working on a package is a commitment, and not a casual hack, and that each package is an entity unto itself. This also eliminates the overhead of a person with sufficient clearance (like Brian B) being bothered every time we need to upgrade someone's access. -Ted.
Re: [POLL] General Consensus, Round 2
Ted Husted wrote: > > (1) > > OLD BUSINESS > > To finalize the first round, I'd like to get a majority vote on these > revised points of consensus. I believe these points represent the > consensus opinion. In the interest of unity, if possible, please provide > a single vote on the points as a block. > > This poll will expire in 5 days, or when the committers on the active > roster (below) have responded. > > + The primary unit of reuse and release is the package. > > + The package library is not a framework but a repository of codebases > designed to be shared. Can this be clarified or omitted? 'Shared' is obvious in open source, isn't it? > + Each package must have a clearly defined purpose, scope, and API -- Do > one thing well, and keep your contracts. > > + Each library package is treated as a product in its own right. > > - - Each package has its own status file, release schedule, version > number, QA tests, documentation, mailing list, and bug category. I think Peter's suggestion of a general list is a good one, except can we put some kind of mechanism to help filter? > - - Each package must clearly specify any external dependencies, > including any other library packages, and the earliest JDK version > required. > > - - - External dependencies on optional and third-party codebases should > be minimized. > > + Each package maintains a list of its active committers in its status > file. > > + The packages should use a standard scheme for versioning, QA tests, > and directory layouts, and a common format for documentation and Ant > build files. > > + The packages should fit within a unified package hierarchy. > > + In general, packages should define an abstract interface, and provide > one or more implementations of that interface. I don't know if that makes sense always : - there are some things where the interface is clear and defined elsewhere (ex JDBC) - multiple implementations that are indistinguishable in function and feature add nothing but confusion for users. This might be best left to individual packages. > + The packages should have boring functional names. Implementations may > choose more "exciting" designations. ? > + Packages are encouraged to either use JavaBeans as core objects, a > JavaBean-style API, or to provide an optional JavaBean wrapper. > > + External configuration files are discouraged, but if required, XML > format files are preferred for configuration options. > > + The package library subproject shall be proposed as a Jakarta > subproject. > > + Each package will be hosted on its own page on the subproject Web > site, and will also be indexed in a master catalog. > > + The subproject catalog will also provide a distribution mechanism. > > + The subproject will also host top-level "general" and "announcement" > mailing lists. Might be good to combine these into a library-wide list. Just prefix the subject ? [ANNOUNCEMENT : DBCP ] > + The subproject will also provide a single JAR of all stable package > releases. It may also provide a second JAR with a subset of only JDK 1.1 > compatible releases. A gump of nightly builds will also be provided. > > + Committers join the library subproject in the same way they are > entered to any Jakarta subproject. Being a committer in another Jakarta > subproject is not a prerequisite, nor does it provide free entry to the > library subproject. But can it be noted that it helps? > + Each committer has karma for all the library packages, but is expected > to add their name to a package's status file before their first commit > to that package. Why? Why not let packages be the 'project' and let them run themselves? > + The library committers shall elect a committee of three committers to > provide general oversight, in the style of the Jakarta PMC. > > + New packages may be proposed to the library general list, and voted on > by all committers. To be accepted, a package proposal must receive a > positive 3/4's vote of the library committers. Packages proposed are > expected to be used by one or more ASF products. > Other than the issues noted, +1 > (2) > > NEW BUSINESS > > The first packages on the library agenda will be: > > JDBC connection pool +! Yay! > and > > Testing Framework +0 > Work on these packages will coincide with work on the library subproject > infrastructure. > > Additional codebases to consider for the Testing Framework include > > http://sourceforge.net/projects/j2eeunit - Vincent Massol > http://sourceforge.net/projects/arrowhead/ - Kevin Burton > > --- > > Roll of Active Committers (those responding to the last poll) > > Costin < [EMAIL PROTECTED] > > Rodney Waldhoff < [EMAIL PROTECTED] > > Ignacio J. Ortega < [EMAIL PROTECTED] > > Bhamidi Krishna < [EMAIL PROTECTED] > > Geir Magnusson Jr. < [EMAIL PROTECTED] > > Ted Husted < [EMAIL PROTECTED] > > Federico Barbieri < [EMAIL PROTECTED] > > Peter Donald < [EMAIL PROTECTED] > > Ceki < [EMAIL PROTECTED] > >
Re: [POLL] General Consensus, Round 2
At 07:41 22/2/01 -0500, Ted Husted wrote: >+ The primary unit of reuse and release is the package. > >+ The package library is not a framework but a repository of codebases >designed to be shared. > >+ Each package must have a clearly defined purpose, scope, and API -- Do >one thing well, and keep your contracts. > >+ Each library package is treated as a product in its own right. > >- - Each package has its own status file, release schedule, version >number, QA tests, documentation, mailing list, and bug category. egads ! ;) maybe not a separate mailing list ;) A general list may help build a community. If it becomes crowded we can always split it up later. Seeing discussion on components may prompt others to use that component. >- - Each package must clearly specify any external dependencies, >including any other library packages, and the earliest JDK version >required. > >- - - External dependencies on optional and third-party codebases should >be minimized. > >+ Each package maintains a list of its active committers in its status >file. > >+ The packages should use a standard scheme for versioning, QA tests, >and directory layouts, and a common format for documentation and Ant >build files. +10 ;) >+ The packages should fit within a unified package hierarchy. > >+ In general, packages should define an abstract interface, and provide >one or more implementations of that interface. Not a requirement as such. A package should do one thing well. If there can be multiple strategies for doing it then have interface-implementation difference. However most components don't need to have multiple implementations. >+ The packages should have boring functional names. Implementations may >choose more "exciting" designations. > >+ Packages are encouraged to either use JavaBeans as core objects, a >JavaBean-style API, or to provide an optional JavaBean wrapper. > >+ External configuration files are discouraged, but if required, XML >format files are preferred for configuration options. and read in by one of the standard XML config systems (ie digester/configuration or tomcat 3.xs one - whatever that is ;]) >+ The package library subproject shall be proposed as a Jakarta >subproject. > >+ Each package will be hosted on its own page on the subproject Web >site, and will also be indexed in a master catalog. > >+ The subproject catalog will also provide a distribution mechanism. > >+ The subproject will also host top-level "general" and "announcement" >mailing lists. > >+ The subproject will also provide a single JAR of all stable package >releases. It may also provide a second JAR with a subset of only JDK 1.1 >compatible releases. A gump of nightly builds will also be provided. > >+ Committers join the library subproject in the same way they are >entered to any Jakarta subproject. Being a committer in another Jakarta >subproject is not a prerequisite, nor does it provide free entry to the >library subproject. unless they are moving code from the other project and are willing to act as caregiver and guardian ;) >+ Each committer has karma for all the library packages, but is expected >to add their name to a package's status file before their first commit >to that package. > >+ The library committers shall elect a committee of three committers to >provide general oversight, in the style of the Jakarta PMC. If it's needed. Until we can an army of developers I would suggest that it is just overhead. When we hit some critical mass (say 15-20 developers) then this would be something to consider then. >+ New packages may be proposed to the library general list, and voted on >by all committers. To be accepted, a package proposal must receive a >positive 3/4's vote of the library committers. Packages proposed are >expected to be used by one or more ASF products. > Other than points above +1 >(2) > >NEW BUSINESS > >The first packages on the library agenda will be: > >JDBC connection pool +0 Nice idea but I don't know enough to help ;) I could help with formalizing the other boring process stuff and setting up build docs etc though... >Testing Framework > >Work on these packages will coincide with work on the library subproject >infrastructure. > >Additional codebases to consider for the Testing Framework include > >http://sourceforge.net/projects/j2eeunit - Vincent Massol Theres also HttpUnit which would be very useful at Apache and it's "owner" was amicable to donation last time I mentioned it ;) However we should make sure it is adopted by projects inside Apache before we try to adopt such projects. >http://sourceforge.net/projects/arrowhead/ - Kevin Burton It is dual licensed and GPLed so a no go unfortunately. It is however based on testlet from avalon CVS under jakarta-avalon-testlet. Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy
