Re: [POLL] Re: Code Sharing Concepts
on 2/15/01 11:56 AM, Craig R. McClanahan at [EMAIL PROTECTED] wrote: I don't have any time to waste on anarchy-based shared code repositories. I have lots of time to spend, and useful code to contribute, to a shared repository that I know I can confidently use in my projects, based on process management rules that include protection from arbitrary API changes. I agree wholeheartedly with this statement. -- James Duncan Davidson http://x180.net/ !try; do(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Craig R. McClanahan" wrote: "Geir Magnusson Jr." wrote: [EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). One small proto-model of "shared code" code components already exists within the Jakarta community, and might serve as a starting point for discussions -- the Jakarta Taglibs project, which is focused on creating reuseable JSP custom tag libraries. This is your FOO, and BAR then is clearly defined. To me, this is a FOO that is generic - like 'visual component' or 'bean' - it is a general class of software where the functionaly is a degree of freedom left to the creativity of the developer. So you can say "Here is a collection of FOO, listed by functionality." I think this is a valuable model - clearly the Taglibs projects shows it's a valuable model. But I am not sure that all the projects in 'Rupert' would work well this way. For the 'single-instance' model, it would be harder to say "Here is a collection of JDBC-compliant DB connection pools". How can you distinguish? There certainly is space for both, or if you make FOO generic enough in each case, then the overall project model can consists of a set of libraries, each hosting a subject area : POOLS : (works as library ) - generic object pool - JDBC DB connection pool - ? XML Configuration : (works as library) - this would be a big list ETC: And each library (POOLS, XML Config) could manage the components within in, similar to how a Jakarta project manages its own work. [SNIP] As long as you avoid a rule that there will be only one kind of FOO in the library, that should avoid most of the potential conflict issues. Yes, but we should recognize that if the multiple FOO are something like a DB Connection Pool, the 'rule' would be that the differences in features and uses should be *clearly* enunciated, to the point of making sure the non-Jakarta developer looking for a solution can easily understand the differences, and make a decision. Otherwise, they *will* go elsewhere. Maybe my concern for the non-Jakarta developer is misplaced or misaligned with the intent here, but as I have said before, there seems to be an *enormous* amount of useful code for the Java developer scattered around, and finding a way of clearly describing, presenting and organizing it for general use would do the development community (and ourselves - nothing beats writing software that is actually used) a big favor. In order to make this work, someone(s) needs to step up and organize the basic infrastructure, but after that it can be fairly self-sustaining. (And maybe Sam can extend Gump to see which individual modules are being used in which projects -- having your shared code selected by some other project is a pretty good vote on it's quality, plus an indication of who you should talk to before changing APIs ;-). that's a great idea. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] typed the following on 04:17 PM 2/15/2001 -0800 Seriously speaking - I am very concerned with the content of the library - I have a feeling that some people would like one book for each subject. I think that would be a very big step backwards. My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. I agree, it's important to allow different ideas to flower rather than impose a "one true way" philosophy. But I also think it's important to keep strong quality control on anything that goes out under the Apache/Jakarta names. Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: Seriously speaking - I am very concerned with the content of the library - I have a feeling that some people would like one book for each subject. I think that would be a very big step backwards. My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. +1. My own hope is that each component be treated like a book, with it's own publication date, edition count, and set of authors and editors. I would also hope that this subproject might eventually serve as a model for * another * project yet to come, that would work more like a Braughtigan library -- all donations accepted. But, family first. For this branch, we probably need a relevance criteria -- that the component is something that * could be * shared among other ASF subprojects. Though, I would think whether a product actually uses a component, or whether products use different flavors of similar components, is something the subproject committers have to decide for themselves. We can lead the subprojects to water, but we can't make them drink. And if getting them to drink means providing more than one trough, then so be it! -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Sam Ruby wrote: the name of the mailing list should match the name of the subproject. I'm willing to create the mailing list in anticipation of the project being created, but it like to be sure that the name is what everybody wants. The name is one of the things we would discuss on the list. This would only be a temporary list. Should a proposal be accepted, a new list named for the subproject would be created. If you are not comfortable with that, maybe an independent list is a better way to go while a proposal is pending. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. I agree, it's important to allow different ideas to flower rather than impose a "one true way" philosophy. But I also think it's important to keep strong quality control on anything that goes out under the Apache/Jakarta names. Except that we should act as librarians or even critics for the code, not censors. The books that are going to go in library are written by Apache authors, part of apache projects. Sometimes is too easy to say something is "not good" because we don't understand it. The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
My own hope is that each component be treated like a book, with it's own publication date, edition count, and set of authors and editors. And again - we'll act as librarians and make sure the book is available, not as censors or authors of competing books. For this branch, we probably need a relevance criteria -- that the component is something that * could be * shared among other ASF subprojects. Though, I would think whether a product actually uses a component, or whether products use different flavors of similar components, is something the subproject committers have to decide for themselves. We can lead the subprojects to water, but we can't make them drink. I believe we are trying to solve the wrong problem. I think the problem is not "reuse", but "sharing". It's not "making them drink", but making sure the water is clean. If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. That's why I think a library would be very good - not because it'll force people to read, but because it'll make authors to make their code more reusable and deal with the sharing problems. It may eliminate all the ugly dependencies between a suposedly "shared" component and the project that hosts it. Or eliminate the claim that the component is shared. CPAN is great because it makes Perl writters to follow some conventions ( make the code modular, etc ) - it helps sharing the code. It doesn't even try to choose or judge or create code... Nor to force people to reuse. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). How can that work in the current "project committer" model? I agree that it should be open to accept projects from the 'outside', but I think that to do that, it is required that it convert to the regular development model going forwards. I don't even know what we are talking about anymore : a 'CJAN' or 'Jakarta Tools' (aka Rupert :) project? I want to participate in a Jakarta Tools project, as I see a need (personal, communal, and global) for high-quality tools for building server based applications in Java. I know people who will go looking at application servers because they want a good connection pool, and that doesn't make sense to me. Jakarta is rich in general-use tools. We just need to get them out into the light of day, documented, and supported directly, not incidentally as part of larger projects. I know I am relatively new, and I am not criticizing. I just think there is a huge opportunity here. :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote:
Jakarta is rich in general-use tools. We just need to get them out into
the light of day, documented, and supported directly, not incidentally
as part of larger projects.
I believe you and I are on the same page, Geir. Costin wants to go a
different way with this. Which way the proposal goes would depend on a
vote of proposed committers. That could in turn affect how many interim
committers join the actual subproject.
I'll set up an interim list this weekend, and we can circulate a
questionnaire that covers the various points of view we've seen here.
Depending on the responses to the questionaire, and any subsequent
discussion, we can prepare a formal proposal, and vote on that.
Here are some preliminary notes of what I was going to suggest when the
list opens.
--
The business of this group will be conducted according to the Jakarta
guidelines and common practices.
Final vote on proposal will be by super-majority (3/4 of interim
committers)
All other polls and votes by active majority
+1 like it, can help;
+0 like it, but can't help;
-0 don't like it, can't help;
-1 don't like it, lets do this instead: {alternative}.
All polls and votes expire in five days (120 hours) or when all
committers have replied.
Since this is an interim group, participation is more important than
ever. All interim committers are strongly encouraged to reply to every
[POLL] or [VOTE] thread posted by another interim committer.
(If it helps, post a flat zero "(0)" vote, if you really don't care
about something.)
New interim committers to a proposed subproduct are welcome, and may
voted in by the existing subproduct
committers in the usual way.
--
Meanwhile, I'd like to see a CJAN someday, but that's not something I
would comfortable working on right now. It may also be outside what the
ASF wants to do. My hope would be that we can define an infrastructure
for a small number of components that might be used as the basis for a
larger project, which any interested party could host.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). How can that work in the current "project committer" model? I agree that it should be open to accept projects from the 'outside', but I think that to do that, it is required that it convert to the regular development model going forwards. Not code from outside - we don't know what to do with our own code... Each jakarta project already has lots of code that could be shared - that's what we need to resolve first. I want to participate in a Jakarta Tools project, as I see a need (personal, communal, and global) for high-quality tools for building server based applications in Java. I know people who will go looking at application servers because they want a good connection pool, and that doesn't make sense to me. I'm not sure I agree with that. My view of Jakarta Tools is not a project where connection pools are developed - but a project where connection pools developed in other projects or used by multiple projects are shared. If 2 apache projects are using a similar piece of code, and at least one wants to share it - rupert/alexandria/tools should be the place where the shared code should be hosted ( or both - if both projects want to share). The development should be done by the people who are using the code. I believe the problem we need to solve is sharing - it doesn't mean "I have a connection pool, you can use it", it also mean designing the connection pool in a modular way ( not "you can use it, but you need the whole project to use it"), and sharing the future development and control over that component ( including interface stability and giving -1 power to the people we share it with ). As for commiters - each component will have a set of commiters ( but "share" means the set is not formed only from original authors, but other commiters from jakarta projects the component is shared with ) Jakarta is rich in general-use tools. We just need to get them out into the light of day, documented, and supported directly, not incidentally as part of larger projects. +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). That's also a sharing problem - the code is too deep inside a project. BTW, blaming the users ( for using the wrong OS for example ) is not working. Changing the code and placing it where it can be found may help. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). That's also a sharing problem - the code is too deep inside a project. BTW, blaming the users ( for using the wrong OS for example ) is not working. Changing the code and placing it where it can be found may help. That's what I am advocating - Getting this stuff out front and center. I am not blaming the users. Its our fault if people don't know what the projects are about and have available. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote: [EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). One small proto-model of "shared code" code components already exists within the Jakarta community, and might serve as a starting point for discussions -- the Jakarta Taglibs project, which is focused on creating reuseable JSP custom tag libraries. The encouraged sharing is in this case at the end developer's application level, rather than within the Jakarta community itself, but some practices we created there might be useful models to look at. Basically, developers on Taglibs agree to the following conventions and policies: * No particular concern about overlaps of functionality - different applications care about different features and might appreciate alternative approaches. * Committers essentially take ownership of the pieces they care about, and agree to offer at least some level of ongoing support. * Organize their tag library directories according to standard conventions (source, example app, documentation) and package naming hierarchies that quickly become familiar to library users. * Construct semi-autonomous releases of individual tag libraries, plus a convenient way to go grab them all. Formal versioning hasn't been an issue yet because the whole thing is pretty new, but that will need to be addressed. * Make information (essentially, the documenation associated with each tag library) available online and accessible. Having one or more FOO modules in a shared library doesn't help any more than the current situation, if I don't know about them or cannot find anything out about them. It would seem reasonable to adopt some set of conventions like this for the sorts of code modules we're discussing here. That way, people whose itch is creating shareable modules have a place to showcase their wares, and people who would rather reuse than write have a place to "shop". As long as you avoid a rule that there will be only one kind of FOO in the library, that should avoid most of the potential conflict issues. In order to make this work, someone(s) needs to step up and organize the basic infrastructure, but after that it can be fairly self-sustaining. (And maybe Sam can extend Gump to see which individual modules are being used in which projects -- having your shared code selected by some other project is a pretty good vote on it's quality, plus an indication of who you should talk to before changing APIs ;-). geir Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Hear hear! I think that Taglibs is an excellent model for a library-oriented subproject. Here are some features of Taglibs (some overlap with Craig's comments) that I think would translate quite well: * individual landing pages for each taglib (essentially sub-subprojects) * standardized documentation formats in most taglibs * clearly defined divisions between tag libraries in the CVS repository * "courteous" interaction between taglib developers (i.e., I don't muck about with your taglib without asking) * lots of user interaction on the dev list esp. concerning release candidates (which neutrilizes maverick developer syndrome and reduces the necessary number of committers) * reasonable scope boundaries (e.g. the JDBC taglib doesn't do database pooling, that's what utility libraries are for!) * it's fun to work on! Although I'm not interested in being a committer on any of the other proposed library sub-subprojects at this time, I'd be happy to help out with the "Library Infrastructure" sub-subproject, if the goal is a Taglibs-like organization for the project and the site. - Morgan --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: "Geir Magnusson Jr." wrote: [EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). One small proto-model of "shared code" code components already exists within the Jakarta community, and might serve as a starting point for discussions -- the Jakarta Taglibs project, which is focused on creating reuseable JSP custom tag libraries. The encouraged sharing is in this case at the end developer's application level, rather than within the Jakarta community itself, but some practices we created there might be useful models to look at. Basically, developers on Taglibs agree to the following conventions and policies: * No particular concern about overlaps of functionality - different applications care about different features and might appreciate alternative approaches. * Committers essentially take ownership of the pieces they care about, and agree to offer at least some level of ongoing support. * Organize their tag library directories according to standard conventions (source, example app, documentation) and package naming hierarchies that quickly become familiar to library users. * Construct semi-autonomous releases of individual tag libraries, plus a convenient way to go grab them all. Formal versioning hasn't been an issue yet because the whole thing is pretty new, but that will need to be addressed. * Make information (essentially, the documenation associated with each tag library) available online and accessible. Having one or more FOO modules in a shared library doesn't help any more than the current situation, if I don't know about them or cannot find anything out about them. It would seem reasonable to adopt some set of conventions like this for the sorts of code modules we're discussing here. That way, people whose itch is creating shareable modules have a place to showcase their wares, and people who would rather reuse than write have a place to "shop". As long as you avoid a rule that there will be only one kind of FOO in the library, that should avoid most of the potential conflict issues. In order to make this work, someone(s) needs to step up and organize the basic infrastructure, but after that it can be fairly self-sustaining. (And maybe Sam can extend Gump to see which individual modules are being used in which projects -- having your shared code selected by some other project is a pretty good vote on it's quality, plus an indication of who you should talk to before changing APIs ;-). geir Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Morgan Delagrange Britannica.com __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
At 07:26 12/2/01 -0500, Ted Husted wrote: On 2/9/2001 at 8:12 AM Sam Ruby wrote: I would suggest that you start with a proposed code base. Going back over the posts, there seem to be at least five clear areas of overlap: * DataSource/Database Pool * XML Configuration +1 * Message Resources / i18n +1 * JNDI / Naming +1 * Testing Suites +1 if that means suites for products I indicated above, +1 also if it means integrating all the test frameworks into one. I would also like to hear from the struts bean utils. I haven't looked at them but I presume they would be general enough (or could be made so) so Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0 codebase). 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 | *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Peter Donald wrote: I would also like to hear from the struts bean utils. I haven't looked at them but I presume they would be general enough (or could be made so) so Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0 codebase). They are -- and they have dependencies only on JDK classes for the following org.apache.struts.util classes: BeanUtils, ConvertUtils, and PropertyUtils. Javadocs are online at http://jakarta.apache.org/struts/api/index.html I haven't voted yet in this thread because I haven't seen anyone else say "let's figure out the process issues first." I guess it's not as interesting as writing code :-), but it is very much as important to a shared resource like this. I will coordinate contributing any or all of the code listed at the bottom of my "Code Sharing Concepts" message, but I'm definitely not interested in making any project I'm a part of dependent on an ad hoc collection of code with no rules about who can change what. I've been bitten way too many times in that scenario. Cheers, Pete Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ok, sorry I was a bit late on the draw here, while I doubt my programming skills are up to snuff, I would love to help out with the following in any way I can: DATASOURCE/DATABASE POOL +1 I can test the heck out of these and perhaps help with a bit of the documentation... SUBPROJECT INFRASTRUCTURE [*] - Subproject infrastructure: website, documentation, sample applications, test suites, quality assurance. [Tinderbox] ? [GUMP] ? +1 Just let me know what needs to be done... -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ - 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: [POLL] Re: Code Sharing Concepts
"Craig R. McClanahan" wrote: I haven't voted yet in this thread because I haven't seen anyone else say "let's figure out the process issues first." I guess it's not as interesting as writing code :-), but it is very much as important to a shared resource like this. My thinking on the next step would be to draft a formal proposal for consideration by the proposed committers, for comments, discussions, revisions, and eventually a vote in the usual way. Also in the usual way, these discussions could take place on an interim list (off Jakarta) to which the proposed committers, and other interested parties, can subscribe. Of course, when it comes to a vote, only those of the proposed committers would be binding, again in the usual way. There are many packages which would make good candidates for the library. To find a starting set, I simply looked for packages where there was already overlap. But, if no one disagrees, let's hereby amend the POLL to include -- [Struts] Bean Introspection support - BeanUtils, PropertyUtils, and ConvertUtils classes have generic support for managing JavaBean property setting and getting through the use of the Java Reflection APIs, including support for nested and indexed property expressions. -- If you or Pete or anyone else would like to commit to this proposed codebase, please reply with your +1. I think this subproject has tremendous potential, but like all Apache subprojects, the decision-making has to be pushed down to the people who are willing to do the work. So before we can make any decisions, we need to find out who will do the work, and let them decide. I know you are one of those people, Craig, and I think you know I won't let the process issues slide. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
David Weinrich wrote: Ok, sorry I was a bit late on the draw here Glad to have you aboard, David, especially since as near as I can figure, you're the one that started this thread! http://www.mail-archive.com/general@jakarta.apache.org/msg00018.html (This time, at least ;-) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: There are many packages which would make good candidates for the library. To find a starting set, I simply looked for packages where there was already overlap. But, if no one disagrees, let's hereby amend the POLL to include -- [Struts] Bean Introspection support - BeanUtils, PropertyUtils, and ConvertUtils classes have generic support for managing JavaBean property setting and getting through the use of the Java Reflection APIs, including support for nested and indexed property expressions. -- If you or Pete or anyone else would like to commit to this proposed codebase, please reply with your +1. As I stated in words rather than votes, and on this code base or any of the others in the polll that came from my original list: Before process management issues are worked out: -0 After process management issues are worked out: +1 I don't have any time to waste on anarchy-based shared code repositories. I have lots of time to spend, and useful code to contribute, to a shared repository that I know I can confidently use in my projects, based on process management rules that include protection from arbitrary API changes. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: Also in the usual way, these discussions could take place on an interim list (off Jakarta) to which the proposed committers, and other interested parties, can subscribe. Why off Jakarta? Whilst this group seems to have difficulty agreeing on anything grin, perhaps a proposal to create a new list could get enough support? Heck, it might even get some +1's from people that DON'T want to be subjected to this discussion any more. ;-) - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Geir Magnusson Jr. wrote: Call it 'Rupert'. Be careful, that name might stick. ;-) I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The are *SOME* things that the PMC are ready, willing, and able to enforce immediately. You just happened to pick one of them. Not to mention the fact that the likehood of a majority of Tomcat developers would be predisposed to consider such a thing is basically nil. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Sam Ruby wrote: Geir Magnusson Jr. wrote: Call it 'Rupert'. Be careful, that name might stick. ;-) That would be fine - forward progress! I guess the logo would be next... :) I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The are *SOME* things that the PMC are ready, willing, and able to enforce immediately. You just happened to pick one of them. Really? How's that? If all the developers decided to switch to the WGSfromPM, what could the PMC do? I am not trying to be argumentative - I just thought that the PMC was well described as 'general oversight' with project-specific issues pushed down to the project participants. If the tomcat developers, arguably some of the top-tier servlet infrastructure developers in the world, decided that the WGSfromPM was superior to Servlet 2.3 ? Granted, Craig would be looking for a new employer, I think... :) Not to mention the fact that the likehood of a majority of Tomcat developers would be predisposed to consider such a thing is basically nil. And back to the issue, that is kinda my point : if you have a group of developers committed to producing a top quality db connection pool for general use, it's not clear that there is much one could do to enforce API stability in an external way that makes sense. At some point, you have to trust someone involved with the project... geir - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Sam Ruby wrote: Whilst this group seems to have difficulty agreeing on anything grin, perhaps a proposal to create a new list could get enough support? Heck, it might even get some +1's from people that DON'T want to be subjected to this discussion any more. ;-) Ok, based on the response to the poll tallied at http://husted.com/about/jakarta/library.html may we please have a interim Jakarta "libary" mailing list for the purpose of formaling the details of a proposal for this subproject. If convenient, these individuals may be subscribed to list when it is installed, being the group of people who have agreed to committ to the proposed codebases. 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] David Weinrich [EMAIL PROTECTED] If an area of the Website were also available, we'd be happy to have that as well ;-) Of course, in the event the proposal were rejected or died in committee, we would expect the interim list and Web space to be cancelled. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: Sam Ruby wrote: Whilst this group seems to have difficulty agreeing on anything grin, perhaps a proposal to create a new list could get enough support? Heck, it might even get some +1's from people that DON'T want to be subjected to this discussion any more. ;-) Ok, based on the response to the poll tallied at http://husted.com/about/jakarta/library.html Man, you are *damn* organized :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote: You might think then that each partition could manage it's own issues, like the projects do. So given http://www.mail-archive.com/general@jakarta.apache.org/msg00154.html are we on the same page, Geir? Basically, I just want to nest everything we do for Jakarta subprojects into Library subproducts. (But then I may have spent too many years wired to a Pascal compiler ;-) I don't know what kind of process management rules one could have to ensure API stability other than responsibility to the users. I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The idea is that when a subproject is proposed, it will also define it's scope, or charter. The scope of the Tomcat subproject is to provide a reference implementation for the Sun Servlet and JSP specifications. If the committers did go insane and adopt another API, the subproject could be cancelled. And the ASF Chairman has alluded to doing just that with Ant. But that's another problem. I would imagine that we would do the same with our library subproducts. If the datasource team started building JDBC drivers, we'd have to ask if they were still within scope, or whether we needed another subproduct for that codebase. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Geir Magnusson Jr." wrote: Sam Ruby wrote: Geir Magnusson Jr. wrote: Call it 'Rupert'. Be careful, that name might stick. ;-) That would be fine - forward progress! I guess the logo would be next... :) I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The are *SOME* things that the PMC are ready, willing, and able to enforce immediately. You just happened to pick one of them. Really? How's that? If all the developers decided to switch to the WGSfromPM, what could the PMC do? I am not trying to be argumentative - I just thought that the PMC was well described as 'general oversight' with project-specific issues pushed down to the project participants. IMHO, the PMC would certainly behave as Sam indicated, but they probably wouldn't have to -- the ASF Board would undoubtedly say such a thing would be so far out of scope that it wouldn't be "Tomcat" any more. If the tomcat developers, arguably some of the top-tier servlet infrastructure developers in the world, decided that the WGSfromPM was superior to Servlet 2.3 ? Granted, Craig would be looking for a new employer, I think... :) Yah, especially if WGSfromPM == .NET's APIs or something like that :-) Not to mention the fact that the likehood of a majority of Tomcat developers would be predisposed to consider such a thing is basically nil. And back to the issue, that is kinda my point : if you have a group of developers committed to producing a top quality db connection pool for general use, it's not clear that there is much one could do to enforce API stability in an external way that makes sense. At some point, you have to trust someone involved with the project... My personal preferences in this regard are fairly simple -- publish APIs (or use existing ones where there are reasonable standards) that you promise reasonably stable contracts for, and innovate on the implementation(s) inside those APIs. When changes ultimately do occur, they should be designed to minimize the pain of adapting (through techniques like providing convenience base classes that most alternative implementations would have started from). For a connection pool in particular, the relavant API (for my needs, at least) is javax.sql.DataSource -- I want to be able to plug in *any* connection pool that conforms to that interface and use it. Turbine's pool (still) does not do this -- and that makes perfect sense, because it existed before the DataSource API was standardized. Changing Turbine's pool to conform to this would break the contracts for all existing Turbine apps that use it, which would not be a Good Thing. But in the mean time, without a wrapper around it -- I'm about 75% done with this, but unfortunately the wrapper will have to be bigger than the entire code for the Struts connection pool :-( -- the Turbine connection pool is not useful to me. Whether it is in a shared repository or not makes no difference. geir - Sam Ruby Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Jon Stevens wrote:
on 2/15/01 2:19 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
Turbine's pool (still) does not do
this -- and that makes perfect sense, because it existed before the DataSource
API was standardized. Changing Turbine's pool to conform to this would break
the contracts for all existing Turbine apps that use it, which would not be a
Good Thing.
I'm not sure that statement is true because...I have implemented all of the
JDBC 2.0 API for Turbine except that single one. It didn't break any
existing code to do so (except in one case where you now need to deal with a
SQLException that is now being thrown in the API and wasn't before...not a
big deal).
The one you haven't gotten to yet is the critical one that makes application code
portable. You will find that it is quite a bit more significant a change to
existing APIs than the ones you did.
The typical application usage pattern of a DataSource goes like this:
// Acquire a reference to the pool (typically from a JNDI
// context provided by the app server, or a servlet context
// attribute)
javax.sql.DataSource ds = ... acquire a reference ...
// Acquire a connection from the pool
javax.sql.Connection conn = ds.getConnection();
// Do your thing with the returned connection
Statement stmt = conn.createStatement("...");
stmt.execute();
// Return the connection to the pool
conn.close();
Note this last -- as far as the application is concerned, they are closing a JDBC
connection, but since the "Connection" was really provided by the pool, the
underlying real connection is *not* closed; it is simply returned to the pool.
Making org.apache.turbine.util.db.pool work like this (i.e. implement
java.sql.Connection) is certainly possible, but breaks the existing contract for
what DBConnection.close() does, among others. If that is OK, you're pretty much
reingineering the whole thing. If not, wrappers are the way to go.
I didn't realize that I also needed to implement the DataSource interface,
now that I do, I will go make it happen.
At that point, will you use it Craig?
I will certainly document it as an available option -- assuming that the changes
were complete, using this connection pool in a Struts app would be as simple as the
following in the app config file:
struts-config
...
data-sources
data-source type="org.apache.turbine.util.db.pool.ConnectionPool"
loginTimeout="30"
driver="org.postgresql.Driver"
maxCount="4"
url="jdbc:postgresql://localhost/mydatabase"
username="myusername"
password="mypassword"
/
/data-sources
...
/struts-config
(assuming a few more property setters on ConnectionPool to set the rest of the
configuration properties).
However, I would not recommend it ... the turbine-pool.jar file drags along ~40
classes of Turbine infrastructure that aren't useful unless you are running inside
Turbine.
Of course, no third part connection pool at all is needed if your app server
provides one for you. And, as long as the server obeys the conventions described in
the servlet and J2EE specs w.r.t. resource-ref entries and the corresponding JNDI
context provided by the server (which is in the near-term plans for Tomcat 4 as
well, with plug-in of any conforming data source), the app doesn't care. It's
portable, instead of locked in to a particular implementation.
I doubt it because you are so head strong in re-inventing everything that
Turbine has done.
I guess my main point here is that I really think it is messed up to simply
say that you won't use something because it doesn't implement some Sun
interface.
The fact of the matter here is that in this case, you NEED an implementation
of a database pool regardless of what interface that it implements. By
saying that you would like to plug other pools into the back end is a
separate issue entirely.
On top of it, it took me all of 30 minutes to implement the majority of the
interfaces in Turbine's pool. You are a better engineer than I (remember,
according to some people, I only write crappy spaghetti code)...so I bet you
could have done it in 15 minutes.
It's actually been quite a few more hours than that writing the wrappers for you so
far. But, if you're going to do it, I won't bother to finish.
p.s. I spent some time reviewing Struts recently and it is absolutely
hilarious how much of it clearly has been "borrowed" from Turbine...all the
way down to the idea of "Actions" for the C portion of MVC. Struts is
clearly Craig's refusal to work with the Turbine project which is clearly
contrary to what he had originally stated when he proposed the project.
Turbine is a fine project, with a good group of developers and a solid base of
functionality. That's not my problem.
I just don't want to work with you (and the
Re: [POLL] Re: Code Sharing Concepts
on 2/15/01 3:24 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: However, I would not recommend it ... the turbine-pool.jar file drags along ~40 classes of Turbine infrastructure that aren't useful unless you are running inside Turbine. What *exactly* is the problem with that? Of course, no third part connection pool at all is needed if your app server provides one for you. And, as long as the server obeys the conventions described in the servlet and J2EE specs w.r.t. resource-ref entries and the corresponding JNDI context provided by the server (which is in the near-term plans for Tomcat 4 as well, with plug-in of any conforming data source), the app doesn't care. It's portable, instead of locked in to a particular implementation. Point being...where is Tomcat going to get its implementation of a connection pool from? Are you going to re-implement Struts pool again? :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Craig R. McClanahan wrote: I just don't want to work with you (and the attitudes you carry) on Turbine. Hmmm. As release manager of Tomcat 4.0, you appear quite willing to ship code that he (and the attitudes that he carries) has committed to that cvs tree. But code that the same person commits to a different cvs tree is somehow not something you want to work with? What will your reaction be if Ted and others are successful in creating a library subproject, and seed it with code of mixed heritage from various subprojects? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: may we please have a interim Jakarta "libary" mailing list for the purpose of formaling the details of a proposal for this subproject. Are you sure that you want to call it that. ;-) Beyond the typo...the name of the mailing list should match the name of the subproject. I'm willing to create the mailing list in anticipation of the project being created, but it like to be sure that the name is what everybody wants. Once that is settled, I'd gladly create a mailing list in anticipation of a subproject being formed, and add any initial subscribers you provide. If an area of the Website were also available, we'd be happy to have that as well ;-) ... looking down the road, you'd put this in the same cvs tree as your source. Meanwhile, you (personally) already have update access to jakarta-site, so I'm not really sure what you are asking for here. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Sam Ruby wrote: Craig R. McClanahan wrote: I just don't want to work with you (and the attitudes you carry) on Turbine. Hmmm. As release manager of Tomcat 4.0, you appear quite willing to ship code that he (and the attitudes that he carries) has committed to that cvs tree. You might want to count the "jakarta-tomcat-4.0" commits from Jon (they fit on one hand :-), but that is not your point. But code that the same person commits to a different cvs tree is somehow not something you want to work with? Primary difference is that Turbine is a project growing out of Jon's dreams and drives. The success he's had building that is a testament to the fact that he's pretty good at community building. But that is not a community that I care to participate in. The stated goals (and, somewhat more importantly, the clear "non-goals") don't scratch my itch for an application framework that plays nice with J2EE APIs. Turbine preceeded the vast majority of these APIs coming into existence, so its no surprise that conforming to them hasn't been a big concern. What will your reaction be if Ted and others are successful in creating a library subproject, and seed it with code of mixed heritage from various subprojects? Not a problem, per my previous vote (assuming the process issues are dealt with on how decisions about code contributions and backwards compatibility are addressed). I don't even care what connection pool implementation(s) are made part of it, as long as it implements interfaces I care about. But that is not the same thing as trying to go tell another project they should change all their APIs to meet *my* needs. To say nothing of the "my way or the highway" attitude that is so prevalent (what happened to competing codebases and "may the best implementation win"?). Personally, I get my satisfaction from open source participation in writing code that people find useful, rather than the somewhat more "political" aspects of community building. I don't have any time for personal diatribes, attacks on my motives, complaints about my employer, or any of the rest of it. You'll have to excuse me now ... I need to go back to work on getting around the *()*() package sealing violations that are affecting any apps that try to use Xerces under WEB-INF/lib in Tomcat 4.0 (including Turbine and Cocoon) ... - Sam Ruby Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: may we please have a interim Jakarta "libary" mailing list for the purpose of formaling the details of a proposal for this subproject. Are you sure that you want to call it that. ;-) Beyond the typo...the name of the mailing list should match the name of the subproject. I'm willing to create the mailing list in anticipation of the project being created, but it like to be sure that the name is what everybody wants. Well, if it's a library - why not calling it "alexandria" - it would be a nice name for that :-) Ops, the name is taken - but maybe we can re-use it - after all alexandria is already a project that is shared by all other projects ( since it contains tools that put togheter everything, etc). Seriously speaking - I am very concerned with the content of the library - I have a feeling that some people would like one book for each subject. I think that would be a very big step backwards. My hope is that the "library" project will be organized in a way that allows multiple "books" in each collection. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Re: Code Sharing Concepts
* DataSource/Database Pool +1 * XML Configuration +1 * Message Resources / i18n +1 * JNDI / Naming * Testing Suites Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: On 2/9/2001 at 8:12 AM Sam Ruby wrote: I would suggest that you start with a proposed code base. Going back over the posts, there seem to be at least five clear areas of overlap: * DataSource/Database Pool +1 * XML Configuration +1 geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
