On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
There was a gentleman agreement that there is no commit from Tobagosto MyFaces, after the toboago incubation was done.That is exactly ***not*** the expected scenario in an Apache TLP. All committers to MyFaces should be able to commit to any
On 9/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Not really.But I need a vote from 2 other pmc member.Can you encourage 2 pmc member to vote for the release.FWIW, this is the kind of thing that motivates a MyFaces committer is a MyFaces committer, as opposed to trying to segregate folks only
Hi, as already announced I now would start to push Dojo into Tomahawk,
probably around friday night.
Following components and Dojo parts would be affected.
The dojo Initializer
The dojo core code and components
The Dojo Utils
The examples for the initializer and generally
how to use Dojo (not the
Hy everyone,
my name is Martin Haimberger and i took part in the GSoC 2006 with the Partial State Saving project for myfaces.
The two mayor things to implement were
a) Create an partial State Saving Tree
b) Render the Tree without calling dispatch() and let the jsp render it
I used the
[
http://issues.apache.org/jira/browse/TOMAHAWK-493?page=comments#action_12434384
]
Guy Coleman commented on TOMAHAWK-493:
--
Could a committer have a look at this issue? It's a simple fix..
detailStamp facet in the last row not
Hi,
Also have in mind that the work on the dojo integration is not finished
in the long run we will have to move dojo as codebase out of tomahawk
into something else, but i first have to know what the Sun guys are up
to, to avoid future conflicts in that area.
how about creating a new jar
Volker Weber schrieb:
aging them into tobago.jars.
I had suggested this before, but it was deferred because of the switch
to maven build and the first maven build relase.
What about creating this new artifact now?
+1 for such a thing... I think dojo and its general code artefacts
are the
Werner,
can you explain the sun guys thing ?
I think I don't get it.
regarding myfaces-commons.jar there was already something like that,
now it's shared.
mmm
On 9/13/06, Werner Punz [EMAIL PROTECTED] wrote:
Volker Weber schrieb:
aging them into tobago.jars.
I had suggested this before,
werner, volker,
what about tomahawk-dojo ?
or myfaces-dojo ?
On 9/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Werner,
can you explain the sun guys thing ?
I think I don't get it.
regarding myfaces-commons.jar there was already something like that,
now it's shared.
mmm
On 9/13/06,
Matthias Wessendorf schrieb:
Werner,
can you explain the sun guys thing ?
I think I don't get it.
It is not official yet, but as it seems the sun guys
are moving towards dojo as well, there are lots of indications.
Which means for future versions of tomahawk and the studio creator
this can
no, the shared is not the suggested commons.
the shared is for shared classes between api/impl and tomahawk and
repackaged at build time.
the suggested commons is for components that are usefull also on other
jsf frameworks.
2006/9/13, Matthias Wessendorf [EMAIL PROTECTED]:
Werner,
can you
It is not official yet, but as it seems the sun guys
are moving towards dojo as well, there are lots of indications.
aha, so we need to follow their way ?
:)
Which means for future versions of tomahawk and the studio creator
this can become problematic,
there are maybe version clashes which i
I don't want a jar for dojo, I suggest a jar for converters,
validators, aliasBeanTag, saveStateTag and other parts of tomahawk.jar
which are complete renderer independent and may also be usefull in jsf
application which don't use tomahawk.
it is e.g. not possible to mix tobago with tomahawk
ah,
since the thread is called dojo, it didn't come through.
something like that might be the best way.
go ahead ;)
On 9/13/06, Volker Weber [EMAIL PROTECTED] wrote:
I don't want a jar for dojo, I suggest a jar for converters,
validators, aliasBeanTag, saveStateTag and other parts of
+1
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
There was a gentleman agreement that there is no commit from Tobagos
to MyFaces, after the toboago incubation was done.
That is exactly ***not*** the expected scenario in an
Thanks Craig for checking that SVN currently creates no gab between
MyFaces and Tobago.
Let's vote on having them official inside our project.
-Matthias
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
There was a gentleman
Matthias Wessendorf schrieb:
It is not official yet, but as it seems the sun guys
are moving towards dojo as well, there are lots of indications.
aha, so we need to follow their way ?
:)
Actually it is more of an issue of trying
to get tomahawk into as many tools as possible in the long
+1 for the release! Although it also concerns me a bit the lack of
knowledge/interest of most of the myfaces committers in tobago,
Cheers!
Bruno
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Not really.
But I need a vote from 2
+1 to get rid of that as well... thanks craig for pointing it out
Matthias Wessendorf schrieb:
+1
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
There was a gentleman agreement that there is no commit from Tobagos
to
[
http://issues.apache.org/jira/browse/TOMAHAWK-667?page=comments#action_12434421
]
eric commented on TOMAHAWK-667:
---
This isn't a problem of library, in my point of view, it's a problem of
configuration.
Maybe the web.xml file, i don't know
[
http://issues.apache.org/jira/browse/TOMAHAWK-494?page=comments#action_12434424
]
Simon Middleton commented on TOMAHAWK-494:
--
Could a committer have a look at this please. The code change provided works
fine.
detailStamp facet is
[
http://issues.apache.org/jira/browse/TOMAHAWK-498?page=comments#action_12434426
]
Simon Middleton commented on TOMAHAWK-498:
--
This fix works. Would a committer care to implement it, please.
detailStamp facet is decoded improperly
Yes, that's true, +1
On 9/13/06, Werner Punz [EMAIL PROTECTED] wrote:
+1 to get rid of that as well... thanks craig for pointing it out
Matthias Wessendorf schrieb:
+1
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Missing Jars for RegExprValidator
-
Key: TOMAHAWK-669
URL: http://issues.apache.org/jira/browse/TOMAHAWK-669
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Validators
Affects Versions:
[
http://issues.apache.org/jira/browse/TOMAHAWK-669?page=comments#action_12434447
]
Wendy Smoak commented on TOMAHAWK-669:
--
When you try to use the validator, where?
Do you mean that the jars are missing from one of the example apps?
It would be good to split a monolithic jar into smaller jars with clear
dependencies. This makes it easy for developers to choose the functionality
based on the needs .
I could think of the breakdown like:
- a jar for dojo
- a jar with shared utility code
- a jar with all validators
- a jar
[
http://issues.apache.org/jira/browse/TOMAHAWK-669?page=comments#action_12434453
]
Brooks Lyrette commented on TOMAHAWK-669:
-
I was programmatically adding validations to controls, so it was in my backing
bean.
Maybe it is not a bug
Ravindar Reddy schrieb:
It would be good to split a monolithic jar into smaller jars with clear
dependencies. This makes it easy for developers to choose the functionality
based on the needs .
I could think of the breakdown like:
- a jar for dojo
- a jar with shared utility code
- a
On 9/13/06, Ravindar Reddy [EMAIL PROTECTED] wrote:
It would be good to split a monolithic jar into smaller jars with clear
dependencies. This makes it easy for developers to choose the functionality
based on the needs .
I could think of the breakdown like:
- a jar for dojo
- a jar with
[Note that I moved the discussion on jar splitting to another thread
-- please use that thread instead of this one]
Werner, I'm for the idea in general, but I'm -1 on doing it before we
make a 1.1.4 Tomahawk branch.
We need to get a matching version of Tomahawk out since the
RI-compatibility
Congratulations, to Martin and Martin.
Dennis Byrne
-Original Message-
From: Martin Haimberger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 04:19 AM
To: dev@myfaces.apache.org
Subject: Outcome of the Google Sommer of Code project Partial State Saving
Hy everyone,
my
Werner,
Maybe the 1.1.4 Tomahawk branching has been done, and I just missed it.
I do see this link:
http://people.apache.org/builds/myfaces/tomahawk-1.1.x/
However, I don't think the MyFaces team has really attempted to
insure that this snapshot is acceptable as a release candidate.
I admit
Cool!
Have all of our Summer Of Code folks filed ICLAs so we can accept
their contributions?
On 9/13/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Congratulations, to Martin and Martin.
Dennis Byrne
-Original Message-
From: Martin Haimberger [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
[ http://issues.apache.org/jira/browse/MYFACES-788?page=all ]
Cyril JOUI updated MYFACES-788:
---
Status: Patch Available (was: Open)
Request attributes lost when using MyFaces in Portlet
-
[
http://issues.apache.org/jira/browse/TOMAHAWK-498?page=comments#action_12434467
]
Mike Kienenberger commented on TOMAHAWK-498:
It will be easier for us to commit this if someone will create a patch, and
attach it as a file to the
[ http://issues.apache.org/jira/browse/MYFACES-788?page=all ]
Mike Kienenberger updated MYFACES-788:
--
Status: Open (was: Patch Available)
Request attributes lost when using MyFaces in Portlet
-
On 9/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
FWIW, this is the kind of thing that motivates a MyFaces committer is a
MyFaces committer, as opposed to trying to segregate folks only interested
in Tobago. On the other hand, the fact that only a small number of folks in
the MyFaces
On 9/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Maybe the 1.1.4 Tomahawk branching has been done, and I just missed it.
I do see this link:
http://people.apache.org/builds/myfaces/tomahawk-1.1.x/
However, I don't think the MyFaces team has really attempted to
insure that this snapshot
[
http://issues.apache.org/jira/browse/TOMAHAWK-493?page=comments#action_12434471
]
Mike Kienenberger commented on TOMAHAWK-493:
Can you submit the fix as a patch, and upload it as a file attachment with the
grant-rights-to-ASF box
Mike Kienenberger schrieb:
On 9/13/06, Ravindar Reddy [EMAIL PROTECTED] wrote:
It would be good to split a monolithic jar into smaller jars with
clear dependencies. This makes it easy for developers to choose the
functionality based on the needs .
I could think of the breakdown like:
- a
On 9/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think this is going too far.
A jar for shared utility code, validators, converters, and
non-rendering components makes sense. Possibly even non-rendering
tags (like t:updateActionListener).
As a facelets user, I could see the
The goal of splitting is two-fold as I see it.
1) Move renderkit-independent resources into a separate jar. These
validators/converters/non-renderers can be used with any JSF
implementation, including those with incompatible renderkit issues
like Tobago and Trinidad.
2) Make a set of common
Wendy Smoak schrieb:
I'm okay with splitting Tomahawk into multiple jars, as long as they
are versioned and released together. Calling one of these jars
'myfaces-components-commons' to indicate that it can be used without
Tomahawk, is also fine.
I'm not in favor of establishing a commons
Wendy Smoak schrieb:
are code between Tomahawk and Tobago, or do we
also want make a commons jar available to users?
As for now the goal is only to share code between Tomahawk and Tobago
(and maybe in the future Trinidad and other libs)
Since as of now nothing visual will come in, I do not see
[ http://issues.apache.org/jira/browse/MYFACES-788?page=all ]
Cyril JOUI updated MYFACES-788:
---
Status: Patch Available (was: Open)
Request attributes lost when using MyFaces in Portlet
-
I was wondering the same thing, why isn't Tobago being merged into
Tomahawk?
-Original Message-
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 8:34 AM
To: MyFaces Development
Subject: Re: [VOTE] Release Apache Tobago 1.0.8
On 9/13/06, Craig
On 9/12/06, Craig McClanahan [EMAIL PROTECTED] wrote:
That is exactly ***not*** the expected scenario in an Apache TLP. All
committers to MyFaces should be able to commit to any of the MyFaces code.
Some TLPs do split the repository -- httpd has a separate
documentation project, and Maven
See this thread:
http://mail-archives.apache.org/mod_mbox/myfaces-users/200604.mbox/[EMAIL
PROTECTED]
On 9/13/06, L Frohman [EMAIL PROTECTED] wrote:
I was wondering the same thing, why isn't Tobago being merged into
Tomahawk?
-Original Message-
From: Mike Kienenberger [mailto:[EMAIL
Datatable renders poorly formatted HTML when dataScroller is used.
--
Key: TOMAHAWK-670
URL: http://issues.apache.org/jira/browse/TOMAHAWK-670
Project: MyFaces Tomahawk
Issue
Wendy Smoak wrote:
On 9/12/06, Craig McClanahan [EMAIL PROTECTED] wrote:
That is exactly ***not*** the expected scenario in an Apache TLP. All
committers to MyFaces should be able to commit to any of the MyFaces
code.
There aren't so many active developers that I think we need to be
Hello,
you can download the tobago examples from
http://people.apache.org/builds/myfaces/nightly/myfaces-tobago-example-1.0.8-SNAPSHOT-bin.tar.gz
the 1.0.8-SNAPSHOT is the next release
Mike Kienenberger wrote:
See this thread:
Team,Might as well throw my 2 cents in here - while more developers would help the cause, the root cause of the conflict lies in the fact that one sub-project moved in a relatively non-aligned manner to the rest. This is what needs to change. I don't think making Tobago a top-level ASF project
On 9/13/06, Zubin Wadia [EMAIL PROTECTED] wrote:
Might as well throw my 2 cents in here - while more developers would help
the cause, the root cause of the conflict lies in the fact that one
sub-project moved in a relatively non-aligned manner to the rest. This is
what needs to change. I don't
Hi,
We just need to assess what it would take to shape Tobago into a seamless
composition within MyFaces. So let's have that dialogue.
i don't understand what you mean with shape Tobago into a seamless
composition within MyFaces .
It looks like here is still the misunderstanding that tobago
[
http://issues.apache.org/jira/browse/MYFACES-1338?page=comments#action_12434530
]
Dave Brondsema commented on MYFACES-1338:
-
Here's a theoretical question: what happens if you want to have a JSF webapp
containing both servlets and
Mike/Volker,I was responding to Bernd feeling like a second-class citizen - that's not true and its not a good feeling to foster. I just want to get this issue out in the open - and sometimes you have to write ambivalently to bring people's feelings into the open. So yay :).
If PMC members are
Testing this now.
One thing I noticed:
http://people.apache.org/builds/myfaces/nightly/myfaces-tobago-1.0.8-SNAPSHOT-bin.zip
has both menuRadio.html and menuradio.html in the same directory.
This doesn't work on case-insensitive filesystems like windows. The
two files appear to have different
+1 for release if the case-insensitve filesystem issue is resolved...On 9/12/06, Bernd Bohmann [EMAIL PROTECTED]
wrote:Not really.But I need a vote from 2 other pmc member.Can you encourage 2 pmc member to vote for the release.
RegardsBerndMatthias Wessendorf wrote: too late ? +1 ... sorry for
It looks like here is still the misunderstanding that tobago and
tomahawk will merge, sonner or later. This will imo never the case.
Tomahawk and Tobago are completely different products based on the
same technology.
Yeah, I agree. The more I think about it the more I see a Tomahawk/Tobago
This is not realy a issue, the files are part of the autogenerated tlddoc.
the radiomenu.html is the description of the deprecated tc:radiomenu
tag which was renamed to tc:radioMenu.
the attributes are the same, if you compare these two pages in a
browser the only diffrence are the line:
Actually I agree with wendy here...
a shared build and release should be mandatory,
otherwise it will be versioning hell.
The parts i like to see in the commons are mainly Validators,
Converters and other renderkid independent stuff with stable api.
I see no reason to release tomahawk just to
Thanks for your vote,
but I can't resolve the case-insensitive filesystem issue until a mayor
release of Tobago.
I think this is only a documentation issue and the documentation is
generated by a maven-plugin. The only fast solution would be to delete
the documentation from the distribution
Consider the condition removed. Binding +1.On 9/13/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Thanks for your vote,but I can't resolve the case-insensitive filesystem issue until a mayor
release of Tobago.I think this is only a documentation issue and the documentation isgenerated by a
On 9/13/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
but I can't resolve the case-insensitive filesystem issue until a mayor
release of Tobago.
I think this is only a documentation issue and the documentation is
generated by a maven-plugin. The only fast solution would be to delete
the
On 8/29/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
I am willing to do any help to support porlets in myfaces.
also can some body please, put an article on wiki telling us (newly joined
developers) where to get latest sources which we should work on? (I am
confused which trunk is latest
Hi all,
I'm creating a popup in a myfaces tree2 dynamically using _javascript_ and creating Dom elements.
I have built the popup div complete with children. I believe the way i
get myfaces to recognize this popup is by passing it in the _javascript_
constructor like so:
var popup = new
Is this intended to be a Java 1.5-only release for examples?
I get this error when trying to run the examples under java 1.4.2.
java.lang.UnsupportedClassVersionError:
org/apache/myfaces/tobago/webapp/TobagoServletContextListener
(Unsupported major.minor version 49.0)
On 9/13/06, Bernd
Tree2 fails with NumberFormat Exception or Null Pointer Exception when
ExpandAll button is placed in the same form as Tree2 using RI
Key:
+1 from me for a release of Tobago.
In any case - are there any new efforts to make Tobago more compatible
to the rest of the JSF world?
We've all put a bit of effort into compatibility in tomahawk and impl,
and I'd like to see some effort in the tobago code base as well...
regards,
Martin
69 matches
Mail list logo