Ok folks, I will try to start the release process for tomahawk next week.
Well, regarding the branch there are various possibilities:
- use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4
- throw away existing 1.1.4 branch, create new branch and release 1.1.4
- (optionally)
Hi,
+1 for throwing away 1.1.4, creating a new branch using current trunk and
releasing 1.1.4.
Cagatay
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok folks, I will try to start the release process for tomahawk next week.
Well, regarding the branch there are various possibilities:
-
Hi Cagatay!
I'd really really like to help if you need:)
There is plenty of room to help :-)
Thanks!
Short term todos are:
* Demo App
* Documentation
Regarding the DemoApp, maybe Werner is able to donate one, if not we
have to build one.
Would be great if you could help there if we have to
Hi Mario,
In the meantime I'll start digging the codebase and hopefully reach a level
where I can start to contribute soon:)
Cheers,
Cagatay
On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi Cagatay!
I'd really really like to help if you need:)
There is plenty of room to help :-)
I agree.
The old 1.1.4 RC is getting really aged now.
However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5
Regards,
Erik-Berndt
Van: Cagatay Civici [mailto:[EMAIL PROTECTED]
Verzonden: vr 23-2-2007 9:27
Aan: MyFaces Development
Hi,
TableSuggestAjax is behaving incorrectly after restore view phase in JSF.
This is due to incorrect implementation of
org.apache.myfaces.component.html.ext.HtmlInputText class
- attribute autocomplete is NOT stored/restored (in
saveState/restoreState methods).
And question - why is
[
https://issues.apache.org/jira/browse/TOMAHAWK-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475301
]
Robert Oschwald commented on TOMAHAWK-887:
--
This issue seems not to be limited to portlets.
We got this
Hi,
by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1
issue, which could block extending usability of dojo.
Problem is in static method getAttributeMap(FacesContext, String[] ,
UIComponent):
- it doesn't count with preferred way of declaring get methods dealing
with
Regarding the demo-app, i could help out with a nice open-source
design which i had improved and used in a sourceforge app and our
[EMAIL PROTECTED] website:
http://jsfatwork.irian.at
Let me know if it seems to be useful for MyFaces Fusion. I am willing
to re-design the demo-app so that it is
Same as Cagatay. Current head should be stable enough!
There was no big change last weeks in tomahawk. Due to using latest
tom in a current app
i can admit that there seem to be no new issues.
Gerald
On 2/23/07, Cagatay Civici [EMAIL PROTECTED] wrote:
Hi,
+1 for throwing away 1.1.4, creating
Mathias-
did you now add the myfaces 1.2 stuff to continuum ?
In the meantime, I just published myfaces12 to a staging repo ([1]).
that should at least help the geronimo folks a bit .
-M
[1] http://people.apache.org/~matzew/myfaces12-stage/
--
Matthias Wessendorf
http://tinyurl.com/fmywh
Hi Matthias,
I still have no rights on the continuum server at port 8081. The
account mrmaven is locked there. I've created an account for me (mbr)
but someone needs to give me more rights.
Have you configured continuum to do the deployment? Or have you done
it manually?
The build problems for
we should overhaul the distributionManagement section
to be able to run
mvn clean install source:jar deploy
-M
On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi Matthias,
I still have no rights on the continuum server at port 8081. The
account mrmaven is locked there. I've created
btw. you are root ?
if so, can you create me an account matzew as well on the zone ?
(speaking of a unix account)
-M
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
we should overhaul the distributionManagement section
to be able to run
mvn clean install source:jar deploy
-M
On
no I'm not root.
2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]:
btw. you are root ?
if so, can you create me an account matzew as well on the zone ?
(speaking of a unix account)
-M
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
we should overhaul the distributionManagement
ah, ok for cont.
however, I am not able to edit the things...
I committed the dist. mgmt in the meantime.
mvn clean install
should be moved to
mvn clean install source:jar deploy
On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
no I'm not root.
2007/2/23, Matthias Wessendorf [EMAIL
hello continuum admins,
the http://myfaces.zones.apache.org:8081 mrmaven account is locked currently.
any change to get it unlocked ?
-M
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
The new tomahawk release number is a trade-off.
We must decide between
- releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and
therefore might confuse users
- skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk
1.1.5 that is 100% compatible to the current core 1.1.5
both sounds bad...
no idea, funny enough, that almost every tomahawk release has a high
dependency on the core code :)
-M
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
The new tomahawk release number is a trade-off.
We must decide between
- releasing tomahawk 1.1.4 which is not
I slightly have a better feeling w/ skipping 1.1.4 but let's document
this very good ;)
-M
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
both sounds bad...
no idea, funny enough, that almost every tomahawk release has a high
dependency on the core code :)
-M
On 2/23/07, Manfred
I suggest releasing from the head with a version of 1.1.5. Releasing
the head as 1.1.4 to me is more confusing for the following reasons:
o It is currently called 1.1..5-SNAPSHOT
o Issues are linked to 1.1.5-SNAPSHOT
o Mailing list post refer to 1.1.5-SNAPSHOT
o 1.1.4 has already gone
I have also developed a simple application which I want to use teaching
MyFaces.
I have used Seam components for integration with JPA as data access layer.
It looks like this fusion lead a more pure MyFaces application.
and I am ready to use it, if you provide some minimum guidelines for rest of
The MyFaces website should support version specific documentation. This is
important
when users are looking for answers for a released version and the site only
documents
the current Snapshot. The Shale and Tomahawk sites have version specific
documentation
I suspect this can be done via
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
The new tomahawk release number is a trade-off.
We must decide between
- releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and
therefore might confuse users
- skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk
Arash-
is your app somewhere accessable ?
-M
On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
I have also developed a simple application which I want to use teaching
MyFaces.
I have used Seam components for integration with JPA as data access layer.
It looks like this fusion lead a more
+1 for release number tomahawk 1.1.5
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
I suggest releasing from the head with a version of 1.1.5. Releasing
the head as 1.1.4 to me is more confusing for the following reasons:
o It is currently called 1.1..5-SNAPSHOT
o Issues are linked
I can send a working copy to your private email. if you want.
zubin is going to use it in his book.
I am changing it each day to make it easier for developers learning MyFaces.
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Arash-
is your app somewhere accessable ?
-M
On 2/23/07,
[
https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475337
]
Mathias Broekelmann commented on MYFACES-1246:
--
I looked into the spec section 5.4. Besides
Ok, thanks for your feedback.
Branch 1.1.5 created.
--Manfred
On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
The new tomahawk release number is a trade-off.
We must decide between
- releasing tomahawk 1.1.4 which is not compatible to
Wendy,
Type-o on my part, I meant to say the Tomcat site support version specific
documentation, not Tomahawk.
Distributing to a version specific URL is part of the solution, the navigation
bar also need a entry the the version specific documentation.
Paul Spencer
Wendy Smoak wrote:
On
slightly too late, but 1.1.5 would have been my option as well.
other option: 1.5 - and let tomahawk and impl version numbers get out of sync.
regards,
Martin
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, thanks for your feedback.
Branch 1.1.5 created.
--Manfred
On 2/23/07,
that would be another very good option
-M
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
slightly too late, but 1.1.5 would have been my option as well.
other option: 1.5 - and let tomahawk and impl version numbers get out of sync.
regards,
Martin
On 2/23/07, Manfred Geiler [EMAIL
Yes, good idea.
So, next tomahawk release would be 1.5.0.
+1 on that from my side
--Manfred
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
slightly too late, but 1.1.5 would have been my option as well.
other option: 1.5 - and let tomahawk and impl version numbers get out of sync.
If the version of Tomahawk is not tied to the version of MyFaces, then
how about the NEXT version of Tomahawk be 1.6?
This would allow Tomahawk, like Tobago, to be version independently of MyFaces.
Paul Spencer
Martin Marinschek wrote:
slightly too late, but 1.1.5 would have been my option as
-1 on 1.5.0. We have called it 1.1.5 for many months. Also the reasons
I presented for NOT calling it 1.1.4
+1 on the next version of 1.6.0
Manfred Geiler wrote:
Yes, good idea.
So, next tomahawk release would be 1.5.0.
+1 on that from my side
--Manfred
On 2/23/07, Martin
1.5.0 or 1.6.0. One is as good as the other IMO.
You mean 1.6.0 is better because it does not match the 1.1.5 of current core?
I think Martin suggested 1.5.0 because it would be in the style of
Tomcat 5.0.x vs Tomcat 5.5.x, right?
--Manfred
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
If
we sould do the same for core
next is 1.5.0
and JSF 1.2 stuff should be changed to 2.0.0
On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote:
1.5.0 or 1.6.0. One is as good as the other IMO.
You mean 1.6.0 is better because it does not match the 1.1.5 of current core?
I think Martin suggested
1) Release the head, currently know as 1.1.5-SNAPSHOT, as 1.1.5.
2) During the release process, the release plugin prompts for the next
version number. Answer 1.6.0-SNAPSHOT to the prompt.
Paul Spencer
Manfred Geiler wrote:
1.5.0 or 1.6.0. One is as good as the other IMO.
You mean 1.6.0
isn't that CCLD for what ever their OS license is named ?
Should go to the notice.txt file, IMO
-M
On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Not to slow you down, but can we distribute this?
Dennis Byrne
On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mbr
Date: Fri
+1
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
1) Release the head, currently know as 1.1.5-SNAPSHOT, as 1.1.5.
2) During the release process, the release plugin prompts for the next
version number. Answer 1.6.0-SNAPSHOT to the prompt.
Paul Spencer
Manfred Geiler wrote:
1.5.0 or
I would suggest keeping the MyFaces core version in
1.1.x range becuse any releses are just bug fixes. New
functionality can only be added when the JSR changes. At
that point should the minor version change.
+1 on releasing JSF 1.2 implementation as 2.0.0
Thus :
JSF 1.1 - MyFaces 1.x
JSF
Hi Dennis,
the problem is that you don't have any leeway to change the
MyFaces-API (read: not JSF API) incompatible to what it had been
before. Well, given we finally reach the point at which we have a
pretty stable API between bugfix-releases.
regards,
Martin
On 2/23/07, Dennis Byrne [EMAIL
How about
JSF 1.1 - MyFaces 1.1.x
JSF 1.2 - MyFaces 1.2.x
Tomahawk for JSF 1.1 - Tomahawk 1.x
Tomahawk for JSF 1.2 - Tomahawk 2.x
sub project for JSF 1.1 - sub project 1.x
sub project for JSF 1.2 - sub project 2.x
Paul Spencer
Dennis Byrne wrote:
JSF 1.1 - MyFaces 1.x
JSF 1.2 -
there was a wiki page which says that they want to have the next
version of jsf (2.0)
named 6.0
so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ...
:-)
On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote:
JSF 1.1 - MyFaces 1.x
JSF 1.2 - MyFaces 2.x
I'd rather keep
6.0? Seriously?
Dennis Byrne
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
there was a wiki page which says that they want to have the next
version of jsf (2.0)
named 6.0
so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ...
:-)
On 2/23/07, Dennis Byrne
I wasn't aware of this. the dtds of 1.0 and 1.1 are also present in
our repository...
2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]:
isn't that CCLD for what ever their OS license is named ?
Should go to the notice.txt file, IMO
-M
On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Not to
+1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x)
dennis said:
1.1 - 1.1.x,
1.2 - 1.2.x
I think
1.1 - 1.x.y
1.2 - 2.x.y
is the better one...
--Manfred
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Dennis,
the problem is that you don't have any
Dennis was suggesting
JSF 1.1 -- MyFaces 1.1
JSF 1.2 -- MyFaces 1.2
I'm against that - Manfred, your suggestion sounds good.
@MyFaces-API: well, Trinidad regards all Trinidad-component classes as
a Trinidad-API. We were once discussing on having something like that
for MyFaces as well. For
It wasn't the beer _we_ were drinking - that must have been the Sun
officials' beer. ;)
regards,
Martin
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
+1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces 2.x)
dennis said:
1.1 - 1.1.x,
1.2 - 1.2.x
I think
1.1 -
8-)
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
It wasn't the beer _we_ were drinking - that must have been the Sun
officials' beer. ;)
regards,
Martin
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
+1 on Dennis' suggestion (JSF 1.1 - MyFaces 1.x, JSF 1.2 - MyFaces
@MyFaces-API: well, Trinidad regards all Trinidad-component classes as
a Trinidad-API. We were once discussing on having something like that
for MyFaces as well. For Trinidad, a renderer is not in the
Trinidad-API, a component is
that can change... I think stuff like CoreRenderer or
I saw that post at the time, but figured it was the result of too much
doppelbock and wienerschnitzel. ;)
Matthias Wessendorf wrote:
Well... there was a meeting in munich, during the october fest...
and they discussed that...
http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006
*snip*
please file a jira issue so we don't loose this issue.
and to speed up things, providing a fix is appreciated ;)
On 2/23/07, Zdeněk Sochor [EMAIL PROTECTED] wrote:
Hi,
by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1
issue, which could block extending usability of dojo.
That would indeed be a very good change. Creating your own renderer
for Trinidad is quite hard currently...
regards,
Martin
On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
@MyFaces-API: well, Trinidad regards all Trinidad-component classes as
a Trinidad-API. We were once discussing
It's Weisswurst we ate! and a lot of that stuff.
regards,
Martin
On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
I saw that post at the time, but figured it was the result of too much
doppelbock and wienerschnitzel. ;)
Matthias Wessendorf wrote:
Well... there was a meeting in munich,
well... not in muc.
only schnitzel Wiener art, which sucks. the original is the better :-))
hefeweizen kills the JSF.next :)
-M
On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
I saw that post at the time, but figured it was the result of too much
doppelbock and wienerschnitzel. ;)
Matthias
and tons of beer :-)
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
It's Weisswurst we ate! and a lot of that stuff.
regards,
Martin
On 2/23/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
I saw that post at the time, but figured it was the result of too much
doppelbock and
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475353
]
Stefan Schuster commented on TOMAHAWK-258:
--
This is actually based on the same issues I experienced with
Yes, of course.
Sorry for bringing total confusion into this thread!
Although it might seem so, I declare that I did NOT yet drink any beer today.
(Only a small glass of wine... ;-)
I am
+1 for Paul's suggestion:
JSF 1.1 - MyFaces 1.x
JSF 1.2 - MyFaces 2.x
and I am
+1 for JSF 2.0 (or JSF6
The Geronimo project recently encountered this situation for several
JEE schemas. It wasn't totally clear whether or not including the Sun
XSDs was OK, and it was soon realized that it would be more practical
to type in the XSDs by hand than try to reach a definitive conclusion.
See this JIRA
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Schuster updated TOMAHAWK-258:
-
Status: Patch Available (was: Open)
sandbox inputSuggestAjax ignores onkeydown event
I am
+1 for Paul's suggestion:
JSF 1.1 - MyFaces 1.x
JSF 1.2 - MyFaces 2.x
and I am
+1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x
thanks!!
This is to summarize the version number discussion.
MyFaces for JSF 1.1
1.1.5 - Current Release (Announced 19-Feb-2007)
1.1.6 - Next release not currently scheduled
MyFaces for JSF 1.2
2.0.0 - Currently being developed as MyFaces 1.2
MyFaces for JSF 2.0 / JSF 6
3.0.0 - ?
Tomahawk for
+1
Thanks!
--Manfred
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
This is to summarize the version number discussion.
MyFaces for JSF 1.1
1.1.5 - Current Release (Announced 19-Feb-2007)
1.1.6 - Next release not currently scheduled
MyFaces for JSF 1.2
2.0.0 - Currently being
That could be difficult to prove but I'm willing to testify that the
person who typed in most of the specs by hand looked very very
exhausted afterwards :-)
Best wishes,
Paul
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Wow. I wonder how anyone will ever find out if they typed it or
Wow. I wonder how anyone will ever find out if they typed it or if
they just copied ;)
regards,
Martin
On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote:
The Geronimo project recently encountered this situation for several
JEE schemas. It wasn't totally clear whether or not including the Sun
I can imagine ;)
regards,
Martin
On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote:
That could be difficult to prove but I'm willing to testify that the
person who typed in most of the specs by hand looked very very
exhausted afterwards :-)
Best wishes,
Paul
On 2/23/07, Martin Marinschek
[
https://issues.apache.org/jira/browse/TOMAHAWK-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerald Müllan updated TOMAHAWK-258:
---
Resolution: Fixed
Fix Version/s: 1.1.5-SNAPSHOT
Status: Resolved (was:
Paul Spencer wrote:
This is to summarize the version number discussion.
MyFaces for JSF 1.1
1.1.5 - Current Release (Announced 19-Feb-2007)
1.1.6 - Next release not currently scheduled
MyFaces for JSF 1.2
2.0.0 - Currently being developed as MyFaces 1.2
MyFaces for JSF 2.0 / JSF 6
Check it in as you go along, and that should provide a record.
On 2/23/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Wow. I wonder how anyone will ever find out if they typed it or if
they just copied ;)
regards,
Martin
On 2/23/07, Paul McMahan [EMAIL PROTECTED] wrote:
The Geronimo project
Hi Arash!
It looks like this fusion lead a more pure MyFaces application.
and I am ready to use it, if you provide some minimum guidelines for
rest of us.
Yep, I am working on it ... should be available soonish.
Ciao,
Mario
DojoUtils class not handling isAttribute methods in components
--
Key: TOMAHAWK-906
URL: https://issues.apache.org/jira/browse/TOMAHAWK-906
Project: MyFaces Tomahawk
Issue Type:
[
https://issues.apache.org/jira/browse/TOMAHAWK-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zdenek Sochor updated TOMAHAWK-906:
---
Status: Patch Available (was: Open)
DojoUtils class not handling isAttribute methods in
I don't think Tomahawk has proved yet that it is independent from core
versioning. Take the MyFaces Core 1.1.4 incompatiblities between
Tomahawk 1.1.5 as an example.
I think we should take a wait and see attitude before we decide
we're going to start with Tomahawk 1.6 numbering.Remember,
Incorrect behaviour of HtmlInputText with ajax
--
Key: TOMAHAWK-907
URL: https://issues.apache.org/jira/browse/TOMAHAWK-907
Project: MyFaces Tomahawk
Issue Type: Bug
Components: AJAX
If there's no objections, I'll open a JIRA and submit a patch. :)
Mike Kienenberger wrote:
This change looks good to me. It's probably more important that the
value binding be able to default to null than to output an empty
string css style.
On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
t:div and t::inputCalendar confilict
-
Key: TOMAHAWK-908
URL: https://issues.apache.org/jira/browse/TOMAHAWK-908
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Mike,
As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should
be considered implementation independent. If their are known
incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those
should be noted in Tomahawk's release notes.
We can make the testing easer by
[
https://issues.apache.org/jira/browse/TOMAHAWK-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475419
]
Werner Punz commented on TOMAHAWK-906:
--
Well the reason why is was ignored was, because
it was assumed, that
Zdeněk Sochor schrieb:
Hi,
by looking at org.apache.myfaces.custom.dojoDojoUtils class i found 1
issue, which could block extending usability of dojo.
Problem is in static method getAttributeMap(FacesContext, String[] ,
UIComponent):
- it doesn't count with preferred way of declaring get
I think it's too soon to be making the decision on what to call the
next version. Let's wait and see how things go with a Tomahawk 1.1.5
release. We're still encountering dependency issues with current
Tomahawk releases. We've promised to deliver
implementation-dependent releases twice in
Mike,
As a part of the 1.1.5 release, the next version is set. Based on your
comments, the version should be set to 1.1.6. I have no problem with
this. The release of 1.1.5 should not be delayed while we determine the
next version number.
Paul Spencer
Mike Kienenberger wrote:
I think
Ok. I see where you're going. I also don't want 1.1.5 delayed
because of the next release version number. And even if we pick
1.1.6 now, we can release it as 1.6 later.
My preference is 1.1.6, but if I'm the only one that feels this way, use 1.6.
On 2/23/07, Paul Spencer [EMAIL PROTECTED]
It will be set, but not in stone. You've changed the version # of
snapshots before. :)
+1 for this not being a release blocker
Paul Spencer wrote:
Mike,
As a part of the 1.1.5 release, the next version is set. Based on your
comments, the version should be set to 1.1.6. I have no problem
line 60 is:
_charArrayWriter.writeTo(getResponse().getWriter());
I am getting this, when running a app:
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.application.jsp.ViewResponseWrapper.flushToWrappedResponse(ViewResponseWrapper.java:60)
at
[
https://issues.apache.org/jira/browse/MYFACES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Broekelmann resolved MYFACES-1441.
--
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
implemented in
[
https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Kienenberger reopened MYFACES-1223:
Assignee: (was: Mathias Broekelmann)
I don't think marking this as
[
https://issues.apache.org/jira/browse/MYFACES-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Broekelmann resolved MYFACES-1223.
--
Resolution: Later
Fix Version/s: 1.2.0-SNAPSHOT
as long as we don't
Mathias,
I'm reading your commit messages, and maybe I'm misunderstanding your
reasons for resolving this.
Did you mean that you implemented it as far as was required, or that
there was more work to be done to support it?
It sounded like you thought more work was required later on.
-Mike
On
I think a version number which is more similar to JSF standard versions will
be much easier for beginners. and less confusing
On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote:
This is to summarize the version number discussion.
MyFaces for JSF 1.1
1.1.5 - Current Release (Announced
Yes that is true - I also marked that issue to be resolved later.
If I understand it right the extension elements are supposed to be
used by jsf implementations. The structure of these elements is not
defined. So it is rather hard to implement something without knowing
what to implement.
When I
[
https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475580
]
Dennis Byrne commented on MYFACES-1246:
---
Thanks Bernd, Hi Paul,
Paul, I plan on diving into this for the
Hi
I've found an interesting bug when using the JSCook menus. If I create
a .jsp file I can use JSCook, for example, this works:
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/tomahawk;
[
https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475588
]
Paul McMahan commented on MYFACES-1246:
---
Dennis, sorry I can see how my comment could be easily
[
https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475593
]
Dennis Byrne commented on MYFACES-1246:
---
Well, I appreciate the help but I'd like to nail this one for all
95 matches
Mail list logo
