[
http://issues.apache.org/jira/browse/MYFACES-1121?page=comments#action_12366597
]
Grigoras Cristinel commented on MYFACES-1121:
-
Thanks,
I have used your solution. I hope somebody will find the real problem.
Cristi
Ok, I will now fix all the tomahawk dependencies and do some tests.
Stay tuned.
Manfred
On 2/15/06, Dennis Byrne [EMAIL PROTECTED] wrote:
How would we check if someone accidentally made a mistake and accessed
impl in tomahawk?
This has happened at least once but it was fixed, so +1 .
Hi All,
If we have good mock support there is no real reason to continue with
any particular cactus test. It is much easier and faster to run tests
in JUnit if you have a good set of mocks. So lets go down that way.
From what I remember all the cactus tests that I did were more or
less
On 2/16/06, James Holmes [EMAIL PROTECTED] wrote:
Thanks for the feedback Sean. From reading everyone else's feedback too, I'm
thinking it's best to just convert what already exists in xdoc format to APT
format initially. Once that's done, we can address what the desired content
of the pages
I think the dependencies are already the way we want them.
Sean
On 2/16/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, I will now fix all the tomahawk dependencies and do some tests.
Stay tuned.
Manfred
On 2/15/06, Dennis Byrne [EMAIL PROTECTED] wrote:
How would we check if someone
No, there are still some quirks to be fixed.
e.g. tomahawk examples must not have compile dependency to impl etc.
I have already fixed most of this, but I want to make sure that
everything builds fine and the wars contain every lib that's needed
before I commit.
Manfred
On 2/16/06, Sean
OK I will go forward with this shortly. (Probably over the weekend.)
We will need everyone's help to sort things out once the instances are
set up.
Sean
On 2/14/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 2/14/06, Sean Schofield [EMAIL PROTECTED] wrote:
Regarding commons, most users
Wait a sec. The examples are different. We *want* those to depend on
tomahawk and we want the dependencies to be included in the WAR.
Sean
On 2/16/06, Manfred Geiler [EMAIL PROTECTED] wrote:
No, there are still some quirks to be fixed.
e.g. tomahawk examples must not have compile dependency
Hi everybody,
Hope it is the right mail list...
We are using MyFaces from about 1 year for test.. We have decided to
use it more :-)
I'm updating from version 1.0.9 to 1.1.1. I enconter many issues... Can
anyone help me for this upgrate ? At least :
1. I canot use the subversion
Please post to the user list.
On 2/16/06, Guillaume Doumenc [EMAIL PROTECTED] wrote:
Hi everybody,
Hope it is the right mail list...
We are using MyFaces from about 1 year for test.. We have decided to use it
more :-)
I'm updating from version 1.0.9 to 1.1.1. I enconter many issues...
No, we don't want examples to depend on myfaces-impl during compile time.
Yes, we want myfaces-impl to be included in the WAR.
Therefore the correct scope is runtime instead of compile in this case.
Manfred
On 2/16/06, Sean Schofield [EMAIL PROTECTED] wrote:
Sorry meant to say we want those
Cool!
that was it!
Unbelievable ;)
regards,
Martin
On 2/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: schof
Date: Thu Feb 16 05:44:47 2006
New Revision: 378247
URL: http://svn.apache.org/viewcvs?rev=378247view=rev
Log:
Reverted to JDK 1.4 safe code. Old method was not
[EMAIL PROTECTED] schrieb:
fixed class loading issue for WebSphere compatibility
Gratulation!!
Habt ihr es doch noch gefunden.
Ciao,
Mario
smime.p7s
Description: S/MIME Cryptographic Signature
Ok, just committed the fixes. Did clean compile and some quick tests
with resulting WARs. Simple and Sandbox examples seem ok now. Wap and
Tiles seem to have some quirks that have nothing to do with my fixes.
Details:
1. tomahawk: changed myfaces-impl dependency from compile to test
(Ideally
Mario was saying...
congrats!!
you found it ...
-Matthias
On 2/16/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
fixed class loading issue for WebSphere compatibility
Gratulation!!
Habt ihr es doch noch gefunden.
Ciao,
Mario
--
Matthias Wessendorf
Oops, I wanted to send him per pm but forgot to change the mail address.
Mario was saying...
congrats!!
you found it ...
-Matthias
On 2/16/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
fixed class loading issue for WebSphere compatibility
OK I think runtime will work.
Sean
On 2/16/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, just committed the fixes. Did clean compile and some quick tests
with resulting WARs. Simple and Sandbox examples seem ok now. Wap and
Tiles seem to have some quirks that have nothing to do with my
On 2/16/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,If we have good mock support there is no real reason to continue withany particular cactus test. It is much easier and faster to run testsin JUnit if you have a good set of mocks. So lets go down that way.
That's been my experience as
Thanks for the fix Arvid. Just applied it.
Sean
On 2/11/06, Arvid Hülsebus [EMAIL PROTECTED] wrote:
Adding the following to style.css
#banner img {
behavior: url(css/png-fix.htc);
}
and placing the other attachements like this:
site/src/site/resources/css/
png-fix.htc
The maven dev team is going to vote on releasing the xslt-plugin next
week. So I think we wait an release against that. In the meantime I
believe they updated a new snapshot so we could change the trunk to
use the newer version and drop the antanion snapshot repository.
Sean
That is great Adam,
Is the source of the docs in the link below a standard tld file? if
so that is great!
TTFN,
Bill Dudney
MyFaces - myfaces.apache.org
Wadi - incubator.apache.org/wadi
On Feb 16, 2006, at 9:42 AM, Adam Winer wrote:
FWIW, one of the tools that will be coming from the
FYII did an update and deployed both simple tiles.Simple worked fine (for the minimal clicking I did) but the tiles war failed on the welcome pagehttp://localhost:8080/myfaces-example-tiles/page1.jsfGave me;java.lang.NullPointerException
Just looked at
no tiles,xml defined in web.xml
I'll change!
On 2/16/06, Bill Dudney [EMAIL PROTECTED] wrote:
FYI
I did an update and deployed both simple tiles.
Simple worked fine (for the minimal clicking I did) but the tiles war failed
on the welcome page
Just a reminder to fix major bugs related to the *core* on the branch
only. We'll merge the branch down to the trunk after the release.
This sounds like a tomahawk thing though ...
Sean
On 2/16/06, Bill Dudney [EMAIL PROTECTED] wrote:
FYI
I did an update and deployed both simple tiles.
conversion of docs from xdoc to APT
---
Key: MYFACES-1129
URL: http://issues.apache.org/jira/browse/MYFACES-1129
Project: MyFaces
Type: Improvement
Components: Tomahawk
Reporter: James Holmes
Attachments: aliasBean.apt,
[ http://issues.apache.org/jira/browse/MYFACES-1129?page=all ]
James Holmes updated MYFACES-1129:
--
Attachment: aliasBean.apt
conversion of docs from xdoc to APT
---
Key: MYFACES-1129
URL:
Hey all,Would someone be kind enough to post and describe all the common maven targets on the wiki? Being a maven newb, this would mucho helpful. Also, has anyone tried the maven plugins for intellij? I've tried the ConsoleMavenPlugin and the Mavenide one, but they don't appear to pickup the Goals
Hi Adam,
that stuff looks really great!
-Matthias
On 2/16/06, Adam Winer [EMAIL PROTECTED] wrote:
It's not a TLD file, since TLDs simply don't have any
of this information. Instead, it's a faces-config file.
Our approach is that TLDs and JSP tags in general
are secondary artifacts;
I agree with Simon; it's better to be explicit. I can't
see a solid justification for omitting them. I do,
however, dislike seeing abstract prepended.
If nothing else, including public (and excluding
abstract) makes it easier to cut-and-paste from an
interface into a class implementing the
If nothing else, including public (and excluding
abstract) makes it easier to cut-and-paste from an
interface into a class implementing the interface.
hehe.
Anyway, we should make it clear, which kind of *convention* we use.
the sun check-style is against, using public in interfaces AFAIK.
I think these plugins are Maven 1 only -- like the Raven Plugin...
Regards,
Arvid
Travis Reeder wrote:
Hey all,
Would someone be kind enough to post and describe all the common maven
targets on the wiki? Being a maven newb, this would mucho helpful.
Also, has anyone tried the maven
A high traffic site running MyFaces of course. I recall seeing an email not long ago about this, but I can't seem to find it. Travis
matt raible in his blog...
From: Travis Reeder [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 11:51 PMTo: MyFaces
DevelopmentSubject: Was someone looking for a public high traffic
site?
A high traffic site running MyFaces of course. I recall
seeing an email
[
http://issues.apache.org/jira/browse/MYFACES-1129?page=comments#action_12366719
]
James Holmes commented on MYFACES-1129:
---
No, this index.apt is for Sandbox. If you look in the comments I submitted when
creating the ticket you will see the paths
Do you have one, Travis?
regards,
Martin
On 2/16/06, Jesse Alexander (KBSA 21) [EMAIL PROTECTED] wrote:
matt raible in his blog...
From: Travis Reeder [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 11:51 PM
To: MyFaces Development
[
http://issues.apache.org/jira/browse/MYFACES-1129?page=comments#action_12366722
]
sean schofield commented on MYFACES-1129:
-
Yeah i had figured that out already. I'm testing the mvn site now before
committing. I'm having an unrelated compile
[ http://issues.apache.org/jira/browse/MYFACES-1129?page=all ]
sean schofield closed MYFACES-1129:
---
Fix Version: Nightly
Resolution: Fixed
conversion of docs from xdoc to APT
---
Key: MYFACES-1129
[ http://issues.apache.org/jira/browse/MYFACES-911?page=all ]
sean schofield updated MYFACES-911:
---
Attachment: (was: TreeWalker.patch)
Allow user to supply their own tree2 id scheme using new TreeWalker interface
[ http://issues.apache.org/jira/browse/MYFACES-911?page=all ]
sean schofield closed MYFACES-911:
--
Resolution: Fixed
Allow user to supply their own tree2 id scheme using new TreeWalker interface
Hi Sylvain,
how hard would it be for you to loose the moving circle you have built
in in the current inputSuggestAjax component? Or to reapply what
you've done to the dojo version we are currently building?
For the reasons we have pointed out earlier on this list, we'd like to
move over to the
Hi,
after moving inputSuggestAjax to dojo, the new component would look
something like this one:
http://archive.dojotoolkit.org/nightly/tests/widget/test_ComboBox.html
regards,
Gerald
On 2/17/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Sylvain,
how hard would it be for you to loose
I'm not a big fan of the circle anyways so I'm definitely ok with it.
But I'm not the one you asked ;-)
Sean
On 2/16/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Sylvain,
how hard would it be for you to loose the moving circle you have built
in in the current inputSuggestAjax
ah,
I was looking for a sample like this
On 2/17/06, Gerald Müllan [EMAIL PROTECTED] wrote:
Hi,
after moving inputSuggestAjax to dojo, the new component would look
something like this one:
http://archive.dojotoolkit.org/nightly/tests/widget/test_ComboBox.html
regards,
Gerald
On
Sean Schofield schrieb:
I'm not a big fan of the circle anyways so I'm definitely ok with it.
But I'm not the one you asked ;-)
Sean
Well I am not Sylvain, but given the fact that around 99% of the custom
javascript code we have can be dropped with the inputsuggest from dojo
+1 from my side
Hello Martin,
I'm on the plane today, but I'll check that over the week-end.
Best regards,
Sylvain.
On Fri, 2006-02-17 at 04:15 +0100, Martin Marinschek wrote:
Hi Sylvain,
how hard would it be for you to loose the moving circle you have built
in in the current inputSuggestAjax
45 matches
Mail list logo
