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
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
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
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
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
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
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
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
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
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
:-)
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
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
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
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
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
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:
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
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.
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!
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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,
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
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
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
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
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
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
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
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?
---
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
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
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
:-)
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
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,
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
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
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
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
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
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
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
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
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 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
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
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
70 matches
Mail list logo
