[Jakarta Wiki] Update of ApacheAtJavaOne2005 by JulesGosnell
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 JulesGosnell: http://wiki.apache.org/jakarta/ApacheAtJavaOne2005 -- * == project confirmed time. Please make sure each slot has two || Date || 11am-1pm || 1pm-3pm || 3pm-5pm || 5pm-7pm || - || 6/27 || Geronimo/Tomcat || Harmony/Struts|| Xalan/Jakarta || Jakarta/Ant || + || 6/27 || Geronimo*/Tomcat || Harmony/Struts|| Xalan/Jakarta || Jakarta/Ant || || 6/28 || Portals*/WS || HTTPD/Geronimo || MyFaces*/Harmony || WS/Maven || || 6/29 || Ant/Portals* || Maven/Ant || Struts/HTTPD || Tomcat/Xalan || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Tapestry 4.0-beta-1
The first beta release of Tapestry 4.0 is now available. Tapestry is a component based web application framework that provides lots of functionality with minimal Java coding, and creates an environment that supports high levels of reuse. Tapestry 4.0 represents a significant advance over Tapestry 3.0. A few of our favorite changes in 4.0: * The new 4.0 specification DTDs have been simplified. * The syntax used for binding parameters inside an HTML template and inside an XML specification is now consistent. Both make use of the binding prefixes. * Friendly URLs (that is, URLs that pack more information into the path and less into query parameters) are built in. This makes it easy to divide your application across many folders (reducing clutter), and leverage J2EE declarative security along the way. * Listener methods are much easier and more flexible; listener parameters in the URL are automatically mapped to listener method parameters, and listener methods can return the page name or page instance to activate. * Component parameters now just work, without having to worry about direction. * Applications can now have a global message catalog, in addition to per-page and per-component message catalogs. Messages not found in the component message catalog are searched for in the application catalog. * Full, native support for developing JSR-168 Portlets has been added. * Tapestry 4.0 makes much less use of reflection and OGNL than Tapestry 3.0; partly because there are many new binding prefixes and largely because of how parameters are now implemented. * HiveMind services and Spring beans to be directly injected into page and component classes. * Tapestry 4.0 includes optional JDK 1.5 annotation support (but Tapestry still works with JDK 1.3). * Tapestry 4.0 debuts a new and much more sophisticated user input validation subsystem. Thanks Paul! * Line precise error reporting can now display the contents of files containing errors. * Forms can now be canceled, bypassing client-side validation logic, and invoking an alternate listener on the server-side. * You are no longer limited to just Global and Visit; you can have as many application state objects as you like. * The use of HiveMind under the covers means that Tapestry can be easily customized to fit your needs. * Page properties can now be persisted on the client, as well as in the session. * Components and component parameters can now be marked as deprecated. Component parameters may have aliases (used when renaming a parameter). The complete list of changes is almost too numerous to enumerate. Suffice to say, everything is about getting more bang for the buck; reducing the amount of Java code, reducing the complexity of templates, and simplifying (or eliminating) XML files. Tapestry is distributed as a combined binary/source distribution, and a seperate documentation distribution. Download Tapestry from http://jakarta.apache.org/site/downloads/downloads_tapestry.cgi -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by StephenColebourne
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 StephenColebourne: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Change CVS to SVN -- (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. + The subproject will host a SVN repository available to all Apache committers as a workplace for new packages or other projects. (2) identify the initial set of committers @@ -57, +57 @@ * As stated in the Jakarta guidelines, an action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes. 1. It is expected that the scope of packages may sometimes overlap. 1. Anyone may propose a new package to the Commons, and list themselves as the initial committers for the package. The vote on the proposal is then also a vote to enter new committers to the subproject as needed. -1. A CVS repository will be available to all Apache committers as a workplace for new packages or other projects. Before release to the public, code or documentation developed here must be sponsored by Jakarta subproject. The sponsoring subproject(s) will distribute the code or documentation along with the rest of their codebase. +1. A SVN repository will be available to all Apache committers as a workplace for new packages or other projects. Before release to the public, code or documentation developed here must be sponsored by Jakarta subproject. The sponsoring subproject(s) will distribute the code or documentation along with the rest of their codebase. 1. Each Commons component should use an internally consistent and documented coding style. When the source code for a component originates in a pre-existing code base outside of Commons, the coding style of that code base may be retained at the discretion of the initial committers. If a component does not specify its coding style, the Sun Coding Convention guidelines are assumed. 1. The subproject catalog will also list packages and resources available to the public related to other Jakarta subprojects and ASF projects. 1. As a Jakarta subproject, the Commons adopts all other guidelines and procedures of Jakarta and the Apache Software Foundation, as they may be amended from time to time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Rahul Akolkar wrote: is boils down to the question: does this subproject need it's own sandbox or will neophyte components start in the jakarta commons sandbox? +1 for sandbox (non-binding) Its slightly hard to imagine anything otherwise, but maybe I'm just used to seeing how commons and taglibs work. If Taglibs join, we have a bunch of Taglibs in sandbox, they will need to be housed somewhere, and I don't see them migrating to commons sandbox ;-) Right? Yes, +1 to a sandbox. Although it can create issues, I think has more benefits than downsides. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
robert burrell donkin wrote: this has proved impractical in the jakarta commons. i propose we drop point 12. 12. 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. --8--- [X] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- One jar didn't work for commons, no reason to expect it will here. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Tapestry 4.0-beta-1
Howard Lewis Ship wrote: Tapestry is distributed as a combined binary/source distribution, and a seperate documentation distribution. What is required to build this? Am I correct in assuming the process is like Tapestry 3.0, with non ASF libs being fetched by an ant script? If so, what really is the procedure for getting this beta working? Thanks, Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
robert burrell donkin wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases is 9 needed? are any configuration guidelines needed? if they are then i agree that they should encourage specification compliance. would a general statement about specification compliance be better? Its not needed. The charter should be as simple as possible. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of CreatingCommonsForWebComponents by StephenColebourne
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 StephenColebourne: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents The comment on the change is: Add a couple more suggestions on subprojects -- * Session, Request and Response utilities * Servlets * Taglibs + * Browser recognition + * File upload These would be compact libraries coupled only with their environment and not to any particular web application development framework. Small, tightly focussed components with minimal dependencies would be favoured. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Stephen Colebourne wrote: robert burrell donkin wrote: On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote: 9 or somewhere else should speak to J2EE or other external config requirments, which should be fine, even encouraged in some cases is 9 needed? are any configuration guidelines needed? if they are then i agree that they should encourage specification compliance. would a general statement about specification compliance be better? Its not needed. The charter should be as simple as possible. +1 -- after thinking about it some more, I don't think it is wise to limit things or to reference J2EE or other specs in the charter. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of CreatingCommonsForWebComponents by StephenColebourne
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 StephenColebourne: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents The comment on the change is: Add Web Commons -- * Web App Components * Web App Modules * Web Bricks + * Web Commons * Web Components * Web Parts * Web Tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of CreatingCommonsForWebComponents by StephenColebourne
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 StephenColebourne: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents The comment on the change is: Add Web Libs -- * Web Bricks * Web Commons * Web Components + * Web Libs * Web Parts * Web Tools * Weblets - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Name for commons-like area for web
There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. We do need to decide this though. Only then can mailing list discussion move off jakarta general and coding get started. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. As long as it is not under the umbrella of the Jakarta Commons project I would avaoid the term Commons. I think I like WebLibs the best. cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: Name for commons-like area for web
I like Components the best (Jakarta Web Components). Apparently so does Sun (e.g. SCWCD). To me, Parts sounds like what I need when my car breaks down. And brick reminds me of a funny insult that was going around the net for a while: http://forums.modemhelp.net/viewtopic.php?t=4161 -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List general@jakarta.apache.org Sent: Saturday, June 25, 2005 2:22 PM Subject: Name for commons-like area for web There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. We do need to decide this though. Only then can mailing list discussion move off jakarta general and coding get started. Stephen - 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: Name for commons-like area for web
Hi! Web Commons Web Components For me it depends how fine grained those components are. Say, if there is a project which cummulates all filters for a servlet container I am for web commons as it might result in project sizes we have in commons. If we manage (what I prefer) to have much much smaller parts say a filter component to handle access control based on the ip address with hosts allow/deny rules or another simple component to have commons-validator available as tags for jsf (yes I know there is shale) I am for web components. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
On 6/25/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Web Commons Web Components For me it depends how fine grained those components are. Say, if there is a project which cummulates all filters for a servlet container I am for web commons as it might result in project sizes we have in commons. If we manage (what I prefer) to have much much smaller parts say a filter component to handle access control based on the ip address with hosts allow/deny rules or another simple component to have commons-validator available as tags for jsf (yes I know there is shale) I am for web components. I am +1 for web components too ... but just wanted to note that the integration between JSF and Commons Validator in Shale is usable even if you don't buy in to the rest of the Shale architecture -- it doens't have any dependencies on the core Shale framework. That kind of independence is one of my goals for the Tiles integration in Shale as well. Except for the configuration interface (which is hooked in to the configuration of Shale overall, but is easily separable), the same is also true for the Dialogs part of Shale ... it has no runtime dependencies on the Shale framework classes, only on the portable JSF APIs. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of Migrating to Subversion by TimObrien
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 TimObrien: http://wiki.apache.org/jakarta/Migrating_to_Subversion -- * JMeter- Nudge sent. * POI - Nudged. Is OS X support good enough? amongst other questions. * Slide - Stefan Lützkendorf. Migration applied for. - * Taglibs - Tim O'Brien. Martin Cooper. Renudged. + * Taglibs - Tim O'Brien. Martin Cooper. [http://brahe.discursive.com/svn/taglibs/ Test Repo] [http://brahe.discursive.com/taglibs-convert.tgz scripts.tgz(200k)] * Tapestry - Nudged. Is [http://sublicpse.tigris.org/ Subclipse] good enough? * Turbine - Henning Schmiedehausen, Daniel Rall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of CreatingCommonsForWebComponents by TimObrien
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 TimObrien: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents The comment on the change is: Silly name ideas -- * Web Parts * Web Tools * Weblets + * Web Artifacts +* League +* Confederation +* Bloc - The Web Bloc + * What about something less definite and more code word? What about not having the word web? Arctic or Telsa or something completely meaningless but catchier than Web .*$ + This will probably need to be settled on the list. WebCommonsNameRequestForComments (create as needed). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
Stephen Colebourne wrote: There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. I like WebLibs the best. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Name for commons-like area for web
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: 26 June 2005 02:16 To: Jakarta General List Subject: Re: Name for commons-like area for web Stephen Colebourne wrote: There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. I like WebLibs the best. Phil ... Nah. That's an anagram of 'Wibbles', and it might upset the company that makes those fashionable toys that are all about friendship, if they ever worked it out ... Rgds Deano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
On 6/25/05, Dean Pickersgill [EMAIL PROTECTED] wrote: -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] snip/ I like WebLibs the best. Phil ... Nah. That's an anagram of 'Wibbles', and it might upset the company that makes those fashionable toys that are all about friendship, if they ever worked it out ... I can see how this thread might last a while ;-) Personally, I'm (also) +1 (non-binding) for web components. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for commons-like area for web
I found this comment interesting: What about something less definite and more 'code word'? What about not having the word 'web'? 'Arctic' or 'Telsa' or something completely meaningless but catchier than 'Web .*$ I think if a proper name is choosen along these lines, the result is something better than the relatively pedestrian names currently being bandied about (not that any of them are especially bad, just a little, bland). How about something like Webementals, fusing Web and Elementals (signifying pieces that combine to form a larger whole)? I think a code word-type name is more interesting and meorable (once a person knows what its all about), but it should still have some connection to what the project is all about. The argument against of course is that you won't know at a glance what its all about. I think something clever enough can overcome this and still be a bit more exciting. Just my opinion (who else' would it be?!?) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Sat, June 25, 2005 2:22 pm, Stephen Colebourne said: There doesn't seem to be a thread for this The current suggestions are: Commons Web Jakarta Web Parts for Java (JWP4J) Web App Commons Web App Components Web App Modules Web Bricks Web Commons Web Components Web Libs Web Parts Web Tools Weblets Of these, WebParts has issues with Microsoft, so I would suggest we avoid it. Weblets was also used by IBM back in 2000, so could have issues. The most obvious would be CommonsWeb or WebCommons, as the general user community could link the concept to commons easily enough. However, there is a danger that it could be confusing precisely because of that. Thus, my current top three are: - WebLibs - WebCommons - WebBricks but I can still be persuaded. We do need to decide this though. Only then can mailing list discussion move off jakarta general and coding get started. Stephen - 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: Name for commons-like area for web
Hi Craig! but just wanted to note that the integration between JSF and Commons Validator in Shale is usable even if you don't buy in to the rest of the Shale architecture Yes, I know - I already use it that way (or better, I started to use it ;-). However, even if shale-core is small, if we go the Web Components direction I think even the shale-core (if it were integrated into web components) needs to be broken into more pieces. And yes, I would prefer it. I think this is an important point. Even a project like (the great) Shale might be too big to be a web component. This stuff can be reflected on the homepage by multiple projects where we have a set of committers like we have now, but this project has to release web components. Even if this project always releases all its web components at once (and thus all their jar files do have the same version number) it is possible for the user to pick its web component. The project is free to also provide a web component bundle. This should avoid somethink like we see often with commons-collections which has been grown in a way where other projects decide to copy the one Collection class needet out of it and drop the rest. On every new release this has to be done again. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
