Is this still a vote now?
Can we start a separate thread?
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
the plugin includes the notice/license
if not present, it generates them
-M
On Dec 20, 2007 8:06 AM, simon [EMAIL PROTECTED] wrote:
On Thu, 2007-12-20
+1
regards,
Martin
On 12/20/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
+1
Matthias Wessendorf schrieb:
yes,
that is correct.
-M
On Dec 20, 2007 8:27 AM, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello,
are the release notes correct?
Hi Nicu,
we should include Mario in this discussion - he implemented a solution
for this in Orchestra. Also, how about Trinidad, in Trinidad there is
dialog handling as well, how is this done?
regards,
Martin
On 12/19/07, simon [EMAIL PROTECTED] wrote:
Hi Nicu,
I haven't got time to look at
[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553610
]
Michael Kutsch commented on TRINIDAD-845:
-
We have the same problem. I am working for an insurance company
Hi,
anyone is invited to contribute with ideas of course,
but I still don't understand what this (multiple-frames state saving) has to
do with dialog handling and conversations!?
On Dec 20, 2007 9:13 AM, Martin Marinschek [EMAIL PROTECTED]
wrote:
Hi Nicu,
we should include Mario in this
[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553613
]
Matthias Weßendorf commented on TRINIDAD-845:
-
IFrame or XHR you mean.
PPR is the Trinidad feature.
Orchestra provides a tag that can be explicitly wrapped around links (eg
h:outputLink). It then encodes a window id into the url params.
So it also partially addresses the second part of the problem (identifying
windows/frames). It covers more cases than Nicu's suggestion, but it does
require
+1
Thank you Leonardo!
Bruno
On 20/12/2007, Martin Marinschek [EMAIL PROTECTED] wrote:
+1
regards,
Martin
On 12/20/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
+1
Matthias Wessendorf schrieb:
yes,
that is correct.
-M
On Dec 20, 2007 8:27 AM, Bernd Bohmann [EMAIL
[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553615
]
Matthias Weßendorf commented on TRINIDAD-845:
-
Michael,
does IE6 supports XHR, but only via ActiveX.
Nicu's solution works fine for MyFaces commandLinks using the MyFaces
JspStateManager.
Someone using MyFaces Tomahawk can take advantage out of this new view
pool approach.
The big problem here: It does not work using a component library that
decorates the statemanager (eg. trinidad).
So far I
state management and multiple frames
-
Key: MYFACES-1791
URL: https://issues.apache.org/jira/browse/MYFACES-1791
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects
tested Trinidad 12x trunk against it.
Fine so far!
On Dec 20, 2007 7:53 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Thanks for replacing the bits.
+1
-Matthias
On Dec 19, 2007 9:13 PM, simon [EMAIL PROTECTED] wrote:
On Wed, 2007-12-19 at 11:54 -0800, Grant Smith wrote:
+1
Hi,
just moved the 1.0.x (for JSF 1.1) to this location:
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/
so, no more trinidad/trinidad
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail:
My solution doesn't work only with commandLinks but works as well with
outputLink or JavaScript by adding a GET parameter like in the
following example:
h:outputLink value=multipleFrames.jsf target=_blank
f:param name=target value=_blank/
/h:outputLink
It also works for any submitted
What Thomas said about Trinidad and any other component library with their
own state manager is very true.
It would be nice to have the SerializedViewCollection (the view pool from
JspStateManagerImpl) to be delegated to handle the actual storing of the
views.
But that still implies modifying
Hello there,
I am trying to debug a myfaces 1.2.0 app but the sources download does not
contain the WebXml class. I have checked both the maven repository and the
main download site. The snapshot version for 1.2.1 also does not have this
class included.
Thanks, Carl
--
View this message in
ok...
looks like myfaces-build-tools won the race.
structure will be
/myfaces-build-tools
-/maven2-plugins
-/all the current (trin) plugins
-tbc
-M
On Dec 15, 2007 11:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
there is this maven plugins folder for the Trinidad Plugins
Hi,
that is part of the shared;
package org.apache.myfaces.shared_impl.webapp.webxml
check this JAR:
http://repo1.maven.org/maven2/org/apache/myfaces/shared/myfaces-shared-impl/3.0.0/myfaces-shared-impl-3.0.0-sources.jar
(was used to build 1.2.0)
-M
On Dec 20, 2007 11:14 AM, Carl Howarth
But the source download for myfaces really should include the shared classes
too. The .class files are in the myfaces impl jar, so the (repackaged) sources
should be in the corresponding source jarfile.
I would *really* like to see this fixed for the next release. It's a pain to be
stepping
On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote:
But the source download for myfaces really should include the shared classes
too. The .class files are in the myfaces impl jar, so the (repackaged)
sources should be in the corresponding source jarfile.
currently the sources
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote:
But the source download for myfaces really should include the shared
classes too. The .class files are in the myfaces impl jar, so the
(repackaged) sources should be in
On Dec 20, 2007 12:45 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote:
But the source download for myfaces really should include the shared
classes too. The .class files are
As Leonardo is working on the release anyways, he might take a stab?
regards,
Martin
On 12/20/07, Simon Kitching [EMAIL PROTECTED] wrote:
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote:
But the source download for
I still think the ideal way would be to do the repackaging on release
only - for the normal build process, we could leave it as is.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 12:45 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Matthias
hrm,
I think the regular build should be similar to the release,
But for the release do things like signing etc as an extra step;
-M
On Dec 20, 2007 12:50 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
I still think the ideal way would be to do the repackaging on release
only - for the normal
Hi,
IMO the archetypes could be moved into the build-tools as well.
/myfaces-build-tools
-/maven2-plugins
-/maven2-archetype
-here they are
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail:
[
https://issues.apache.org/jira/browse/TOMAHAWK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Price resolved TOMAHAWK-1171.
--
Resolution: Fixed
I realized the component referenced by the binding attribute on the
Did a relocate of the plugins to:
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-plugins/
the current trinidad-pluings are still in their trinidad-maven trunk;
I renamed the plugins to be compliant to the naming-schema
maven-blah-plugin means that blah is a plugin
+1 yes, sure
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
IMO the archetypes could be moved into the build-tools as well.
/myfaces-build-tools
-/maven2-plugins
-/maven2-archetype
-here they are
-M
--
Matthias Wessendorf
further stuff:
blog:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the java packages like:
-org.apache.myfaces.build.wagon
-org.apache.myfaces.build.faces
-...
WDYT ?
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions:
yes, ok
or org.apache.myfaces.buildtools ?
--Manfred
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the java packages like:
-org.apache.myfaces.build.wagon
-org.apache.myfaces.build.faces
-...
sounds good;
On Dec 20, 2007 2:08 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
yes, ok
or org.apache.myfaces.buildtools ?
--Manfred
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the java packages like:
-org.apache.myfaces.build.wagon
-org.apache.myfaces.build.faces
-...
WDYT ?
+1
Thanks for the build-tools stuff Matthias. That's a very nice tidyup. Having
myfaces-core depend on stuff called trinidad was rather confusing...
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
Did a relocate of the plugins to:
+1
On Dec 20, 2007 2:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
+1 yes, sure
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
IMO the archetypes could be moved into the build-tools as well.
/myfaces-build-tools
-/maven2-plugins
-/maven2-archetype
+1
On 20/12/2007, Manfred Geiler [EMAIL PROTECTED] wrote:
yes, ok
or org.apache.myfaces.buildtools ?
--Manfred
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the java packages like:
+1
On 20/12/2007, Cagatay Civici [EMAIL PROTECTED] wrote:
+1
On Dec 20, 2007 2:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
+1 yes, sure
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
IMO the archetypes could be moved into the build-tools as well.
On Dec 20, 2007 2:45 PM, [EMAIL PROTECTED] wrote:
Author: skitching
Date: Thu Dec 20 05:45:06 2007
New Revision: 605927
URL: http://svn.apache.org/viewvc?rev=605927view=rev
Log:
Remove accidental use of java 1.6 method String.isEmpty
isn't the build catching this ?
-M
Modified:
No - if you are building with 1.6, it won't. Only the language level is checked.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 2:45 PM, [EMAIL PROTECTED] wrote:
Author: skitching
Date: Thu Dec 20 05:45:06 2007
New Revision: 605927
URL:
+1,
regards,
Martin
On 12/20/07, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On 20/12/2007, Cagatay Civici [EMAIL PROTECTED] wrote:
+1
On Dec 20, 2007 2:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
+1 yes, sure
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED]
I thought the compile was configured for source/target not 1.5 || 1.6
-M
On Dec 20, 2007 3:18 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
No - if you are building with 1.6, it won't. Only the language level is
checked.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL
On Dec 20, 2007 3:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I thought the compile was configured for source/target not 1.5 || 1.6
(the compiler plugin)
-M
On Dec 20, 2007 3:18 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
No - if you are building with 1.6, it won't. Only the
Yes, so 1.5/1.6 syntax will correctly be found and disallowed. But API
changes are not checked for, so a newly added method will not be
found.
regards,
Martin
On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 3:19 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I
So,
you say that a configuration like:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
inheritedtrue/inherited
configuration
source1.5/source
target1.5/target
/configuration
/plugin
does allow you to use JDK6 methods?
That would be a
yes, that is what I'm saying.
Saying that this is a bug is maybe pushing it too hard... the
attributes just translate into a compiler language level - that does
not mean that someone automagically knows all API changes from 1.4 to
1.6 and automatically applies them. The only chance for you to
Yes, well, with Trinidad the suggested changes won't work - but
Trinidad has some internal means of doing something similar to what is
proposed here, so first we should check what Trinidad is doing. Can
you check/send a mail with Trinidad in the subject line?
regards,
Martin
On 12/20/07, Cristi
I'd be fine with Java5 instead of 1.4
-M
On Dec 20, 2007 3:37 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
yes, that is what I'm saying.
Saying that this is a bug is maybe pushing it too hard... the
attributes just translate into a compiler language level - that does
not mean that someone
relocated to:
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2-archetypes/
renamed them to fit into the proper naming schema.
will update the wiki as well.
(name, location, etc)
-M
On Dec 20, 2007 3:18 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
+1,
regards,
This problem happens no matter what java versions are being talked about. When
the aim is to support java N, but the latest is java X then it is difficult to
prevent accidents.
Compiler property source prevents the use of *language features* that are not
supported in the specified version
+1
Simon Kitching schrieb:
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
Hi,
I like to use
groupIdorg.apache.myfaces.build/groupId
as the groupId
And the java packages like:
-org.apache.myfaces.build.wagon
-org.apache.myfaces.build.faces
-...
WDYT ?
+1
I saw in the logs, that the zone uses JDK6.
Is there a special reason for that ?
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
[
https://issues.apache.org/jira/browse/TRINIDAD-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553711
]
Matthias Weßendorf commented on TRINIDAD-65:
I just used the Trinidad 1.0.5-SNAPSHOT from MyFaces's
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
On Dec 20, 2007 10:11 AM, Simon Kitching [EMAIL PROTECTED] wrote:
This problem
+1
On Dec 20, 2007 12:59 AM, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
Thank you Leonardo!
Bruno
On 20/12/2007, Martin Marinschek [EMAIL PROTECTED] wrote:
+1
regards,
Martin
On 12/20/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
+1
Matthias Wessendorf schrieb:
yes,
Hi,
I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out. This mail is to make clear that the vote still
continues and the problems
discussed before already has been solved.
Please note that this vote concerns all of the following parts:
1. Maven artifact group
On Dec 20, 2007 5:42 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out. This mail is to make clear that the vote still
continues and the problems
discussed before already has been solved.
Please note that this
+1
On Dec 20, 2007 8:47 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 5:42 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core out. This mail is to make clear that the vote still
continues
+1
On 20/12/2007, Grant Smith [EMAIL PROTECTED] wrote:
+1
On Dec 20, 2007 8:47 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 5:42 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.2.1 release of Apache
MyFaces core
nevermind.
I got confused by vmbuild (welcome back to life :-) )
On Dec 20, 2007 4:42 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I saw in the logs, that the zone uses JDK6.
Is there a special reason for that ?
-M
--
Matthias Wessendorf
further stuff:
blog:
+1 - I looked through the artifacts, and they are ok - the shared
sources are missing, something we can include in the next release.
regards,
Martin
On 12/20/07, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On 20/12/2007, Grant Smith [EMAIL PROTECTED] wrote:
+1
On Dec 20, 2007 8:47 AM,
Could someone please fix the continuum configuration, or at least disable the
scheduled build for trinidad?
Since the svn changes of today, there has been a regular stream of error emails
to [EMAIL PROTECTED]
I presume these are because pom files have now moved, and that fixing the
config is
Mike Kienenberger [EMAIL PROTECTED] schrieb:
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
Yep. However that cannot be
I agree, but it could be set up on the continuum server (if it's not
already set up there).
I know nothing about maven, but maybe the rt.jar can be pulled down
into the repository, where it should be in a standard location.
On Dec 20, 2007 12:36 PM, Simon Kitching [EMAIL PROTECTED] wrote:
On 12/20/07, Simon Kitching [EMAIL PROTECTED] wrote:
Mike Kienenberger [EMAIL PROTECTED] schrieb:
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath
NLS: Translation to always honor view locale not formatting locale
--
Key: TRINIDAD-879
URL: https://issues.apache.org/jira/browse/TRINIDAD-879
Project: MyFaces Trinidad
Issue
Hi there,
Our local NLS expert brought this bug to my attention. I created a JIRA
issue https://issues.apache.org/jira/browse/TRINIDAD-879
Here is what I have there. Let me know if you think that this is not a
bug. I plan to fix it.
Thanks!
Jeanne
Trinidad embedded translations should
+1
On Dec 20, 2007 7:26 PM, Martin Marinschek [EMAIL PROTECTED]
wrote:
+1 - I looked through the artifacts, and they are ok - the shared
sources are missing, something we can include in the next release.
regards,
Martin
On 12/20/07, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On
I did a test-drive w/ trinidad 1.2.5-SNAPSHOT
all cool over there.
good job guys!
On Dec 20, 2007 5:47 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Dec 20, 2007 5:42 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.2.1 release of Apache
yah,
tomorrow :-)
On Dec 20, 2007 6:32 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Could someone please fix the continuum configuration, or at least disable the
scheduled build for trinidad?
Since the svn changes of today, there has been a regular stream of error
emails to [EMAIL
fixed (deleted)
On Dec 20, 2007 11:21 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
yah,
tomorrow :-)
On Dec 20, 2007 6:32 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Could someone please fix the continuum configuration, or at least disable
the scheduled build for trinidad?
Since
Clientside validation errors when using PPR
---
Key: TRINIDAD-880
URL: https://issues.apache.org/jira/browse/TRINIDAD-880
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.4-core,
71 matches
Mail list logo
