+0
~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1
Simon, is http://myfaces.apache.org/javadoc.html an official page?
Google search says that there is no external link to that page.
Should we get rid of it or is there a quick way to fix this?
Thanks,
Manfred
-- Forwarded message --
From: [EMAIL PROTECTED]
Date: Feb 20, 2008
+1
--Manfred
On Feb 19, 2008 11:49 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Over the next few days I'm going to be moving in my changes to support
multiple bridges. As a fist step, I need to move the current trunk at
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/trunk to
Hi
On Feb 20, 2008 10:39 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Simon, is http://myfaces.apache.org/javadoc.html an official page?
Google search says that there is no external link to that page.
it was... and we talked about that already in this thread ([1]).
This page was also linked to
[
https://issues.apache.org/jira/browse/TRINIDAD-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570641#action_12570641
]
Matthias Weßendorf commented on TRINIDAD-922:
-
hey andrew,
I like your
[
https://issues.apache.org/jira/browse/TRINIDAD-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-944:
Resolution: Fixed
Assignee: Matthias Weßendorf (was: Catalin Kormos)
Hi,
The thread that Matthias refers to is about something a bit different.
I only knew that the tagdoc was linked (from the page in question).
-M
There should be no javadoc.html page at the top level of the site, as
this just does not make sense with the large number of myfaces projects
Hi Manfred,
No, that page
http://myfaces.apache.org/javadoc.html
is just a leftover. It should not exist, and can be deleted. The maven
website deploy stuff doesn't delete old obsolete stuff when a new site
is deployed. I guess google indexed it when it was once valid, and now
people are
[
https://issues.apache.org/jira/browse/TOBAGO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570651#action_12570651
]
Helmut Swaczinna commented on TOBAGO-325:
-
I can't see any problems with partial
Deleting it seems not so easy. There is still some update cron job
running with user schof. Right?
This are the properties of the file in /www/myfaces.apache.org
85847169 8 -rw-rw-r-- 1 schof myfaces 7397 Feb 17 21:34 javadoc.html
So it seems that it gets updated/copied on a regular
Perhaps there is a process running on the myfaces.zones.apache.org
machine that is syncing from the continuum server output dir to
people.apache.org. Note that the site is *not* being automatically built
by continuum, but maybe the sync is still running anyway.
I had problems for a while with the
[
https://issues.apache.org/jira/browse/TRINIDAD-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570677#action_12570677
]
Andy Schwartz commented on TRINIDAD-922:
Gang -
While I like the idea of
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+artifactIdportlet-bridge-api/artifactId
+version1.0.0-alpha/version
+scopeprovided/scope
+ /dependency
I wonder fi is the right scope.
Pretty much all containers don't really ship
hi,
checking:
http://www.apache.org/jcp/
it doesn't mention that we develop a RI and the asf representative for that jsr.
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2
-M
On Feb 20, 2008 3:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
dependency
+groupIdorg.apache.myfaces.portlet-bridge/groupId
+
[
https://issues.apache.org/jira/browse/TOBAGO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570717#action_12570717
]
Zied Hamdi commented on TOBAGO-509:
---
The bug doesn't happen under firefox 2.0 (but
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind
[
https://issues.apache.org/jira/browse/TOBAGO-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570723#action_12570723
]
Volker Weber commented on TOBAGO-509:
-
Can you test this with a non png image?
If its
Hello,
actually, I'm using Trinidad with a non JSR-301 bridge (even though it
requires some workarounds ..). Isn't it possible to make this bugfix
optional, for example by introducing a Jsr301StateManagerImpl?
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
There is no compatibility for Trinidad with non JSR-301 bridges.
Scott
Bernhard Huemer wrote:
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED]
We can, but it's a lot of overkill. My concern going forward, however,
is that Trinidad is going to be expected to work with the standard as it
emerges and us trying to pay run with non-standard bridges will limit
our ability to support the standard ones.
That said, I suppose I can put some
Moving this thread out of the bug and into the mailing list to avoid
an endless comment thread on the bug.
Here is the bug for ppl just joining this thread:
https://issues.apache.org/jira/browse/TRINIDAD-922
This is in reply to Andy's comment on the bug.
Andy, you definitely have a good point
Correction, this dependency is a compile only library, not a runtime
only library.
Scott O'Bryan wrote:
The Apache MVN website says this about providing a compile only
library:
The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided
Hi Scott,
On Feb 20, 2008 5:26 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
The Apache MVN website says this about providing a compile only library:
The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided at run time by its
This change does not impact 1.1.x at all. It's only a JSF 1.2 change..
Therefore it's only in the Trinidad 1.2 trunk. Do you still need this
change for 1.2? I'm not sure if the Apache Portals JSF Bridge even
works with 1.2.
Scott
Bernhard Huemer wrote:
Hello,
it would be great if you
Ok, yeah. Much to my embarrassment, my local trunk_1.2.x repository was
mapped to trunk.. Sorry. I'll fix that right away.
Scott
Scott O'Bryan wrote:
Matthias,
Yeah, both of these are issues. This should be in Trunk 1.2 and the
demo should run without the classes in the classpath. I'll
Hello,
that's because there's a dependency to PortletNamingContainerUIViewRoot
even if you're using this StateManager in a Servlet environment (due to
the import). In order to overcome this issue Scott could introduce an
additional indirection so that the class Portlet..UIViewRoot will only
The Apache MVN website says this about providing a compile only library:
The scope you should use for this is |provided|. This indicates to
Maven that the dependency will be provided at run time by its
container or the JDK, for example.
Dependencies with this scope will not be
Matthias,
Yeah, both of these are issues. This should be in Trunk 1.2 and the
demo should run without the classes in the classpath. I'll revert my
change in trunk and move it. Sorry about that.
As for compile scope, I'll check it out. The intent of this change was
to NOT require the
Hello,
it would be great if you could check whether the class actually exists.
I'm using the Apache Portals JSF Bridge with MyFaces 1.1.x.
regards,
Bernhard
On 02/20/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
We can, but it's a lot of overkill. My concern going forward, however,
is
LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
99.9% of the code is shared and only a private inner class contains
the change. I'll figure something out.
That said, I'm not sure it's the import necessarily. But I'll trace
though it to see what I've got. I know that
Hi,
On Feb 20, 2008 5:54 PM, Bernhard Huemer [EMAIL PROTECTED] wrote:
Hello,
that's because there's a dependency to PortletNamingContainerUIViewRoot
even if you're using this StateManager in a Servlet environment (due to
the import). In order to overcome this issue Scott could introduce an
[
https://issues.apache.org/jira/browse/TRINIDAD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Cooper reopened TRINIDAD-901:
--
Reopen for backporting to 1.1 trunk.
Trinidad demos use deprecated styleClass=AFDataText
[
https://issues.apache.org/jira/browse/TRINIDAD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Cooper resolved TRINIDAD-901.
--
Resolution: Fixed
Fix Version/s: 1.0.7-core
Trinidad demos use deprecated
It is not possible to style the options in a SelectOneChoice
Key: TRINIDAD-962
URL: https://issues.apache.org/jira/browse/TRINIDAD-962
Project: MyFaces Trinidad
Issue Type:
Hello,
LOL. Seriously the Jsr301StateManagerImpl is the wrong answer.
99.9% of the code is shared and only a private inner class contains
the change. I'll figure something out.
actually, I was just kidding but nevertheless noone said that the
Jsr301StateManagerImpl isn't allowed to
Reduce memeory allocations in DocumentRenderer::_renderSkinProperties
-
Key: TRINIDAD-963
URL: https://issues.apache.org/jira/browse/TRINIDAD-963
Project: MyFaces Trinidad
[
https://issues.apache.org/jira/browse/TRINIDAD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman deleted TRINIDAD-963:
Reduce memeory allocations in DocumentRenderer::_renderSkinProperties
+1
On Wed, Feb 20, 2008 at 1:41 AM, Manfred Geiler [EMAIL PROTECTED]
wrote:
+1
--Manfred
On Feb 19, 2008 11:49 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Over the next few days I'm going to be moving in my changes to support
multiple bridges. As a fist step, I need to move the current
add links to tag doc and skinning doc to demos
--
Key: TRINIDAD-964
URL: https://issues.apache.org/jira/browse/TRINIDAD-964
Project: MyFaces Trinidad
Issue Type: Improvement
Components:
[
https://issues.apache.org/jira/browse/TRINIDAD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandy Schaffner updated TRINIDAD-964:
-
Status: Patch Available (was: Open)
add links to tag doc and skinning doc to demos
Ok, I think I fixed it. Bernhard, you were right, it needed to be
moved. ExternalContextUtils works because I use reflection to get the
classes.. duh!
Anyway I removed the checkin from trunk.
Added the checking to trunk_1.2.x
And modified the previous checkin to 1.2.6.1-branch
I tested it
I am trying to show the details of 'SelectItem' object of SelectOneListBox
on a set of Input fields. Problem that I am facing is, whenever the page is
rendered partially, it always returns the 'value' of SelectOneListBox as
null. I have tried using both 'change' and 'click' facets, and both of
Hi Andrew and Matthias,
I fully agree. But please don't forget that if a certain (whatever)
DOCTYPE can be selected, that also all generated code should conform to
that DOCTYPE! Maybe that could be a reason not to allow certain types?
Regards, Paul.
Matthias Weßendorf (JIRA) wrote:
[
thank!
and yes, jetty is a damn cool container ;-)
-Matthias
On Thu, Feb 21, 2008 at 3:13 AM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Ok, I think I fixed it. Bernhard, you were right, it needed to be
moved. ExternalContextUtils works because I use reflection to get the
classes.. duh!
Hello,
I'm fine with this restriction as I'm using the Apache Portal JSF
Bridge only in cases where I can't use the JSR 301 Bridge (due to the
JSF 1.2 dependency).
regards,
Bernhard
On 02/21/2008 +0100,
Scott O'Bryan [EMAIL PROTECTED] wrote:
Ok, I think I fixed it. Bernhard, you were
46 matches
Mail list logo
