[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Dropped 8 as per POLL -- 1. The packages should fit within a unified package hierarchy. 1. In general, packages should provide an interface and one or more implementations of that interface, or implement another interface already in use. * The packages should have boring functional names. Implementations may choose more 'exciting' designations. -1. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. +1. '''DELETED''' ''Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper.'' 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. 1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Changed to reflect consensus about mailing lists -- 1. The package library is not a framework but a collection of components designed to be used independently. 1. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts. 1. Each package is treated as a product in its own right. - 1. Each package has its own status file, release schedule, version number, QA tests, documentation, mailing list, bug category, and individual JAR. + 1. Each package has its own status file, release schedule, version number, QA tests, documentation, '''DELETED''' ''mailing list,'' bug category, and individual JAR. 2. Each package must clearly specify any external dependencies, including any other Commons packages, and the earliest JDK version required. 1. External dependencies on optional and third-party codebases should be minimized. 2. All necessary dependencies must be recorded in the MANIFEST.MF file of the package JAR, in the manner recommended in the JDK 1.3 documentation describing 'system extensions' @@ -49, +49 @@ 1. '''DELETED''' ''Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper.'' 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. -1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. +1. '''DELETED''' ''The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages.'' '''ADDED''' The subproject will provide two mailing lists: one for users and the other for developers. Posters should prefix the subject with the name of the component to allow easy filtering. 1. '''DELETED''' ''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.'' 1. Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite. 1. Each committer has karma to all the packages, but committers are required to add their name to a package's status file before their first commit to that package. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
Henri Yandell wrote: are there any committers involved with JSTL around? Sorry, I raised the question then entered in JavaOne-sleep-mode :( if not, would anyone like to volunteer to sound them out about a move to subproject status? I vote for Standard being a separate Jakarta sub-project. I've mentioned the idea on the taglibs-dev mailing list, no reply as yet. There hasn't being too many messages by the committers lately, specially on votes. So, tomorrow (I'm too tired now :-) I will send a big message summarizing all of these pending votes and hopefully we will get enough committer answers now... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Deleted point 12 -- 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. 1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. -1. 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. +1. '''DELETED''' ''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.'' 1. Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite. 1. Each committer has karma to all the packages, but committers are required to add their name to a package's status file before their first commit to that package. 1. New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, the coding conventions used for the package (if different from the Sun coding conventions), and the initial set of committers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
On Thu, 2005-06-23 at 20:14 -0400, Henri Yandell wrote: On Thu, 23 Jun 2005, robert burrell donkin wrote: On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? My vote is for the active Taglibs to roll into the web component subproject, but for the Standard/JSTL taglib to move to Jakarta subproject status. Taglibs-user is dominated by JSTL questions and the JSTL committers don't have any obvious overlap with the other taglib committers (that I've noticed). Also in terms of codebase, Standard is the relative behemoth. Lastly it has a much higher profile than other parts of web-component-subproject will have and as a spec implementation it has a different set of issues to deal with. +1 are there any committers involved with JSTL around? if not, would anyone like to volunteer to sound them out about a move to subproject status? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
On 6/26/05, robert burrell donkin [EMAIL PROTECTED] wrote: are there any committers involved with JSTL around? if not, would anyone like to volunteer to sound them out about a move to subproject status? I've mentioned the idea on the taglibs-dev mailing list, no reply as yet. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) I'd like to suggest 2 things: 1.We prefereably use Maven for the builds, as it helps a lot handling the dependencies (if we stick to Ant, we should at least use Ivy or M2 Ant stuff for dependency management). For instance, I haven't applied some patches to the Jakarta Taglibs because my computers are not set for building them anymore (and I don't have the time/patience to fix it). jakarta commons is agnostic (but uses maven for the website). i'd recommend official agnosticism with unofficial encouragement to maven. it is a good idea to provide ant scripts generated by maven in SVN. 2.Regarding the Jakarta Taglibs, we should create the new taglibs from scratch. I mean, of course we should reuse the code, but we better do some refactoring first (for instance, eliminating redundant taglibs, defining a role for TLD names, etc...) - the current Jakarta Taglibs would then be frozen in time. IMHO it would probably be more convenient to maintain these frozen taglibs (from an official perspective) within the new subproject. with subversion, it's really nice and easy to have cool directory structures... 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 00:52 -0300, Felipe Leme wrote: Felipe Leme wrote: I'd like to suggest 2 things: ... 3 Damn, beaten by the ENTER key again :-( shades of monty python's flying circus ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
robert burrell donkin wrote: if the new subproject is anything like the commons then each component will have it's own development rhythm. I think this is a cogent point... if the idea is that this is like a Commons project, than I have to ask the question: why not just have a few new Commons projects, as was my original proposal? I originally started by suggesting a Commons Filters, because I had some filters I wanted to contribute. So far I think we've brainstormed something like 4-6 sort of sub-packages of this... If they are going to develop to their own rhythm as you say, then why not make each a Commons project, where there already largely is the infrastructure (in the larger sense) build up? That would seem to me the path of least (or at least lower) resistance, and maybe even a more appropriate fit. It's a question of what the vision is of course... if everyone is thinking along the commons lines anyway, why not just do it in Commons? Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 2005-06-23 at 17:55 -0400, Frank W. Zammetti wrote: robert burrell donkin wrote: if the new subproject is anything like the commons then each component will have it's own development rhythm. I think this is a cogent point... if the idea is that this is like a Commons project, than I have to ask the question: why not just have a few new Commons projects, as was my original proposal? The relevant questions are: * what percentage of the existing commons developers are interested in working on web components * what percentage of the prospective web developers are interested in participating in other commons projects * what percentage of users and interested in both web and normal commons projects. If the answer to any of these is high then the benefits of a combined community outweigh the nuisance of excessive emails, overly-large subproject lists and general distraction. I would guess the critical threshold to be about 25% - but I don't think that will be reached, ie I believe that less than 25% of existing commons committers would be interested in web commons components of the sort proposed. Therefore having such components in the existing commons will just annoy people without having any significant benefits (other than allowing this startup hassle for web commons to be skipped). Already we have people (both developers and users) agitating for separate per-component mail lists due to the volume of emails in commons. Some people have stated that they refuse to subscribe or be part of the community while there is a shared list. I would hate to see separate lists, but they have a point - there is an upper limit to the amount of mail people can handle (esp. people on dial-up connections; filtering by mail subject doesn't reduce the bandwidth needed to download all the mails). There is also the issue of community size. Commons has a couple of dozen regular committers, which means we all recognise each other's names. That's quite important I think, and brings some sense of team membership. Diluting this with another dozen developers (I hope web commons will grow to that size!) may change that sense of community (esp. if we don't have many interests in common). And likewise for new web commons committers - I think the sense of a team will be stronger with a separate project/mail-list etc. I admit it's all guesswork and a little crystal-ball-gazing. If web-commons is a failure, ie only a couple of projects get off the ground, then the existing commons would be a better home. But I hope that's not the case - there does seem to be a reasonable number of ideas and people willing to push them forward. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
On Thu, 23 Jun 2005, robert burrell donkin wrote: On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote: Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). if the new subproject is anything like the commons then each component will have it's own development rhythm. it might be easier to raise extra hands when needed for these efforts if these share the same infrastructure (mailing lists, subproject organization and so on). opinions? My vote is for the active Taglibs to roll into the web component subproject, but for the Standard/JSTL taglib to move to Jakarta subproject status. Taglibs-user is dominated by JSTL questions and the JSTL committers don't have any obvious overlap with the other taglib committers (that I've noticed). Also in terms of codebase, Standard is the relative behemoth. Lastly it has a much higher profile than other parts of web-component-subproject will have and as a spec implementation it has a different set of issues to deal with. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Initial draft based on Jakarta Commons charter New page: = Draft Charter For Web Component Commons = == About This Page == This is a space for easy development of the charter. Since the web components commons is intended to function in the same way that Jakarta Commons does, the initial version will be the current Jakarta Commons charter. Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. == Draft Charter == (0) rationale Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major deliverable. The Java language however is package-based, and most of these products have many useful utilities. Some products are beginning to break these out so that they can be used independently. A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product. To further this goal, the subproject shall also host a workplace for Jakarta committers. (1.1) the sandbox The subproject will host a CVS repository available to all Apache committers as a workplace for new packages or other projects. (2) identify the initial set of committers '''PLEASE LEAVE EMPTY''' == Draft Guidelines == Note : * is, has, will, shall, must - required. * may, should, are encouraged - optional but recommended. 1. The primary unit of reuse and release is the package. 1. The package library is not a framework but a collection of components designed to be used independently. 1. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts. 1. Each package is treated as a product in its own right. 1. Each package has its own status file, release schedule, version number, QA tests, documentation, mailing list, bug category, and individual JAR. 2. Each package must clearly specify any external dependencies, including any other Commons packages, and the earliest JDK version required. 1. External dependencies on optional and third-party codebases should be minimized. 2. All necessary dependencies must be recorded in the MANIFEST.MF file of the package JAR, in the manner recommended in the JDK 1.3 documentation describing 'system extensions' 3. Each package must maintain a list of its active committers in its status file. 1. The packages should use a standard scheme for versioning, QA tests, and directory layouts, and a common format for documentation and Ant build files. 1. The packages should fit within a unified package hierarchy. 1. In general, packages should provide an interface and one or more implementations of that interface, or implement another interface already in use. * The packages should have boring functional names. Implementations may choose more 'exciting' designations. 1. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. 1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. 1. 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. 1. Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite. 1. Each committer has karma to all the packages, but committers are required to add their name to a package's status file before their first commit to that package. 1. New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Apache Wiki wrote: Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments or post to [http://jakarta.apache.org/site/mail.html General At Jakarta]. OK, here I am posting :-) I'd like to suggest 2 things: 1.We prefereably use Maven for the builds, as it helps a lot handling the dependencies (if we stick to Ant, we should at least use Ivy or M2 Ant stuff for dependency management). For instance, I haven't applied some patches to the Jakarta Taglibs because my computers are not set for building them anymore (and I don't have the time/patience to fix it). 2.Regarding the Jakarta Taglibs, we should create the new taglibs from scratch. I mean, of course we should reuse the code, but we better do some refactoring first (for instance, eliminating redundant taglibs, defining a role for TLD names, etc...) - the current Jakarta Taglibs would then be frozen in time. 3.What about the Standard Taglibs? Should it be part of this new project or should it be a separate project. The reasoning here is that, because that sub-project provide the codebase for JSTL's implementation (and maybe other JSR taglibs in the future as well, such as the Web Services taglib), its development activities/cycles might be different from the non-standard ones (we could even try to apply the TCK on such projects in the future, for instance). -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Felipe Leme wrote: I'd like to suggest 2 things: ... 3 Damn, beaten by the ENTER key again :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
