Re: [result][vote] start up the MyFaces Commons project
To lessen confusion, would someone want to start a wiki page with a summary of what the commons would look like. That way the emails should be (hopefully) easier to read. Then this thread can be used to refine and discuss the wiki contents. -Andrew On Nov 30, 2007 12:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Mario Ivankovits [EMAIL PROTECTED] schrieb: I don't see any reason why we shoulnd't being able to provide a stable api even for shared. I have to strongly disagree here. I know what all this means, but, this statement, and what Manfred wrote means, that MyFaces is not allowed to depend on jsfcommons and is not allowed to use all the nice utility methods in there. I still think it should be possible to provide a library with a stable api over time, new methods can be added without breaking backward compatibility. See commons-lang. IF JSF changes in a way that makes this no longer possible, we could create a new package structure for the new API. Something like org.apache.myfaces.jsfcommons - org.apache.myfaces.jsfcommons2 etc. Dropping such a jar into the J2EE Container does not necessarily break anything. BTW: I think all this J2EE stuff with providing implementations is broken, at least, it shows a major caveat in Java where a library is not able to define on which other library-version it depends on. A shame that this has not been fixed for a long time ... Something like this is planned in Java 1.7 I think, no? In any case, I think having a subject-separated project structure in jsfcommons is better than the api/impl way. However, if we split tomahawk into pieces and providing a jsfcommons for just the utils thing I am fine too. Yep, maybe this is the way how tomahawk should evolve and it frees jsfcommons from the discussion if converters/validators should be put in there - the answer then is simply NO, put it into tomahawk-converters. In the sense of equality we should find an all new name for this project which has nothing to do with commons, tomahawk, trinidad etc. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
let me try to get the wiki page done tomorrow.
(at least the starting point)
On Dec 3, 2007 8:48 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
To lessen confusion, would someone want to start a wiki page with a
summary of what the commons would look like. That way the emails
should be (hopefully) easier to read. Then this thread can be used to
refine and discuss the wiki contents.
-Andrew
On Nov 30, 2007 12:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Mario Ivankovits [EMAIL PROTECTED] schrieb:
I don't see any reason why we shoulnd't being able to provide a stable
api even for shared.
I have to strongly disagree here.
I know what all this means, but, this statement, and what Manfred wrote
means, that MyFaces is not allowed to depend on jsfcommons and is not
allowed to use all the nice utility methods in there.
I still think it should be possible to provide a library with a stable
api over time, new methods can be added without breaking backward
compatibility. See commons-lang.
IF JSF changes in a way that makes this no longer possible, we could
create a new package structure for the new API.
Something like org.apache.myfaces.jsfcommons -
org.apache.myfaces.jsfcommons2 etc.
Dropping such a jar into the J2EE Container does not necessarily break
anything.
BTW: I think all this J2EE stuff with providing implementations is
broken, at least, it shows a major caveat in Java where a library is not
able to define on which other library-version it depends on. A shame
that this has not been fixed for a long time ... Something like this is
planned in Java 1.7 I think, no?
In any case, I think having a subject-separated project structure in
jsfcommons is better than the api/impl way. However, if we split
tomahawk into pieces and providing a jsfcommons for just the utils thing
I am fine too. Yep, maybe this is the way how tomahawk should evolve and
it frees jsfcommons from the discussion if converters/validators should
be put in there - the answer then is simply NO, put it into
tomahawk-converters. In the sense of equality we should find an all
new name for this project which has nothing to do with commons,
tomahawk, trinidad etc.
Ciao,
Mario
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
I don't think a separation between api and impl jars is useful. Myfaces core has broken code I've been working on many times. And the issue there is not a change in the api (the JSF api is clearly static). Instead the problem has been changes in behaviour. So a stable API jar only solves about 20% of the stability problem. But it doubles the number of jars a user has to manage. Doesn't seem to me like the inconvenience is work it. Instead, having a decent test suite to check for application stability is better; that can test both API and behaviourable stability. Possibly having non-public classes in a separate package within the jar (eg org.myfaces.jsfcommons.impl.*) would be worthwile. At release time, then a simple check of the commits to the api packages would be sufficient to double-check api stability. Regards, Simon Manfred Geiler [EMAIL PROTECTED] schrieb: yes, fine! please consider the following structure: myfaces-jsfcommons | myfaces-jsfcommons-api | myfaces-jsfcommons-impl | myfaces-jsfcommons-sandbox (we must avoid the name myfaces-commons for there was once a project with that name - see maven repo!) api = the classes and interfaces, that users will directly use (ie. import) in their code (= compile scope dependency) impl = internal implementation classes, users will need during runtime only (= runtime scope dependency) furthermore: - api classes and interfaces must not change between two bugfix releases (eg. from 1.0.0 to 1.0.1) - api classes and interfaces might vary (be extended) between two minor releases (eg. from 1.0.3 to 1.1.0) - BUT only backwards compatible! - api classes and interfaces might be totally different between two major releases (eg. from 1.5.3 to 2.0.0) - BUT need not ;-) - impl classes (and interfaces) can be changed, added, removed, refactored whenever needed This is no unnecessary effort IMHO. jsfcommons can only be successful and widely accepted if users can confide in a stable API that is not subject to change on every single release. In a community driven project this is only possible with some rules. And systematically separating API from Impl classes in different JARs make these rules very simple and intuitive. --Manfred On Nov 28, 2007 10:41 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, it is that case, that Bernd I and meet next weekend. If you guys don't mind, we start the commons project, as discussed here. Like maven-stuff etc. -Matthias On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ?
Re: [result][vote] start up the MyFaces Commons project
Six additional lines for the user (as long as he/she uses maven ;-) is not that much more additional inconvenience I think: dependency groupIdmyfaces-jsfcommons/groupId artifactIdmyfaces-jsfcommons-impl/artifactId version1.0.0/version scoperuntime/scope /dependency But I see your point and if I'm the only one who prefers separate jars, I'm ok with only separating them by different package namespace. However, the idea is a really stable API. That is crucial. If you think we can manage it with one jar I'm ok with that. --Manfred On 11/29/07, Simon Kitching [EMAIL PROTECTED] wrote: I don't think a separation between api and impl jars is useful. Myfaces core has broken code I've been working on many times. And the issue there is not a change in the api (the JSF api is clearly static). Instead the problem has been changes in behaviour. So a stable API jar only solves about 20% of the stability problem. But it doubles the number of jars a user has to manage. Doesn't seem to me like the inconvenience is work it. Instead, having a decent test suite to check for application stability is better; that can test both API and behaviourable stability. Possibly having non-public classes in a separate package within the jar (eg org.myfaces.jsfcommons.impl.*) would be worthwile. At release time, then a simple check of the commits to the api packages would be sufficient to double-check api stability. Regards, Simon Manfred Geiler [EMAIL PROTECTED] schrieb: yes, fine! please consider the following structure: myfaces-jsfcommons | myfaces-jsfcommons-api | myfaces-jsfcommons-impl | myfaces-jsfcommons-sandbox (we must avoid the name myfaces-commons for there was once a project with that name - see maven repo!) api = the classes and interfaces, that users will directly use (ie. import) in their code (= compile scope dependency) impl = internal implementation classes, users will need during runtime only (= runtime scope dependency) furthermore: - api classes and interfaces must not change between two bugfix releases (eg. from 1.0.0 to 1.0.1) - api classes and interfaces might vary (be extended) between two minor releases (eg. from 1.0.3 to 1.1.0) - BUT only backwards compatible! - api classes and interfaces might be totally different between two major releases (eg. from 1.5.3 to 2.0.0) - BUT need not ;-) - impl classes (and interfaces) can be changed, added, removed, refactored whenever needed This is no unnecessary effort IMHO. jsfcommons can only be successful and widely accepted if users can confide in a stable API that is not subject to change on every single release. In a community driven project this is only possible with some rules. And systematically separating API from Impl classes in different JARs make these rules very simple and intuitive. --Manfred On Nov 28, 2007 10:41 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, it is that case, that Bernd I and meet next weekend. If you guys don't mind, we start the commons project, as discussed here. Like maven-stuff etc. -Matthias On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
On Nov 29, 2007 9:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... this is something, that I like more; Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). well, when we put in the converters/validators, we will also have faces-cfg for them... Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. -1 Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. +1 no sandbox inside the master project. For Trinidad Sandbox, I am planing to create it at the same level, where projects like tomahawk, trinidad or portlet-bridge are -M Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hi! well, when we put in the converters/validators, we will also have faces-cfg for them... Yep, if we have separate projects we can have the faces-config.xml again. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. +1 no sandbox inside the master project. Just to clarify, this means a -1 to my suggestion above, no? For Trinidad Sandbox, I am planing to create it at the same level, where projects like tomahawk, trinidad or portlet-bridge are Hmm and this again means to be a +1 to my suggestion ... I am confused now ;-) If you create it at the project level (which I proposed), why not simply move the tomahawk-sandbox up? Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Oh no! Seems like we are going round in circles... :-( WHAT is the FOCUS of a jsfcommons project?! Do we really want component like stuff like converters and validators there? Didn't we discuss this already? I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi Manfred! Oh no! Seems like we are going round in circles... :-( Seems like. A mail (31.10.2007 21:59) from you And don't forget about all those (renderkit-independent!) converters and validators. People might argue for putting them into a jsfcommons components artifact. What about the Joda converter that Matthias suggested? What is the reason it should go into Trinidad? It is not renderkit-specific or somehow related to Trinidad. So, a perfect candidate for jsfcommons-components, right? (There would even be place for a separate jsfcommons-converters artifacts, IMHO) Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Having projects like jsfcommons-utils and jsfcommons-components were suggested by you. But true, I lost the focus now :-( I really thought that stuff like NavigationHandler (not configured) would go into the jsfcommons too. Seems like I am wrong. Sorry! Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
I'd love to see things like: http://svn.apache.org/viewvc/myfaces/tobago/trunk/core/src/main/java/org/apache/myfaces/tobago/servlet/NonFacesRequestServlet.java?view=markup in a util. (oh boy, it all starts again) -M On Nov 29, 2007 10:25 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Manfred! Oh no! Seems like we are going round in circles... :-( Seems like. A mail (31.10.2007 21:59) from you And don't forget about all those (renderkit-independent!) converters and validators. People might argue for putting them into a jsfcommons components artifact. What about the Joda converter that Matthias suggested? What is the reason it should go into Trinidad? It is not renderkit-specific or somehow related to Trinidad. So, a perfect candidate for jsfcommons-components, right? (There would even be place for a separate jsfcommons-converters artifacts, IMHO) Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Having projects like jsfcommons-utils and jsfcommons-components were suggested by you. But true, I lost the focus now :-( I really thought that stuff like NavigationHandler (not configured) would go into the jsfcommons too. Seems like I am wrong. Sorry! Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
:-) currently (which is wrong) /tom /tom/sandbox it should: /tom /tom-sandbox On Nov 29, 2007 10:04 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! well, when we put in the converters/validators, we will also have faces-cfg for them... Yep, if we have separate projects we can have the faces-config.xml again. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. +1 no sandbox inside the master project. Just to clarify, this means a -1 to my suggestion above, no? For Trinidad Sandbox, I am planing to create it at the same level, where projects like tomahawk, trinidad or portlet-bridge are Hmm and this again means to be a +1 to my suggestion ... I am confused now ;-) If you create it at the project level (which I proposed), why not simply move the tomahawk-sandbox up? Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
On Nov 29, 2007 10:07 AM, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Seems like we are going round in circles... :-( WHAT is the FOCUS of a jsfcommons project?! Do we really want component like stuff like converters and validators there? hu? yes! Didn't we discuss this already? I thought we agreed on not starting yet another jsf component lib. converters/validators are renderKit independent, so why not having them there ? What is wrong with having convenient converters and validators in tomahawk? Where they are right now! I am fine with having them in tomahawk as a convenient solution (technically the TLD point to the TAG, defined in the lib) Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) that would be more a utlis; What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hi! If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Oh ... how much I'd love this to happen Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. that would easy the debugging as well. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hi, 2007/11/29, Manfred Geiler [EMAIL PROTECTED]: Oh no! Seems like we are going round in circles... :-( WHAT is the FOCUS of a jsfcommons project?! Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. An i think this one was meant by Matthias and Bernd. If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hmpf Last time the discussion ended with some open issues. I think it's all about naming. That's the main reason for different views and opinions I think. To gain a common view on things I try to subsume without giving names first. The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. It IS. You have to know at which class to set a breakpoint. Even if you see a shared class, you have to set the breakpoint to the refactored shared_tomahawk, shared_impl, etc. Depending on which lib you are going to debug. Currently this also requires you to know which version you are going to debug as e.g. Tomahawk uses the shared from the 1.1 trunk while the 1.2 trunk has its own shared. I already spent a significat amount of time during debugging until I figured out that fact. Also, if you change something in shared you have to run maven ... you know why ;-) I don't see any reason why we shoulnd't being able to provide a stable api even for shared. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? +1 to these categories Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? no names yet :-) See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) no names yet :-) -M An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
yes, yes, of course - sorry. I should read more carefully. I thought Matthias meant that it's easier to debug if you do not have splittet jars - API and Impl. One of the other 7 discussions we are having concurrently within this thread, you know. ;-) Debugging shared IS horror today, sure! Agreed! easy means minimum of the horror. I don't see any reason why we shoulnd't being able to provide a stable api even for shared. Thing is: One beneficiary of shared (and not the least important!) is the myfaces-impl, which is a candidate to be provided by J2EE containers. Therefore we MUST ensure that ALL classes that form the actual jsf implementation reside in a private namespace. This is the only way to avoid unwanted sideeffects when users deploy their apps together with other beneficiaries of shared (Tomahawk, ...) Please note: this is no unusual case. Some containers use re-packaged XML-Parsers to avoid unwanted sideeffects when a user deploys an app together with a newer (or older) Xerces. Even Sun Java runtime is shipped with a re-packaged Xalan. right, /com/sun/foo/org/apache/ is there, always. So, no real way around? (perhaps not for -impl?) --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. It IS. You have to know at which class to set a breakpoint. Even if you see a shared class, you have to set the breakpoint to the refactored shared_tomahawk, shared_impl, etc. Depending on which lib you are going to debug. yes, yes, of course - sorry. I should read more carefully. I thought Matthias meant that it's easier to debug if you do not have splittet jars - API and Impl. One of the other 7 discussions we are having concurrently within this thread, you know. ;-) Debugging shared IS horror today, sure! Agreed! Currently this also requires you to know which version you are going to debug as e.g. Tomahawk uses the shared from the 1.1 trunk while the 1.2 trunk has its own shared. I already spent a significat amount of time during debugging until I figured out that fact. Also, if you change something in shared you have to run maven ... you know why ;-) :-) I don't see any reason why we shoulnd't being able to provide a stable api even for shared. Thing is: One beneficiary of shared (and not the least important!) is the myfaces-impl, which is a candidate to be provided by J2EE containers. Therefore we MUST ensure that ALL classes that form the actual jsf implementation reside in a private namespace. This is the only way to avoid unwanted sideeffects when users deploy their apps together with other beneficiaries of shared (Tomahawk, ...) Please note: this is no unusual case. Some containers use re-packaged XML-Parsers to avoid unwanted sideeffects when a user deploys an app together with a newer (or older) Xerces. Even Sun Java runtime is shipped with a re-packaged Xalan. --Manfred
Re: [result][vote] start up the MyFaces Commons project
Hi, just my few ideas about this ;) What about reversing the flow by answering the 'simple question': What code is specific to render kit? By answering this question we can really begin discussion about the way of putting remaining classes to so called 'commons'. - My current view of 'commons' contents: From start we should agree only that we have only 1 starting base dependancy - JSF API (not impl!) and even that with restriction - not components in .html package. As of today, almost all components from libraries by their tight coupling with tags are disqualified for getting into 'commons'. The main reason for my thinking is not using any generic means of manipulating arbitrary attributes. IMO whole path of JSF components implementation (either RI of MF) diverted from 1st vision of using Map of attributes (see _ComponentAttributesMap class) WITHOUT using getter/setter specific to the attribute in the component's code. If implementation was based solely on using Map, some components WOULD make it to 'commons' if: 1. they had NO dependency on anything beside JSF API (base components, NOT html ones) and classes in 'commons' 2. they declared crucial attributes from Map they work with to be functional (in the simpliest form) Not to mention that adding new attributes would be almost painless - just matter of adding them to tags (which would NOT be in 'commons') and tweaking renderrers (also NOT in 'commons'). Tag related stuff should be seen as outlaws for 'commons', because they depend on render kits - when i hear (or read :D ) word TAG i'm immediatly thinking of CONCRETE language. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from components (see above) and NOT specific tag attributes from ANY language. Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and
Re: [result][vote] start up the MyFaces Commons project
sure, no dependency to -impl. Wouldn't make sense, if there were. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from (server-side) converters and (server-side) validators, are really reusable components, so they need to be in that *commons* thing. components (see above) and NOT specific tag attributes from ANY language. not sure, what this means. Does it mean, that such a commons.jar (not a final name!) doesn't (or shouldn't contain) tags ? (for JSP / Facelets) I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) If a user of commons.jar needs to create TAGs or facelets.xml file, the user would be a very! poor guy. Would make they kind of useless, IMO. -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only for technical reasons. --Manfred On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure
Re: [result][vote] start up the MyFaces Commons project
Hi, Matthias Wessendorf napsal(a): sure, no dependency to -impl. Wouldn't make sense, if there were. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from (server-side) converters and (server-side) validators, are really reusable components, so they need to be in that *commons* thing. That was only note from me - not using converters/validators coupled with render kit's outcome language (like escaping special characters). components (see above) and NOT specific tag attributes from ANY language. not sure, what this means. Does it mean, that such a commons.jar (not a final name!) doesn't (or shouldn't contain) tags ? (for JSP / Facelets) I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) There are NO tags in JSF API (they are ALL in impl), so they don't have a foundation to be built upon. If a user of commons.jar needs to create TAGs or facelets.xml file, the user would be a very! poor guy. Would make they kind of useless, IMO. These files (tags, descriptors) should go to project where components are to be useful at all. Zdenek -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in jsfcommons in former discussed. It was not only
Re: [result][vote] start up the MyFaces Commons project
Hi, the tags for converters/validators e.g. must be in here, or the components are not useable. Regards, Volker 2007/11/29, Sochor Zdeněk [EMAIL PROTECTED]: Hi, Matthias Wessendorf napsal(a): sure, no dependency to -impl. Wouldn't make sense, if there were. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from (server-side) converters and (server-side) validators, are really reusable components, so they need to be in that *commons* thing. That was only note from me - not using converters/validators coupled with render kit's outcome language (like escaping special characters). components (see above) and NOT specific tag attributes from ANY language. not sure, what this means. Does it mean, that such a commons.jar (not a final name!) doesn't (or shouldn't contain) tags ? (for JSP / Facelets) I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) There are NO tags in JSF API (they are ALL in impl), so they don't have a foundation to be built upon. If a user of commons.jar needs to create TAGs or facelets.xml file, the user would be a very! poor guy. Would make they kind of useless, IMO. These files (tags, descriptors) should go to project where components are to be useful at all. Zdenek -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a
Re: [result][vote] start up the MyFaces Commons project
I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) There are NO tags in JSF API (they are ALL in impl), so they don't have a foundation to be built upon. ... These files (tags, descriptors) should go to project where components are to be useful at all. Sure, there are no concrete tags in JSF-API, but from a user's perspective, I would expect, that a commons.jar (which contains converter/validator) has this: -tags for JSP (since the JSF spec requires the support of JSP) and Facelets (if the lib is nice) -faces-config.xml, containing these converter's / validator. If not, that lib would be a bit to abstract; Like when Tomahawk (and/or Trinidad/Tobago) will *reship* those validators, they build the tags (JSP/Faclets/what_ever). That work is done three-times. But... for some reason, the user has to use JSF-lib NameItWhatEverYouWant, but want's these COOL extra validator/converter classes. He needs to provide tags/cfg on his own, which is odd. Sure... the other component-lib, could implement them... but... well... I'd not buy such a poor solution; It should be more convenient for users, that just want these extra bits that would be to much, IMO Zdenek -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for component developers - convenient backing(!) bean utils and helpers for jsf application developers (ie users) What jsfcommons should NOT be: - a convenient haven for simple components or component like stuff, that is put there for strategic reasons A need for a jsfcommons-faces-config.xml is a definite sign, that we would start off in the wrong direction. We would start yet another jsf component lib. That is the main reason I warned of having a faces-config.xml in
Re: [result][vote] start up the MyFaces Commons project
Exactly, that would be a poor man's API :-) I'd not buy such a lib -M On Nov 29, 2007 4:22 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi, the tags for converters/validators e.g. must be in here, or the components are not useable. Regards, Volker 2007/11/29, Sochor Zdeněk [EMAIL PROTECTED]: Hi, Matthias Wessendorf napsal(a): sure, no dependency to -impl. Wouldn't make sense, if there were. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from (server-side) converters and (server-side) validators, are really reusable components, so they need to be in that *commons* thing. That was only note from me - not using converters/validators coupled with render kit's outcome language (like escaping special characters). components (see above) and NOT specific tag attributes from ANY language. not sure, what this means. Does it mean, that such a commons.jar (not a final name!) doesn't (or shouldn't contain) tags ? (for JSP / Facelets) I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) There are NO tags in JSF API (they are ALL in impl), so they don't have a foundation to be built upon. If a user of commons.jar needs to create TAGs or facelets.xml file, the user would be a very! poor guy. Would make they kind of useless, IMO. These files (tags, descriptors) should go to project where components are to be useful at all. Zdenek -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original idea of a jsfcommons project is/was: - convenient utils, helpers and base classes for
Re: [result][vote] start up the MyFaces Commons project
Hi, the tags for converters/validators e.g. must be in here, or the components are not useable. I should have made myself little clearer - i was speaking of components, not converters/validators. I was ONLY speaking here about converters/validators. API (containing the validators/converters) AND! and IMPL (containing the TAGs) *might* be a solution, but IMO that is a little bit overhead. -Matthias Regards, Volker 2007/11/29, Sochor Zdeněk [EMAIL PROTECTED]: Hi, Matthias Wessendorf napsal(a): sure, no dependency to -impl. Wouldn't make sense, if there were. Convertors and validators are quite different matter - they should get into 'commons' BUT if and only if they use only crucial attributes from (server-side) converters and (server-side) validators, are really reusable components, so they need to be in that *commons* thing. That was only note from me - not using converters/validators coupled with render kit's outcome language (like escaping special characters). components (see above) and NOT specific tag attributes from ANY language. not sure, what this means. Does it mean, that such a commons.jar (not a final name!) doesn't (or shouldn't contain) tags ? (for JSP / Facelets) I think it should contain tags for: -jsp (that guy is default in JSF spec) -facelets (that guy is more and more used) There are NO tags in JSF API (they are ALL in impl), so they don't have a foundation to be built upon. If a user of commons.jar needs to create TAGs or facelets.xml file, the user would be a very! poor guy. Would make they kind of useless, IMO. These files (tags, descriptors) should go to project where components are to be useful at all. Zdenek -Matthias Utility classes - only small potion of them are really without any references to render kit (either direct or indirect through components). Having convenient classes for working in either backing beans and/or developing new components in 'commons' would be ...convenient. :D With regards, Zdenek Matthias Wessendorf napsal(a): The stuff we have (or plan to have) and we need places for are: 1. renderkit independent stuff - converters, validators, ... (BTW, are they really renderkit independent? What about client-side validation?!) let me write a wiki page for that + discussion in a separate thread. -M 2. convenient utils, helpers and base classes for component developers 3. convenient backing(!) bean utils and helpers for jsf application developers (ie users) 4. some things in myfaces-shared that should not be there (BTW, I have concrete plans on refactoring shared, but first I need a place where I can move some stuff to) 5. ??? Let's try to agree on these different categories. After that we try to find the proper place and name(!) for each item? Okay? See inline as well -- -- Manfred On 11/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Yes we had discuss this, but it seems we did not reach agreement. I think we need a own project for converters/validators/other stuff for application-development which should not include renderkid/jsf-impl dependend stuff. +1 that was my real motivation for creating a commons. I really don't care on a coolBackingBean. Utils might be the better wording for that. Aren't commons modules as we know it all utilities in some sense? ;-) An i think this one was meant by Matthias and Bernd. I think so :-) If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Yes, that's what I want to try. But shared is no proper name for stuff that could be used by independent component developers. The name shared means: this is internal code *shared* by some MyFaces subprojects. Therefore we need a better place: jsfcommons-??? that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. Perhaps we need stricter rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. (Just my thoughts) Regards, Volker I thought we agreed on not starting yet another jsf component lib. What is wrong with having convenient converters and validators in tomahawk? Where they are right now! Is it because tomahawk has some flaws and maybe have sideeffects on other component libs? If yes, we have to FIX tomahawk and not turn around and start a new (better?) project. My original
Re: [result][vote] start up the MyFaces Commons project
Hi! Mario Ivankovits [EMAIL PROTECTED] schrieb: I don't see any reason why we shoulnd't being able to provide a stable api even for shared. I have to strongly disagree here. I know what all this means, but, this statement, and what Manfred wrote means, that MyFaces is not allowed to depend on jsfcommons and is not allowed to use all the nice utility methods in there. I still think it should be possible to provide a library with a stable api over time, new methods can be added without breaking backward compatibility. See commons-lang. IF JSF changes in a way that makes this no longer possible, we could create a new package structure for the new API. Something like org.apache.myfaces.jsfcommons - org.apache.myfaces.jsfcommons2 etc. Dropping such a jar into the J2EE Container does not necessarily break anything. BTW: I think all this J2EE stuff with providing implementations is broken, at least, it shows a major caveat in Java where a library is not able to define on which other library-version it depends on. A shame that this has not been fixed for a long time ... Something like this is planned in Java 1.7 I think, no? In any case, I think having a subject-separated project structure in jsfcommons is better than the api/impl way. However, if we split tomahawk into pieces and providing a jsfcommons for just the utils thing I am fine too. Yep, maybe this is the way how tomahawk should evolve and it frees jsfcommons from the discussion if converters/validators should be put in there - the answer then is simply NO, put it into tomahawk-converters. In the sense of equality we should find an all new name for this project which has nothing to do with commons, tomahawk, trinidad etc. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi, it is that case, that Bernd I and meet next weekend. If you guys don't mind, we start the commons project, as discussed here. Like maven-stuff etc. -Matthias On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
yes, fine! please consider the following structure: myfaces-jsfcommons | myfaces-jsfcommons-api | myfaces-jsfcommons-impl | myfaces-jsfcommons-sandbox (we must avoid the name myfaces-commons for there was once a project with that name - see maven repo!) api = the classes and interfaces, that users will directly use (ie. import) in their code (= compile scope dependency) impl = internal implementation classes, users will need during runtime only (= runtime scope dependency) furthermore: - api classes and interfaces must not change between two bugfix releases (eg. from 1.0.0 to 1.0.1) - api classes and interfaces might vary (be extended) between two minor releases (eg. from 1.0.3 to 1.1.0) - BUT only backwards compatible! - api classes and interfaces might be totally different between two major releases (eg. from 1.5.3 to 2.0.0) - BUT need not ;-) - impl classes (and interfaces) can be changed, added, removed, refactored whenever needed This is no unnecessary effort IMHO. jsfcommons can only be successful and widely accepted if users can confide in a stable API that is not subject to change on every single release. In a community driven project this is only possible with some rules. And systematically separating API from Impl classes in different JARs make these rules very simple and intuitive. --Manfred On Nov 28, 2007 10:41 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, it is that case, that Bernd I and meet next weekend. If you guys don't mind, we start the commons project, as discussed here. Like maven-stuff etc. -Matthias On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
Yes, I hope I can spend some time at the end of the week. I will setup the initial maven dirs and stuff. I will also add the sandbox we spoke about. So, hopefully, next week we will have some space that wants to get filled with cool Java lines... --Manfred On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
Grins I give up :) as far as I am concerned call it that (booring!!! :) ) Ron On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
Well, I think there's probably enough difference between the two goals that we do need to separate projects, even though it contributes to the Yet Another MyFaces Subproject quagmire. At least it's a step in the right direction since we're looking at merging common code rather than futher separation. Let's leave the components - api dependency out until such time that it's explicitly needed. On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Name for MyFaces Common Project was Re: [result][vote] start up the MyFaces Commons project
I like Manfred Geiler idea around MyFaces JSF Commons. Paul Spencer Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
Hi! I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components I think this makes stuff again too complicated to be maintained in the future. You have two additional projects/modules, with maybe separate release cycles - and even if not, you have to release them both at the same time. Documentation and site is splitted, pom work is required to do twice, etc My preference is to stick with just one MyFaces JSF Commons project - artifactIdmyfaces-jsfcommons/artifactId Ciao, Mario
Need summary of intent and contend to each MyFaces JSF Commons subproject was (Re: [result][vote] start up the MyFaces Commons project)
Please summarize the intent and proposed contents of each subproject on a wiki page. A common refactoring page already exists [1]. The resulting pages should be moved in each project's site documentation Paul Spencer [1] http://wiki.apache.org/myfaces/MyFaces_Commons_Refactoring Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Need summary of intent and contend to each MyFaces JSF Commons subproject was (Re: [result][vote] start up the MyFaces Commons project)
Please summarize the intent and proposed contents of each subproject on a wiki page. A common refactoring page already exists [1]. The resulting pages should be moved in each project's site documentation Paul Spencer [1] http://wiki.apache.org/myfaces/MyFaces_Commons_Refactoring Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components I think this makes stuff again too complicated to be maintained in the future. You have two additional projects/modules, with maybe separate release cycles - and even if not, you have to release them both at the same time. Documentation and site is splitted, pom work is required to do twice, etc We do not necessarily need separate release cycles. At least at the beginning. They would have a common parent pom of course. So, once set up, there is not really additional effort during development or releasing. I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? --Manfred
Re: [result][vote] start up the MyFaces Commons project
Hi, i don't understand what should go into the utils and what into the components parts. I think we can mix static utils with renderkid independent components in one library. for renderkid dependend compeonents we have already tomahawk, tobago and trinidad. Regards, Volker 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
We're discussing two completely different concepts here. One is an api for writing new components. For component developers. One is a library of common renderkit-independent components for use in JSF applications. For application developers. Attempting to combine them is going to shortchange one side or the other. Either the library is going to end up with dependencies on renderkit-specific stuff, or the api is going to be severely limited in what it provides. On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: Hi, i don't understand what should go into the utils and what into the components parts. I think we can mix static utils with renderkid independent components in one library. for renderkid dependend compeonents we have already tomahawk, tobago and trinidad. Regards, Volker 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
Hi! which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a component-library without (the dreaded) shared. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? Yes, sure. And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a component-library without (the dreaded) shared. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Also renderkit independent components need a taglib in the META-INF dir. This is the main difference between a component and a goodie class a user can decide to use or not. --Manfred
Re: [result][vote] start up the MyFaces Commons project
The point is: For myfaces-jsfcommons-components we must provide additional stuff in the jar. You know: taglib, faces-config.xml, ... This is what we do NOT want in the myfaces-jsfcommons-utils jars to - keep it simple, and - avoid unwanted side-effects Please mind: Not yet sure, but the myfaces-jsfcommons-utils might propably become a jar that myfaces-core-impl depends on in the future. So, we should really keep all real components out of it. Which on the same time does not forbid convenient Renderer utils in myfaces-jsfcommons-utils of course. --Manfred On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: Hi, i don't understand what should go into the utils and what into the components parts. I think we can mix static utils with renderkid independent components in one library. for renderkid dependend compeonents we have already tomahawk, tobago and trinidad. Regards, Volker 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Re: [result][vote] start up the MyFaces Commons project
What is the problem having a taglib in the jar? 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? Yes, sure. And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a component-library without (the dreaded) shared. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Also renderkit independent components need a taglib in the META-INF dir. This is the main difference between a component and a goodie class a user can decide to use or not. --Manfred
Re: [result][vote] start up the MyFaces Commons project
To avoid this I'd NOT include eg viewhandler or navigation handler in the jar. Taglib wont harm if not used. Instead we just document how to setup. Mario -Original Message- From: Manfred Geiler [EMAIL PROTECTED] Date: Wednesday, Okt 31, 2007 4:53 pm Subject: Re: [result][vote] start up the MyFaces Commons project To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! which is itself an 'umbrella' project for two artifacts** called 'MyFaces JSF Commons Utils' and 'MyFaces JSF Commons Components' I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? Yes, sure. And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a 'component-library without (the dreaded) shared'. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Also renderkit independent 'components' need a taglib in the META-INF dir. This is the main difference between a 'component' and a goodie class a user can decide to use or not. --Manfred
Re: [result][vote] start up the MyFaces Commons project
A taglib and a faces-config in the META-INF are loaded/registered automatically. And as I already mentioned, it should be possible to use the commons utils from the core impl. Automatically loading extensions(!) is not what we want when using the myfaces core implementation. There is some stuff in shared that makes sense to be moved to commons utils. So this is not only theoretical. And don't forget about all those (renderkit-independent!) converters and validators. People might argue for putting them into a jsfcommons components artifact. What about the Joda converter that Matthias suggested? What is the reason it should go into Trinidad? It is not renderkit-specific or somehow related to Trinidad. So, a perfect candidate for jsfcommons-components, right? (There would even be place for a separate jsfcommons-converters artifacts, IMHO) BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. The Apache Commons Proper consists of 35 different Components and nobody cares. Quite the contrary, everybody is glad there is not only one bloated commons.jar when he/she needs just commons-logging or some of the DbUtils, right? --Manfred On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: What is the problem having a taglib in the jar? 2007/10/31, Manfred Geiler [EMAIL PROTECTED]: On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? Yes, sure. And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a component-library without (the dreaded) shared. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Also renderkit independent components need a taglib in the META-INF dir. This is the main difference between a component and a goodie class a user can decide to use or not. --Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [result][vote] start up the MyFaces Commons project
Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
Why not Apache Caribbean? Since it's most likely going to be composed of features taken from Trinidad and Tobago it would fit quite well (probably would probably get quite a lot of additional search engine hits :P ) ~ Simon On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [result][vote] start up the MyFaces Commons project
Pretty hard to discuss for non-Americans, I can't speak for Manfred, but I accepted the discussions, said OK and moved forward. -M On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
:-) On 10/30/07, Simon Lessard [EMAIL PROTECTED] wrote: Why not Apache Caribbean? Since it's most likely going to be composed of features taken from Trinidad and Tobago it would fit quite well (probably would probably get quite a lot of additional search engine hits :P ) ~ Simon On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hi! I am not sure why we can't call it simply MyFaces Commons? I think the name is pretty fine. But to put something additional into the fire: MyFaces Essentials, or, to move on with islands, MyFaces Papeete Ciao, Mario Pretty hard to discuss for non-Americans, I can't speak for Manfred, but I accepted the discussions, said OK and moved forward. -M On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [result][vote] start up the MyFaces Commons project
It was already set, isn't it ??? On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I am not sure why we can't call it simply MyFaces Commons? I think the name is pretty fine. But to put something additional into the fire: MyFaces Essentials, or, to move on with islands, MyFaces Papeete Ciao, Mario Pretty hard to discuss for non-Americans, I can't speak for Manfred, but I accepted the discussions, said OK and moved forward. -M On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [result][vote] start up the MyFaces Commons project
Hmm I don't know. I think we cannot really use MyFaces Commons for 2 reasons: 1. When I hear Commons I can only think of Jakarta; 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. ~ Simon On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I am not sure why we can't call it simply MyFaces Commons? I think the name is pretty fine. But to put something additional into the fire: MyFaces Essentials, or, to move on with islands, MyFaces Papeete Ciao, Mario Pretty hard to discuss for non-Americans, I can't speak for Manfred, but I accepted the discussions, said OK and moved forward. -M On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [result][vote] start up the MyFaces Commons project
On 10/30/07, Simon Lessard [EMAIL PROTECTED] wrote: Why not Apache Caribbean? And risk offending the Atlantic sea snail ? I would think not !! -- Grant Smith
Re: [result][vote] start up the MyFaces Commons project
Hi! 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. I have no plans to ever move TLP with anything I do here in MyFaces land, I feel very comfortable under the MyFaces umbrella and I also do not understand (yet) why we should leave. MyFaces = [EMAIL PROTECTED] - IMHO that should be the direction. Maybe we have to split the ML later on, but that is another story. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Yeah, and I don't know what's going to happen with the RCF project, guess it's up to the community to decide, but I don't see why it needs to be a subproject of Trinidad so much as a subproject of MyFaces with a dependency on Trinidad. :) Most all of it's dependencies are on API packages in Trinidad and I imagine that any impl dependencies would have to be resolved anyway. Scott Mario Ivankovits wrote: Hi! 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. I have no plans to ever move TLP with anything I do here in MyFaces land, I feel very comfortable under the MyFaces umbrella and I also do not understand (yet) why we should leave. MyFaces = [EMAIL PROTECTED] - IMHO that should be the direction. Maybe we have to split the ML later on, but that is another story. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Yep, KIFS - Keep It Flat and Simple. For the same reason we should not put the Facelets project under tomahawk - even though it may have tomahawk in its name. With the projects names Manfred proposed this is easily possible. Ciao, Mario Scott O'Bryan schrieb: Yeah, and I don't know what's going to happen with the RCF project, guess it's up to the community to decide, but I don't see why it needs to be a subproject of Trinidad so much as a subproject of MyFaces with a dependency on Trinidad. :) Most all of it's dependencies are on API packages in Trinidad and I imagine that any impl dependencies would have to be resolved anyway. Scott Mario Ivankovits wrote: Hi! 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. I have no plans to ever move TLP with anything I do here in MyFaces land, I feel very comfortable under the MyFaces umbrella and I also do not understand (yet) why we should leave. MyFaces = [EMAIL PROTECTED] - IMHO that should be the direction. Maybe we have to split the ML later on, but that is another story. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
[result][vote] start up the MyFaces Commons project
Hi! The result of the vote is: +1 Mike Kienenberger Martin Marinschek Matthias Wessendorf Volker Weber Gary VanMatre Grant Smith Cagaty Civici Paul Spencer Scott O'Bryan Ernst Fastl alvaro tovar (even if he don't know why ;-) ) Manfred Geiler Bernd Bohmann Ron Smits I've abstaind from splitting binding and non binding votes as everyone can see that this vote passed with amazing attendance. Seems like there is some maven work waiting now :-) Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! I agree that MyFaces Basics is too MyFaces-Core-esque.Tomahawk Basics or JSF Basics would be better choices. Hmmm ... I think the MyFaces JSF Basics is the only option then. As far as I know the token MyFaces needs to be in there as it is a project of the MyFaces project. Personally I think the token tomahawk suggest that the Basic module is meant as something related to tomahawk only then. Also we should clearly state in the future that the term MyFaces does not not necessarily mean a module works only with the MyFaces JSF implementation nor with tomahawk only. But I think this is something we already do as good as we can, e.g. with Apache MyFaces Trinidad, Apache MyFaces Orchestra. Btw, Tobago is an exception here, they call their project just Tobago instead of Apache MyFaces Tobago as it should be ... I think. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
I don't think there's any hard rule that all projects have to be prefixed with MyFaces. But then, I also don't have any problem with it being associated with Tomahawk or MyFaces (in the name). On 10/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I agree that MyFaces Basics is too MyFaces-Core-esque.Tomahawk Basics or JSF Basics would be better choices. Hmmm ... I think the MyFaces JSF Basics is the only option then. As far as I know the token MyFaces needs to be in there as it is a project of the MyFaces project. Personally I think the token tomahawk suggest that the Basic module is meant as something related to tomahawk only then. Also we should clearly state in the future that the term MyFaces does not not necessarily mean a module works only with the MyFaces JSF implementation nor with tomahawk only. But I think this is something we already do as good as we can, e.g. with Apache MyFaces Trinidad, Apache MyFaces Orchestra. Btw, Tobago is an exception here, they call their project just Tobago instead of Apache MyFaces Tobago as it should be ... I think. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? -A On 10/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I don't think there's any hard rule that all projects have to be prefixed with MyFaces. But then, I also don't have any problem with it being associated with Tomahawk or MyFaces (in the name). On 10/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I agree that MyFaces Basics is too MyFaces-Core-esque.Tomahawk Basics or JSF Basics would be better choices. Hmmm ... I think the MyFaces JSF Basics is the only option then. As far as I know the token MyFaces needs to be in there as it is a project of the MyFaces project. Personally I think the token tomahawk suggest that the Basic module is meant as something related to tomahawk only then. Also we should clearly state in the future that the term MyFaces does not not necessarily mean a module works only with the MyFaces JSF implementation nor with tomahawk only. But I think this is something we already do as good as we can, e.g. with Apache MyFaces Trinidad, Apache MyFaces Orchestra. Btw, Tobago is an exception here, they call their project just Tobago instead of Apache MyFaces Tobago as it should be ... I think. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario
